Of course miners can shuffle transactions or timestamps or whatever, but that's not ideal xD

already common in other coins I think. not a big deal

Isthmus it actually just depends on miner hash speed. At <50kH/s with current miners, a miner can only do less than 6mill hashes per published block. A nonce with 4 bytes can be up to 4.3 billion, so a miner will never test enough nonces to require all the bits of the nonce.

koe: both monero-pool and nodejs-pool (last I looked) use 16 bytes (4 integers) in the reserved nonce space.

its used so miners are hashing unique data.

like: job,instance,proxy,worker

job being an id for the job, instance being a pool process, proxy being a proxy nonce and worker being a worker id.

as Snipa says, there is no standard. Pools use it however they need to.

if pools didn't use it, every miner would be duplicating work.

nodejs-pool uses 17 bytes, the old node pool uses 4 I think.

koe: "so miner transactions extra nonce is basically ignored" <- No. It is still used/parsed (tx pub key for example).

Snipa: yes sorry 17, not 16. Same with monero-pool.

(neither technically *need* that extra byte of course)

This is quite true. :)

jtgrassie I mean the extra field's extra nonce is ignored/skipped over for miner transactions, different from normal transactions where it might find a payment ID inside

*key?

hello! is there any way to prove a transaction using the CLI without a tx key?

KnifeOfPi_: There's a transaction proof as well, which, as far as I know, does not require the private tx key

Afaik it proves you signed/sent the transaction

AFAIK it needs it.

alrighty

private tx key is only stored in the wallet file, and lost if you only have the seed to restore wallet from?

The generator for all private keys within a wallet is deterministic and depends only on your seed. I beleive this is true.

on your seed and maybe some data in blockchain*

blockchain + seed is enough to restore all your coins

I've done successfully at least once.

private tx keys are not derived from seed, so lost if you lose wallet file

cohcho: yes, enough to restore your *coins* but not enough to know the address you SEND coins to, or to prove you sent a specific transaction.

sent*

well you can prove an output is sent by making a new MLSAG with the same ring, since the same key image will appear (and doesn't reveal which input is spent); not that it's easy to do

which only depends on seed

mmm I think it would work with different ring too, otherwise you could double spend

well the point is to prove a specific transaction is yours

you can prove a specific output you own is spent by signing with the onetime address, but that reveals which output you own

signing and reproducing the key image*

oh ok if you want to prove a specific transaction that makes sense

does the core implementation always construct the tx extra the same way? e.g. always the same order of subfields? I just noticed a block with two transactions, where in one the encrypted ID is before the transaction pub key, and in the other it's after the pub key. Isthmus

It sorts what it can parse.

Im not sure I understand.. before filling the extra field with data, it sorts the values which will be inserted?

Afterwards IIRC.

Since you can add more at any time.

does it sort based on tag?

Yes.

found sort_tx_extra() thanks

this sort_tx_extra seems to imply only one padding chunk can be made by the core implementation (ofc other implementations can do what they want)

The core implementation does not add padding at all.

fair enough lol, the sort_tx_extra() seems at least a bit lenient on people modifying the core implementation