Transcript for #bitcoin-dev 2017/08/30

13:08 nazarewk how can i discover transaction involving only change addresses?
13:09 nazarewk (i've made a CPFP involving change address and it doesn't display anywhere unless i tell it exact txid in gettransaction)
13:13 nazarewk but i still lost fee on this transaction
15:45 esotericnonsense #lnd
15:45 esotericnonsense oops. sorry
18:35 ddustin If the blocksize was increased tremendously, would the Nonce in the block header also be increased to avoid recalculating the merkle root so often?
18:35 ddustin Or would calculating the merkle root still be a negligible overhead
18:39 CryptAxe Does the nonce effect the merkle tree?
18:40 CryptAxe As far as I know, regardless of block size, the nonce value will continue to serve its purpose while remaining at 4 bytes
18:40 CryptAxe We wouldn't have to change the hashing algo just because the block size limit changes
18:40 esotericnonsense ddustin: are you imagining that on each hash cycle the transactions would be different?
18:41 esotericnonsense ddustin: this is basically impossible due to the speed of sha256 on custom hardware (in fact i'd guess even on a standard x86 cpu)
18:41 CryptAxe Yeah you would be slowing your miners down to a crawl if you did that
18:42 esotericnonsense ah hang on I understand now
18:42 esotericnonsense you're talking about extranonce going into the merkle hash
18:44 CryptAxe the extra nonce is usually only changed when you wrap the nonce though. Most miners just change nTime to get more nonce space
18:45 CryptAxe The extra nonce goes into the generation input and doesn't have any meaning in the protocol so I see no reason that the block size would effect that either
18:47 CryptAxe ddustin so what you are saying is that with HUGE blocks, there are going to be a lot of tx's. So incrementing extra nonce actually takes a bit of time. In that case, you could just increment nTime instead and not have to calculate the merkle root again
18:48 ddustin Yeah exactly
18:49 ddustin So nonce + nTime is enough to keep up with hashing speed now and probably forever?
18:49 ddustin My quick math implies that it wouldn't be
18:50 ddustin 32 bits in nonce means about 2.1 GH/s
18:50 CryptAxe Well you can use nTime to get a pretty huge amount of potential hashes, but if you had to you could also mess with the extra nonce
18:51 CryptAxe You'd want to avoid recalculating the merkle root as much as possible but even with big blocks I don't think it would take that long
18:51 CryptAxe The real time sucker with big blocks would be script validation and stuff, calculating the merkle root should be really fast
18:52 ddustin Makes sense
18:52 CryptAxe I guess the nonce field could be made 8 bytes if it becomes a big problem
18:53 CryptAxe I think people would really resist blocks big enough that they cause that issue
18:53 CryptAxe Honestly someone else is probably going to find a block before you start messing with the extra nonce but who knows
18:54 ddustin If your miner is calculating more 2.1 GH/s, than the nTime second counter wouldn't provide enough combinations to keep up with your hash rate
18:55 ddustin I imagine mining pools must run into this already
18:56 ddustin I guess they're just sitting around calculating tons of headers with different merkle hashes and pumping them out to miners?
18:56 ddustin Which I guess if you want to include as many transactions as possible in your block, you'd be doing anyway.. hm. Maybe that solves the problem on its own
19:18 CryptAxe ddustin the pools generally don't change around what transactions they will include very often per block as far as I know
21:10 olrrai hi