1 2017-08-30 13:08:58 <nazarewk> how can i discover transaction involving only change addresses?
 2 2017-08-30 13:09:35 <nazarewk> (i've made a CPFP involving change address and it doesn't display anywhere unless i tell it exact txid in gettransaction)
 3 2017-08-30 13:13:21 <nazarewk> but i still lost fee on this transaction
 4 2017-08-30 15:45:31 <esotericnonsense> #lnd
 5 2017-08-30 15:45:35 <esotericnonsense> oops. sorry
 6 2017-08-30 18:35:31 <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?
 7 2017-08-30 18:35:52 <ddustin> Or would calculating the merkle root still be a negligible overhead
 8 2017-08-30 18:39:04 <CryptAxe> Does the nonce effect the merkle tree?
 9 2017-08-30 18:40:30 <CryptAxe> As far as I know, regardless of block size, the nonce value will continue to serve its purpose while remaining at 4 bytes
10 2017-08-30 18:40:46 <CryptAxe> We wouldn't have to change the hashing algo just because the block size limit changes
11 2017-08-30 18:40:53 <esotericnonsense> ddustin: are you imagining that on each hash cycle the transactions would be different?
12 2017-08-30 18:41:30 <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)
13 2017-08-30 18:41:51 <CryptAxe> Yeah you would be slowing your miners down to a crawl if you did that
14 2017-08-30 18:42:15 <esotericnonsense> ah hang on I understand now
15 2017-08-30 18:42:31 <esotericnonsense> you're talking about extranonce going into the merkle hash
16 2017-08-30 18:44:34 <CryptAxe> the extra nonce is usually only changed when you wrap the nonce though. Most miners just change nTime to get more nonce space
17 2017-08-30 18:45:17 <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 2017-08-30 18:47:36 <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
19 2017-08-30 18:48:25 <ddustin> Yeah exactly
20 2017-08-30 18:49:14 <ddustin> So nonce + nTime is enough to keep up with hashing speed now and probably forever?
21 2017-08-30 18:49:56 <ddustin> My quick math implies that it wouldn't be
22 2017-08-30 18:50:42 <ddustin> 32 bits in nonce means about 2.1 GH/s
23 2017-08-30 18:50:49 <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
24 2017-08-30 18:51:22 <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
25 2017-08-30 18:51:48 <CryptAxe> The real time sucker with big blocks would be script validation and stuff, calculating the merkle root should be really fast
26 2017-08-30 18:52:09 <ddustin> Makes sense
27 2017-08-30 18:52:50 <CryptAxe> I guess the nonce field could be made 8 bytes if it becomes a big problem
28 2017-08-30 18:53:03 <CryptAxe> I think people would really resist blocks big enough that they cause that issue
29 2017-08-30 18:53:34 <CryptAxe> Honestly someone else is probably going to find a block before you start messing with the extra nonce but who knows
30 2017-08-30 18:54:47 <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
31 2017-08-30 18:55:12 <ddustin> I imagine mining pools must run into this already
32 2017-08-30 18:56:07 <ddustin> I guess they're just sitting around calculating tons of headers with different merkle hashes and pumping them out to miners?
33 2017-08-30 18:56:53 <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
34 2017-08-30 19:18:58 <CryptAxe> ddustin the pools generally don't change around what transactions they will include very often per block as far as I know
35 2017-08-30 21:10:14 <olrrai> hi