-
m-relay
<kayabanerve:matrix.org> I'd ack given my call for a moratorium on ecc dev but jeffro256: may want a new tx version after the fcmp++ HF (same time as jamtis)?
-
m-relay
<kayabanerve:matrix.org> That raises the Q if we're going to have a 2.0 in 6-12 months
-
m-relay
<kayabanerve:matrix.org> If there's still frequent consensus changes, I'd advocate shifting the versions over, not making a 1.0
-
sech1
Let's just shift from v0.18.x.x. to v19.x.x to satisfy everyone :)
-
m-relay
<j0j0xmr:monero.social> What's wrong with sender privacy?
-
sech1
Ring signatures are not perfect (only 16 decoys). See EAE attack, for example
-
m-relay
<syntheticbird:monero.social> sech1 even see OSPEAD latest results show yesterday
-
m-relay
<syntheticbird:monero.social> 4.2 effective ring size
-
m-relay
<syntheticbird:monero.social> 4.2 effective ring size at worst
-
m-relay
<fede:xmr.mx> Where do I put the "nonce extra" in the Monero block header? Inside the transaction with the TxExtraTagNonce right?
-
m-relay
<fede:xmr.mx> Test
-
m-relay
<fede:xmr.mx> Why are my messages instantly deleted?
-
m-relay
<syntheticbird:monero.social> they are not
-
m-relay
<syntheticbird:monero.social> we can see them
-
m-relay
<fede:xmr.mx> test
-
sech1
"nonce extra" is put in the tx_extra field of the coinbase transaction. Yes, with the TX_EXTRA_NONCE tag.
-
m-relay
<fede:xmr.mx> The size can be anything? Can I have a 16 or 32 bytes extra nonce?
-
m-relay
<fede:xmr.mx> And the process would be as follows for a 16 byte nonce, correct?
-
m-relay
<fede:xmr.mx> 1. call get_block_template with reserve_size = 17 (16+1)
-
m-relay
<fede:xmr.mx> 2. unmarshal the `blocktemplate_blob` to a Block struct (provided by
git.gammaspectra.live/P2Pool/consen…ch/master/p2pool/stratum/stratum.go , a cool library i found)
-
m-relay
<fede:xmr.mx> 3. edit the TxExtra to replace the 17 empty bytes with `TxExtraTagNonce` prefix + 16 random bytes
-
m-relay
<fede:xmr.mx> 4. get the hashing blob with block.HashingBlob() and send it to miners for work
-
m-relay
<fede:xmr.mx> i'm unsure about the steps 2. and 3
-
m-relay
<fede:xmr.mx> The size can be anything? Can I have a 16 or 32 bytes extra nonce?
-
m-relay
<fede:xmr.mx> And the process would be as follows for a 16 byte nonce, correct?
-
m-relay
<fede:xmr.mx> 1. call get\_block\_template with reserve\_size = 17 (16+1)
-
m-relay
<fede:xmr.mx> 2. unmarshal the `blocktemplate_blob` to a Block struct (provided by
git.gammaspectra.live/P2Pool/consen…branch/master/monero/block/block.go , a cool library i found)
-
m-relay
<fede:xmr.mx> 3. edit the TxExtra to replace the 17 empty bytes with `TxExtraTagNonce` prefix + 16 random bytes
-
m-relay
<fede:xmr.mx> 4. get the hashing blob with block.HashingBlob() and send it to miners for work
-
m-relay
<fede:xmr.mx> @sech1
-
sech1
Size must be < 256 bytes
-
sech1
But you don't need a lot for tx_extra
-
m-relay
<fede:xmr.mx> are the steps i outlined correct?
-
sech1
yes, but you need to have a unique tx_extra for each miner
-
sech1
or they will mine on the same hashing blob
-
m-relay
<fede:xmr.mx> of course... i generate a different tx_extra for every single job for each miner
-
sech1
get_block_template returns hashing blob, but you can't use it directly. You need to edit the template (tx_extra in it), then recalculate the hashing blob. So steps 3-4 are correct
-
sech1
I mean you can use it directly, but only for solo mining
-
m-relay
<fede:xmr.mx> yes, and i rely on that Go implementation to calculate block.HashingBlob()
-
sech1
It should work. You can check it on testnet
-
m-relay
<fede:xmr.mx> (testnet synchronization is so slow 😦)
-
m-relay
<fede:xmr.mx> i mean stagenet
-
selsta
.merge+ 9720 9721
-
xmr-pr
Added