02:50:35 <spirobel[m]> do all transaction get constructed by the wallet2 api with this function: https://github.com/monero-project/monero/blob/c6d387184e05437d8f68a4227d739ad28568aa5e/src/cryptonote_core/cryptonote_tx_utils.cpp#L201 or are there different code paths?
02:50:41 <spirobel[m]> s/transaction/transactions/, s/cryptonote_core/cryptonote\_core/, s/cryptonote_tx_utils/cryptonote\_tx\_utils/
02:53:29 <UkoeHB> spirobel[m]: yes, until this PR where multisig txs will use a different path https://github.com/monero-project/monero/pull/8149
02:55:43 <spirobel[m]> UkoeHB: how about transaction uniformity with multisig txs? will they be visible as multisig on chain? or do they look like all other transactions
02:57:25 <UkoeHB> they should look like other txs, aside from the fact ring members and tx fee will be very stale compared to when the tx is submitted
02:57:59 <spirobel[m]> UkoeHB: do they have a dummy payment_id like normal transactions: https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/cryptonote_core/cryptonote_tx_utils.cpp#L234 ?
03:00:03 <UkoeHB> spirobel[m]: yes, you can see it in set_tx_extra(); a large amount of that code was copied directly from construct_tx_with_tx_key()
07:23:07 <sech1> .merges
07:23:07 -xmr-pr- 7774 8296 8356 8357 8358
07:23:34 <sech1> I hate to be that guy but I have to remind that June 16th was supposed to be binary release date, this is in 2 days
07:29:33 <sech1> Do we still aim for June 16th? If not, maybe we should have a dev meeting this weekend?
09:01:39 <arnuschky[m]> <sech1> "Do we still aim for June 16th..." <- well the branch hasn't even been created, so I think that point's been answered ;)
09:02:12 <sech1> PRs can be merged, branch can be created in a matter of minutes
09:02:37 <arnuschky[m]> I wanted to suggest a dev meeting on the multisig situation this weekend already (if we have the audit's final report). Alternatively we could meet up at Monerokon
09:37:26 <willshu[m]> Hello, XMR uses ed25519 as far as I know. This is, for example, an ed25519 private key, "d9acad686f03b1bb5054fb8b4c35a96f22dee45372e4c5ed9751373486d02399259e184f5c7cecf261063dd298e250b2303cf896a3d6705eedd35cc8b97cee0a". When I use the first 64 characters to sign a transaction, the sdk returns "failed to verify secret spend key". Why is that?
09:38:18 <willshu[m]> s/d9acad686f03b1bb5054fb8b4c35a96f22dee45372e4c5ed9751373486d02399259e184f5c7cecf261063dd298e250b2303cf896a3d6705eedd35cc8b97cee0a/c45ca69ddc12adc2fff9951f701bed35f5ca8b48ab7274b9cd50ccecb85f226c4a81e153cd561443ae318500c0f7f6dba14b4b7f11327acd80c60eda52759dcf/
09:40:32 <sech1> Different encoding probably
09:42:07 <sech1> .merges
09:42:07 -xmr-pr- 7774 8296 8356 8357 8358
09:42:24 <sech1> 8381 and 8384 are also important before we branch
09:49:03 <willshu[m]> <sech1> "Different encoding probably" <- But isn't Monero ed25519? https://monerodocs.org/cryptography/asymmetric/private-key/#relation-to-ed25519
10:10:53 <ooo123ooo1234567> <willshu[m]> "Hello, XMR uses ed25519 as far..." <- What's the source of that 128 chars hex string ?
10:21:24 <YOUNGUNION[m]> admins, hello i need help with my transaction from binance to monero wallet. i dont get monero from binance, because payment id not found about error host
10:25:50 <moneromooo> Try asking in #monero.
10:49:52 <willshu[m]> <ooo123ooo1234567> "What's the source of that 128..." <- You mean for the same mnemonic, ed25519 and xmr algorithm generates different private (spend) key, so I cannot use an ed25519 private key as xmr private spend key?
10:50:32 <ooo123ooo1234567> <arnuschky[m]> "I wanted to suggest a dev..." <- conferences aren't the best place to ask critical questions, though meetings too
10:51:05 <ooo123ooo1234567> willshu[m]: "edd25519 algorithm" what is it ? any code ?
10:51:17 <ooo123ooo1234567> > <@will.shu:matrix.org> You mean for the same mnemonic, ed25519 and xmr algorithm generates different private (spend) key, so I cannot use an ed25519 private key as xmr private spend key?
10:51:17 <ooo123ooo1234567>  * "ed25519 algorithm" what is it ? any link to code ?
10:52:36 <willshu[m]> https://en.wikipedia.org/wiki/EdDSA
10:53:32 <ooo123ooo1234567> There is no code on that wiki page
10:53:57 <ooo123ooo1234567> How exactly do you generate priv key ?
10:53:57 <merope> 64 characters or 64 bytes?
10:54:53 <willshu[m]> merope: 64 characters.
11:00:56 <UkoeHB> willshu[m]: what is your procedure for generating and printing that private key?
11:04:38 <willshu[m]> UkoeHB: I did not have the exact code, but this is the procedure: https://cryptobook.nakov.com/digital-signatures/eddsa-and-ed25519#:~:text=For%20Ed25519%20the%20private%20key,point%20G%20for%20the%20curve).
11:04:38 <willshu[m]> The private key is a standard ed25519 private key.
11:04:54 <willshu[m]> That is 32 bytes and 64 characters
11:09:15 <ooo123ooo1234567> > <@will.shu:matrix.org> I did not have the exact code, but this is the procedure: https://cryptobook.nakov.com/digital-signatures/eddsa-and-ed25519#:~:text=For%20Ed25519%20the%20private%20key,point%20G%20for%20the%20curve).
11:09:15 <ooo123ooo1234567> > 
11:09:15 <ooo123ooo1234567> > The private key is a standard ed25519 private key.
11:09:15 <ooo123ooo1234567> Indeed, there is a small problem
11:10:12 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/src/wallet/api/wallet.cpp#L631, this is where you're stuck
11:10:39 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L183, this is why it failed
11:11:07 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L167, if you would pass the same hex string into monero-wallet-cli then it would firstly reduce secret key
11:11:35 <ooo123ooo1234567> try to apply sc_reduce(...) to your hex string, or enter it into monero-wallet-cli and grab reduced one with `spendkey` cmd
11:12:57 <willshu[m]> const privateViewKey = sc_reduce32(cn_fast_hash(privateSpendKey))
11:13:26 <willshu[m]> How do you suggest I get my privateSpendKey from the 64-char hex? sc_reduce32(privateKeyHex)?
11:14:07 <willshu[m]> Above is how I get my privateViewKey from the privateSpendKey.
11:14:53 <willshu[m]> How do you suggest that I transform from a 64-char hex to a privateSpendKey? sc_reduce32(64-char hex)?
11:15:53 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/account.cpp#L157, call this ::generate(<hex 32 bytes secret>, true, false)
11:16:21 <ooo123ooo1234567> it will generate both view and spend keys
11:16:43 <moneromooo> No. The hex represenation is just a textual representation.
11:17:03 <willshu[m]> moneromooo: ?
11:18:25 <ooo123ooo1234567> willshu[m]: 64 hex -> 32 bytes -> ::generate(...)
11:18:45 <ooo123ooo1234567> s/cryptonote_basic/cryptonote\_basic/, s/<hex/\</
11:19:00 <willshu[m]> ooo123ooo1234567: Do you know how to call this library from node.js?
11:28:52 <ooo123ooo1234567> <willshu[m]> "Do you know how to call this..." <- https://github.com/jedisct1/libsodium/blob/master/src/libsodium/include/sodium/crypto_core_ed25519.h#L104, this function from libsodium is doing the same as sc_reduce(...), there are nodejs bindings for libsodium
11:37:28 <ooo123ooo1234567> <willshu[m]> "Do you know how to call this..." <- just add reduce step for secret, which is being generated for some reason outside of monero "sdk", once wallet is generated from secret spend key it's possible to get all keys with methods `std::string WalletImpl::secretViewKey() const`
11:41:02 <willshu[m]> ooo123ooo1234567: no problem from privateSpendKey to privateViewKey, just looking at how to get from 64-char hex to privateSpendKey. Do you mean I call in Node.js:
11:41:02 <willshu[m]> const _sodium = require('libsodium-wrappers');
11:41:02 <willshu[m]> _sodum.crypto_core_ed25519_scalar_reduce(unsigned char *r, const unsigned char *s)?
11:41:02 <willshu[m]> What is unsigned char *r, const unsigned char *s?
11:41:45 <ooo123ooo1234567> it isn't clear whether you're doing in educational purposes or for some production, 1st case - use monero-wallet-cli / read code, 2nd case - generate new wallet with monero wallet api instead of externally / read code
11:49:03 <willshu[m]> <ooo123ooo1234567> "it isn't clear whether you're..." <- Sorry I am a little lost. 64 hex -> 32 bytes -> ::generate(...) : Which library and api should I use?
11:51:54 <willshu[m]> <ooo123ooo1234567> "it isn't clear whether you're..." <- For example, what does the `::generate(...)` step have to do with sc_reduce?
11:51:55 <ooo123ooo1234567> > <@will.shu:matrix.org> no problem from privateSpendKey to privateViewKey, just looking at how to get from 64-char hex to privateSpendKey. Do you mean I call in Node.js:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/653d3331b85297e93e29814c9da4a563205a7c05)
11:52:27 <ooo123ooo1234567> btw, monero lib are you using for nodejs ?
11:52:31 <ooo123ooo1234567> * btw, what monero lib
11:54:00 <ooo123ooo1234567> > <@will.shu:matrix.org> no problem from privateSpendKey to privateViewKey, just looking at how to get from 64-char hex to privateSpendKey. Do you mean I call in Node.js:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6752d0cf19d8939034d9e398cd746226cf2a9f4f)
11:54:54 <willshu[m]> ooo123ooo1234567: monero-javascript
11:59:33 <willshu[m]> void crypto_core_ed25519_scalar_reduce(unsigned char *r, const unsigned char *s);
11:59:33 <willshu[m]> From the doc you showed above, the two params are somewhat different from 32 bytes in js
12:02:28 <ooo123ooo1234567> https://moneroecosystem.org/monero-javascript/MoneroWalletKeys.html#createWallet, call it as in example a
12:02:32 <ooo123ooo1234567>  * https://moneroecosystem.org/monero-javascript/MoneroWalletKeys.html#createWallet, call it as in example
12:02:43 <ooo123ooo1234567> s/a/to generate new wallet keys/
12:12:09 <UkoeHB> willshu[m]: you shouldn't need to scalar reduce if it's already a private key
12:12:30 <UkoeHB> hence my question, where did you get that hex string?
12:12:30 <ooo123ooo1234567> > <@will.shu:matrix.org> void crypto_core_ed25519_scalar_reduce(unsigned char *r, const unsigned char *s);
12:12:31 <ooo123ooo1234567> > 
12:12:31 <ooo123ooo1234567> > From the doc you showed above, the two params are somewhat different from 32 bytes in js
12:12:31 <ooo123ooo1234567> https://github.com/jedisct1/libsodium/issues/920#issuecomment-578395336, wow, there is even example from libsodium author
12:14:28 <ooo123ooo1234567> UkoeHB: it doesn't matter now
12:34:58 <sech1> Question. Who takes care of DNS checkpoints? https://paste.debian.net/hidden/8ea57f14/ - isn't it a bit... outdated?
12:37:33 <selsta> fluffy did years ago
12:37:59 <sech1> and monerod queries it every hour by default, right in before adding a new block
12:38:09 <sech1> sometimes these queries stall monerod for up to a minute
12:38:25 <sech1> which is why p2pool recommends adding --disable-dns-checkpoints
12:38:46 <selsta> would there be harm in deactivating it at this point?
12:39:10 <sech1> As far as I understand, it's used to speed up syncing beyond built-in checkpoints
12:39:17 <sech1> so disabling it won't change anything
12:39:36 <selsta> speed up? I think it's solely a security feature
12:40:05 <sech1> syncing goes faster while checkpoints are available
12:40:08 <selsta> speed up syncing is this other checkpoint system that requires built in hashes
12:40:19 <selsta> they have the same name but is something different
12:40:24 <sech1> don't know, it's in the same checkpoints.cpp
12:40:38 <moneromooo> It's a semi centralized emergency sanity check. I don't tink it was ever used.
12:41:07 <selsta> `src/blocks/checkpoints.dat` and hash in `src/cryptonote_core/blockchain.cpp` is used for speed up syncing as far as I know
12:41:19 <moneromooo> It doens't affect sync speed. Hash of hashes does. The above ^
12:41:22 <selsta> sanity check checkpoints are in `src/checkpoints/checkpoints.cpp`
12:42:10 <sech1> right, it's a different system then
12:42:22 <selsta> if it isn't used it might make sense to deactivate it and avoid the constant DNS queries
12:42:58 <moneromooo> The embedded hashes should not be called checkpoints, they're hashes of block hashes. Same as calling output pubkeys stealth addresses, it just confuses things by taking a name and applying it to something else.
12:43:14 <selsta> checkpoints.dat is the confusing part
12:44:12 <sech1> well, all it does now is stalling monerod every hour
12:45:34 <sech1> and it can potentially shut down all nodes that query DNS, if malicious incorrect hashes are planted there
12:45:49 <sech1> not p2pool nodes, those will be fine because they disable it
12:46:06 <moneromooo> It's off by default. It'll just whine a bit and continue.
12:46:49 <sech1> https://github.com/monero-project/monero/blob/master/src/cryptonote_core/cryptonote_core.cpp#L298
12:46:56 <sech1> it sends SIGTERM if something is wrong
12:47:59 <moneromooo> It should not.
12:48:23 <moneromooo> If enabled, it should act as a... checkpoint.
12:48:31 <sech1> right
12:48:39 <sech1> --enforce-dns-checkpointing enables this shutdown behavior
12:49:45 <moneromooo> Maybe I'm misremembering then. I was sure it was off by default...
12:50:01 <sech1> I just checked the code. It requires this cmd parameter
12:50:21 <sech1> anyway, should the whole DNS checkpointing be disabled by default?
12:50:42 <sech1> It's not updated and has never been used
12:50:48 <moneromooo> The enforcement, yes. The checking, no, but feel free to make it fetch in a thread.
12:51:02 <sech1> I was planning to move it to thread pool
12:51:13 <sech1> until I checked the actual DNS records :D
12:51:25 <sech1> ok, I'll move it to thread pool then
12:51:41 <moneromooo> That's like saying "I never used by first aid kit so first aid kits are useless and should be binned" :)
12:51:56 <moneromooo> Now, I'm assuming it still works, and I don't *know* that.
12:52:34 <sech1> continuing the analogy, who holds the keys to the first aid kit (checkpoints.moneropulse.* domains)?
12:52:59 <moneromooo> pony and/or binaryFate AFAIK.
12:53:11 <selsta> bF now yes
12:55:19 <sech1> ok, a PR with a few DNS query fixes is coming this week
12:56:04 <sech1> I also don't like how the default thread pool is used for both tx verification and DNS queries. Checkpoints fill the thread pool with long-lasting DNS queries (7 at a time), stalling all tx verification
12:56:22 <sech1> I/O needs separate thread pool
12:56:45 <moneromooo> Easy to change, no ?
12:56:48 <sech1> yes
12:57:11 <sech1> threadpool::getInstance() -> threadpool::getInstanceForCompute() and threadpool::getInstanceForIO()
12:57:53 <ooo123ooo1234567> sech1: https://unbound.docs.nlnetlabs.nl/en/latest/developer/libunbound-tutorial/async-lookup.html, welcome to ub_resolve_async
12:58:22 <moneromooo> That sounds... odd. Why not use a local one ?
12:58:36 <moneromooo> I'm reasonably sue some other classes have their own pool.
12:59:24 <sech1> no, everyone uses threadpool::getInstance()
12:59:26 <moneromooo> Though looking, they all seem to use the default one now.
12:59:45 <sech1> threadpool even has private constructor
13:00:09 <moneromooo> Not sure why. Can't be creation time if it's a long lived object field.
13:00:14 <ooo123ooo1234567> sech1: There are more sophisticated ways to stall tx verification, why to start from the most unimportant one which can be even disabled with cli arg ?
13:00:22 <sech1> it has getNewForUnitTests() function, but it's for testing
13:00:52 <moneromooo> Oh, private ctor. I see.
13:01:45 <moneromooo> Looks like it was always so, so no object can have had a local pool before.
13:02:05 <moneromooo> Must have been boost::thread's then.
13:03:00 <sech1> ooo123 again "useful" advices, better keep silent if you have nothing useful. unbound async lookup? What to do with the calling code with is 100% synchronous? Are you advocating for a full rewrite again? "Unimportant"? It literally stalls monerod every hour for a random (sometimes up to a minute) period of time.
13:03:10 <sech1> *which is 100%
13:03:45 <ooo123ooo1234567> sech1: urgent - disable with cli arg
13:04:26 <ooo123ooo1234567> sech1: It will be rewrite since there are other problems and thread for that particular dns check is a waste of time, unless it's in educational purposes
13:05:39 <sech1> let me decide myself what is a waste of time, ok?
13:05:47 <sech1> added to ignore again
13:07:12 <ooo123ooo1234567> sech1: there is some problem with logging, added notification is present, but removed notification is absent for some reason
13:15:58 <ooo123ooo1234567> <sech1> "let me decide myself what is a..." <- sure, as long as it doesn't interfere with code correctness in monero repo
13:28:36 <willshu[m]> <ooo123ooo1234567> "> <@will.shu:matrix.org> void..." <- It seems the `libsodium.js` does not have an export method called `crypto_core_ed25519_scalar_reduce`
13:46:53 <kayabanerve[m]> will.shu: If you get a bigint, you can trivially perform scalar reduction, though I'd have to check what elliptic/noble does for a constant time bigint...
14:03:38 <ooo123ooo1234567> <willshu[m]> "Do you know how to call this..." <- https://github.com/monero-ecosystem/monero-cpp/blob/master/src/wallet/monero_wallet_keys.cpp#L167, found answer for this: check how create_wallet_from_keys was exported into node-js via monero-javascript->monero-cpp->monero_wasm_bridge.cpp
14:04:32 <ooo123ooo1234567> https://github.com/monero-ecosystem/monero-cpp/blob/master/src/wallet/monero_wallet_keys.cpp#L167, you can export this way function that will accept hex string -> decode it into bytes -> apply sc_reduce -> return reduced hex string
14:04:57 <ooo123ooo1234567>  * https://github.com/monero-ecosystem/monero-cpp/blob/master/src/wallet/monero\_wallet\_keys.cpp#L167, you can export this way new function that will accept hex string -> decode it into bytes -> apply sc\_reduce -> return reduced hex string
14:13:35 <willshu[m]> ooo123ooo1234567: From the js code of this site - https://xmr.llcoins.net/addresstests.html, can I infer that I can get privateSpendKey from `sc_reduce32(64-char hex)`?
14:14:20 <plowsof[m]> full disclosure: will shu has a ccs open requesting funds for this work , this is his 'homework' 
14:15:48 <ooo123ooo1234567> willshu[m]: https://github.com/moneromooo-monero/monero-wallet-generator/blob/master/monero-wallet-generator.html#L8662
20:45:19 <binaryFate> <sech1> continuing the analogy, who holds the keys to the first aid kit (checkpoints.moneropulse.* domains)? <- pony and me indeed
22:08:12 <monerm[m]> Howdy folks, I'm new to Monero and I'm trying to understand how it works and was hoping someone here could answer a question for me
22:11:21 <monerm[m]> I know how Pedersen commitments verify that the sum of all inputs and outputs is zero. What I don't know is how the network confirms that the input amounts are legitimate to begin with.
22:11:21 <monerm[m]> C = x*G + a*H
22:11:21 <monerm[m]> What is preventing me from using an output worth 0.4 XMR as an input in a tx, but doing the pedersen commitment math as if "a" is 0.6? Essentially, how does anyone verify that "a" is the actual amount of an input?
22:18:52 <sech1> because if you do a commitment for the wrong amount, the sum of commitments will not be 0
22:20:52 <sech1> https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf page 46
22:25:44 <jeffro256[m]> All amounts start as unencrypted from minining, so that the commitments have a starting point which everyone can verify so that there's not an infinite amount floating around 
22:26:14 <jeffro256[m]> From there, the sum of the output commitments must equal the sum of the input commitments 
22:27:24 <sech1> plus the range proofs
22:27:30 <jeffro256[m]> Yes ^
22:27:31 <sech1> that prove all numbers are non-negative
22:28:00 <jeffro256[m]> Bulletproofs is the name of the proof that makes sure you don't send yourself +5 XMR and -5XMR
22:29:57 <jeffro256[m]> Soon Bulletproofs+
22:31:45 <jeffro256[m]> The only way you could  come up with a commitment which satisfies that the sum is 0 without the amounts summing to 0 is you would have to know the logarithm between G and H, which were picked so that no ones ones that
22:34:15 <monerm[m]> Maybe my confusion stems from how an input is put into a transaction.
22:34:15 <monerm[m]> When you receive an output worth let's say 1 XMR and the pederson commitment is C = xG + 1H
22:34:15 <monerm[m]> When you go to spend it as an input does x have to be the same? My understanding was that you select a random x when building the transaction
22:36:18 <sech1> you select it for outputs, inputs are already on the blockchain
22:44:52 <jeffro256[m]> I believe you can pick random x for all except one output on a transaction. Once you have picked random blinding factors for other outputs, there is only one "correct" blinding factor for the last output
22:45:00 <jeffro256[m]> So you solve for it
22:45:19 <jeffro256[m]> It's still hiding because it's a function of the other blinding factors you picked
22:55:06 <monerm[m]> So as the receiver. My output to my stealth address is C = xG + 1H. When I spend it I must use the same C = xG + 1H right?
22:55:27 <monerm[m]> Thank you all very much for the responses btw
22:57:51 <UkoeHB> monerm[m]: yes, when you spend an output you give the verifier an index reference into the ledger. The verifier looks up the exact copy of your output (along with all the decoys) in order to verify CLSAGs.
23:06:12 <monerm[m]> Thank you all! You guys rock. Gosh dang Monero is neat