00:05:52 * Isthmus tries to figure out the probability that there is *not* a winning nonce [0,2^32) as  function of network difficulty
00:06:53 <Isthmus> Of course miners can shuffle transactions or timestamps or whatever, but that's not ideal xD
04:11:33 <luigi1111> already common in other coins I think. not a big deal
04:18:36 <koe> 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.
04:56:46 <jtgrassie> koe: both monero-pool and nodejs-pool (last I looked) use 16 bytes (4 integers) in the reserved nonce space.
04:57:54 <jtgrassie> its used so miners are hashing unique data.
04:59:31 <jtgrassie> like: job,instance,proxy,worker
05:01:35 <jtgrassie> job being an id for the job, instance being a pool process, proxy being a proxy nonce and worker being a worker id.
05:02:39 <jtgrassie> as Snipa says, there is no standard. Pools use it however they need to.
05:03:41 <jtgrassie> if pools didn't use it, every miner would be duplicating work.
05:08:21 <Snipa> nodejs-pool uses 17 bytes, the old node pool uses 4 I think.
05:09:16 <jtgrassie> koe: "so miner transactions extra nonce is basically ignored" <- No. It is still used/parsed (tx pub key for example).
05:09:43 <jtgrassie> Snipa: yes sorry 17, not 16. Same with monero-pool.
05:13:50 <jtgrassie> (neither technically *need* that extra byte of course)
05:14:01 <Snipa> This is quite true. :)
15:55:25 <koe> 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
18:40:54 <KnifeOfPi_> *key?
18:41:17 <KnifeOfPi_> hello! is there any way to prove a transaction using the CLI without a tx key?
19:09:18 <dEBRUYNE> KnifeOfPi_: There's a transaction proof as well, which, as far as I know, does not require the private tx key
19:09:25 <dEBRUYNE> Afaik it proves you signed/sent the transaction
19:09:49 <moneromooo> AFAIK it needs it.
19:09:58 <KnifeOfPi_> alrighty
21:54:36 <Inge-> private tx key is only stored in the wallet file, and lost if you only have the seed to restore wallet from?
21:57:05 <cohcho> The generator for all private keys within a wallet is deterministic and depends only on your seed. I beleive this is true.
21:57:47 <cohcho> on your seed and maybe some data in blockchain*
21:58:01 <cohcho> blockchain + seed is enough to restore all your coins
21:58:54 <cohcho> I've done successfully at least once.
22:01:39 <binaryFate> private tx keys are not derived from seed, so lost if you lose wallet file
22:07:07 <Inge-> 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.
22:07:14 <Inge-> sent*
22:10:43 <koe> 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
22:11:58 <koe> which only depends on seed
22:12:36 <binaryFate> mmm I think it would work with different ring too, otherwise you could double spend
22:13:05 <koe> well the point is to prove a specific transaction is yours
22:13:56 <koe> you can prove a specific output you own is spent by signing with the onetime address, but that reveals which output you own
22:14:13 <koe> signing and reproducing the key image*
22:15:21 <binaryFate> oh ok if you want to prove a specific transaction that makes sense
22:47:32 <koe> 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
22:47:54 <moneromooo> It sorts what it can parse.
22:49:39 <koe> Im not sure I understand.. before filling the extra field with data, it sorts the values which will be inserted?
23:00:34 <moneromooo> Afterwards IIRC.
23:00:42 <moneromooo> Since you can add more at any time.
23:01:30 <koe> does it sort based on tag?
23:05:02 <moneromooo> Yes.
23:06:13 <koe> found sort_tx_extra() thanks
23:12:38 <koe> 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)
23:16:39 <moneromooo> The core implementation does not add padding at all.
23:18:07 <koe> fair enough lol, the sort_tx_extra() seems at least a bit lenient on people modifying the core implementation