do all transaction get constructed by the wallet2 api with this function: github.com/monero-project/monero/bl…e_core/cryptonote_tx_utils.cpp#L201 or are there different code paths?

s/transaction/transactions/, s/cryptonote_core/cryptonote\_core/, s/cryptonote_tx_utils/cryptonote\_tx\_utils/

spirobel[m]: yes, until this PR where multisig txs will use a different path monero-project/monero #8149

UkoeHB: how about transaction uniformity with multisig txs? will they be visible as multisig on chain? or do they look like all other transactions

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

UkoeHB: do they have a dummy payment_id like normal transactions: github.com/monero-project/monero/bl…e_core/cryptonote_tx_utils.cpp#L234 ?

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()

.merges

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

Do we still aim for June 16th? If not, maybe we should have a dev meeting this weekend?

<sech1> "Do we still aim for June 16th..." <- well the branch hasn't even been created, so I think that point's been answered ;)

PRs can be merged, branch can be created in a matter of minutes

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

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?

s/d9acad686f03b1bb5054fb8b4c35a96f22dee45372e4c5ed9751373486d02399259e184f5c7cecf261063dd298e250b2303cf896a3d6705eedd35cc8b97cee0a/c45ca69ddc12adc2fff9951f701bed35f5ca8b48ab7274b9cd50ccecb85f226c4a81e153cd561443ae318500c0f7f6dba14b4b7f11327acd80c60eda52759dcf/

Different encoding probably

.merges

8381 and 8384 are also important before we branch

<sech1> "Different encoding probably" <- But isn't Monero ed25519? monerodocs.org/cryptography/asymmet…ic/private-key/#relation-to-ed25519

<willshu[m]> "Hello, XMR uses ed25519 as far..." <- What's the source of that 128 chars hex string ?

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

Try asking in #monero.

<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?

<arnuschky[m]> "I wanted to suggest a dev..." <- conferences aren't the best place to ask critical questions, though meetings too

willshu[m]: "edd25519 algorithm" what is it ? any code ?

> <@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?

* "ed25519 algorithm" what is it ? any link to code ?

There is no code on that wiki page

How exactly do you generate priv key ?

64 characters or 64 bytes?

merope: 64 characters.

willshu[m]: what is your procedure for generating and printing that private key?

UkoeHB: I did not have the exact code, but this is the procedure: cryptobook.nakov.com/digital-signat…20key,point%20G%20for%20the%20curve).

The private key is a standard ed25519 private key.

That is 32 bytes and 64 characters

> <@will.shu:matrix.org> I did not have the exact code, but this is the procedure: cryptobook.nakov.com/digital-signat…20key,point%20G%20for%20the%20curve).

>

> The private key is a standard ed25519 private key.

Indeed, there is a small problem

github.com/monero-project/monero/bl…ster/src/wallet/api/wallet.cpp#L631, this is where you're stuck

github.com/monero-project/monero/bl…b/master/src/crypto/crypto.cpp#L183, this is why it failed

github.com/monero-project/monero/bl…b/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

try to apply sc_reduce(...) to your hex string, or enter it into monero-wallet-cli and grab reduced one with `spendkey` cmd

const privateViewKey = sc_reduce32(cn_fast_hash(privateSpendKey))

How do you suggest I get my privateSpendKey from the 64-char hex? sc_reduce32(privateKeyHex)?

Above is how I get my privateViewKey from the privateSpendKey.

How do you suggest that I transform from a 64-char hex to a privateSpendKey? sc_reduce32(64-char hex)?

github.com/monero-project/monero/bl…c/cryptonote_basic/account.cpp#L157, call this ::generate(<hex 32 bytes secret>, true, false)

it will generate both view and spend keys

No. The hex represenation is just a textual representation.

moneromooo: ?

willshu[m]: 64 hex -> 32 bytes -> ::generate(...)

s/cryptonote_basic/cryptonote\_basic/, s/<hex/\</

ooo123ooo1234567: Do you know how to call this library from node.js?

<willshu[m]> "Do you know how to call this..." <- github.com/jedisct1/libsodium/blob/…e/sodium/crypto_core_ed25519.h#L104, this function from libsodium is doing the same as sc_reduce(...), there are nodejs bindings for libsodium

<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`

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:

const _sodium = require('libsodium-wrappers');

_sodum.crypto_core_ed25519_scalar_reduce(unsigned char *r, const unsigned char *s)?

What is unsigned char *r, const unsigned char *s?

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

<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?

<ooo123ooo1234567> "it isn't clear whether you're..." <- For example, what does the `::generate(...)` step have to do with sc_reduce?

> <@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 libera.ems.host/_matrix/media/r0/do…331b85297e93e29814c9da4a563205a7c05)

btw, monero lib are you using for nodejs ?

* btw, what monero lib

> <@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 libera.ems.host/_matrix/media/r0/do…0cf19d8939034d9e398cd746226cf2a9f4f)

ooo123ooo1234567: monero-javascript

void crypto_core_ed25519_scalar_reduce(unsigned char *r, const unsigned char *s);

From the doc you showed above, the two params are somewhat different from 32 bytes in js

moneroecosystem.org/monero-javascri…/MoneroWalletKeys.html#createWallet, call it as in example a

* moneroecosystem.org/monero-javascri…/MoneroWalletKeys.html#createWallet, call it as in example

s/a/to generate new wallet keys/

willshu[m]: you shouldn't need to scalar reduce if it's already a private key

hence my question, where did you get that hex string?

> <@will.shu:matrix.org> void crypto_core_ed25519_scalar_reduce(unsigned char *r, const unsigned char *s);

>

> From the doc you showed above, the two params are somewhat different from 32 bytes in js

jedisct1/libsodium #920#issuecomment-578395336, wow, there is even example from libsodium author

UkoeHB: it doesn't matter now

Question. Who takes care of DNS checkpoints? paste.debian.net/hidden/8ea57f14 - isn't it a bit... outdated?

fluffy did years ago

and monerod queries it every hour by default, right in before adding a new block

sometimes these queries stall monerod for up to a minute

which is why p2pool recommends adding --disable-dns-checkpoints

would there be harm in deactivating it at this point?

As far as I understand, it's used to speed up syncing beyond built-in checkpoints

so disabling it won't change anything

speed up? I think it's solely a security feature

syncing goes faster while checkpoints are available

speed up syncing is this other checkpoint system that requires built in hashes

they have the same name but is something different

don't know, it's in the same checkpoints.cpp

It's a semi centralized emergency sanity check. I don't tink it was ever used.

`src/blocks/checkpoints.dat` and hash in `src/cryptonote_core/blockchain.cpp` is used for speed up syncing as far as I know

It doens't affect sync speed. Hash of hashes does. The above ^

sanity check checkpoints are in `src/checkpoints/checkpoints.cpp`

right, it's a different system then

if it isn't used it might make sense to deactivate it and avoid the constant DNS queries

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.

checkpoints.dat is the confusing part

well, all it does now is stalling monerod every hour

and it can potentially shut down all nodes that query DNS, if malicious incorrect hashes are planted there

not p2pool nodes, those will be fine because they disable it

It's off by default. It'll just whine a bit and continue.

it sends SIGTERM if something is wrong

It should not.

If enabled, it should act as a... checkpoint.

right

--enforce-dns-checkpointing enables this shutdown behavior

Maybe I'm misremembering then. I was sure it was off by default...

I just checked the code. It requires this cmd parameter

anyway, should the whole DNS checkpointing be disabled by default?

It's not updated and has never been used

The enforcement, yes. The checking, no, but feel free to make it fetch in a thread.

I was planning to move it to thread pool

until I checked the actual DNS records :D

ok, I'll move it to thread pool then

That's like saying "I never used by first aid kit so first aid kits are useless and should be binned" :)

Now, I'm assuming it still works, and I don't *know* that.

continuing the analogy, who holds the keys to the first aid kit (checkpoints.moneropulse.* domains)?

pony and/or binaryFate AFAIK.

bF now yes

ok, a PR with a few DNS query fixes is coming this week

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

I/O needs separate thread pool

Easy to change, no ?

yes

threadpool::getInstance() -> threadpool::getInstanceForCompute() and threadpool::getInstanceForIO()

sech1: unbound.docs.nlnetlabs.nl/en/latest…bunbound-tutorial/async-lookup.html, welcome to ub_resolve_async

That sounds... odd. Why not use a local one ?

I'm reasonably sue some other classes have their own pool.

no, everyone uses threadpool::getInstance()

Though looking, they all seem to use the default one now.

threadpool even has private constructor

Not sure why. Can't be creation time if it's a long lived object field.

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 ?

it has getNewForUnitTests() function, but it's for testing

Oh, private ctor. I see.

Looks like it was always so, so no object can have had a local pool before.

Must have been boost::thread's then.

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.

*which is 100%

sech1: urgent - disable with cli arg

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

let me decide myself what is a waste of time, ok?

added to ignore again

sech1: there is some problem with logging, added notification is present, but removed notification is absent for some reason

<sech1> "let me decide myself what is a..." <- sure, as long as it doesn't interfere with code correctness in monero repo

<ooo123ooo1234567> "> <@will.shu:matrix.org> void..." <- It seems the `libsodium.js` does not have an export method called `crypto_core_ed25519_scalar_reduce`

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...

<willshu[m]> "Do you know how to call this..." <- github.com/monero-ecosystem/monero-…/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

github.com/monero-ecosystem/monero-…/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

* 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

ooo123ooo1234567: From the js code of this site - xmr.llcoins.net/addresstests.html, can I infer that I can get privateSpendKey from `sc_reduce32(64-char hex)`?

full disclosure: will shu has a ccs open requesting funds for this work , this is his 'homework'

willshu[m]: github.com/moneromooo-monero/monero…/monero-wallet-generator.html#L8662

<sech1> continuing the analogy, who holds the keys to the first aid kit (checkpoints.moneropulse.* domains)? <- pony and me indeed

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

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.

C = x*G + a*H

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?

because if you do a commitment for the wrong amount, the sum of commitments will not be 0

getmonero.org/library/Zero-to-Monero-2-0-0.pdf page 46

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

From there, the sum of the output commitments must equal the sum of the input commitments

plus the range proofs

Yes ^

that prove all numbers are non-negative

Bulletproofs is the name of the proof that makes sure you don't send yourself +5 XMR and -5XMR

Soon Bulletproofs+

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

Maybe my confusion stems from how an input is put into a transaction.

When you receive an output worth let's say 1 XMR and the pederson commitment is C = xG + 1H

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

you select it for outputs, inputs are already on the blockchain

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

So you solve for it

It's still hiding because it's a function of the other blinding factors you picked

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?

Thank you all very much for the responses btw

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.

Thank you all! You guys rock. Gosh dang Monero is neat