< phantomcircuit>
gmaxwell, is there a reason for simple things like IsNull to be in headers? (that dont use templates of course)
< phantomcircuit>
i'd like to move a bunch of those into the .cpp file to improve build performance
< gmaxwell>
so they get inlined.
< phantomcircuit>
gmaxwell, does that actually change the result with any kind of optimization enabled
< gmaxwell>
phantomcircuit: yes, ignoring lto a function must be in the same compliation unit to get inlined.
< phantomcircuit>
gmaxwell, are we using lto?
< gmaxwell>
No.
< gmaxwell>
(should we, perhaps, but it will likely signficiantly slow down compiling and increase memory usage, opposite of the changes you're thinking of making)
< phantomcircuit>
gmaxwell, yeah it would improve things and then make it much much worse all at the end
< arubi>
I'm looking at the famous "value overflow incident" transaction, it has a byte 0xA8 where the sighash type byte is normally found and I was wondering if either 0xa8 was ever a sighash type. also, checking the signature, it seems to behave like ALL. maybe it is that unfamiliar sighash is treated as ALL?
< arubi>
s/either//
< arubi>
ah. I should've tried 'signrawtransaction'. core says "error": "Signature hash type missing or not understood". I wonder how it got into a block at all, unless the logic was different back then!
< sipa>
the signing logic not being able to deal with it doesn't mean it's invalid
< arubi>
good point, so it would just default to ALL?
< arubi>
or, is any type of signature be acceptable in a block? (sorry, brainstorming..)
< sipa>
yes
< sipa>
unknown values are treated as ALL
< sipa>
or rather, look at the low 5 bits of the sighash versions
< sipa>
if those are 2, SIGHASH_NONE
< sipa>
if those are 3, SIGHASH_SINGLE
< sipa>
anything else, SIGHASH_ALL
< arubi>
thanks a lot. should I be looking at interpreter.h/cpp for this logic?
< GitHub195>
[bitcoin] sipa opened pull request #8272: Make the dummy argument to getaddednodeinfo optional (master...optionaladdnodedummy) https://github.com/bitcoin/bitcoin/pull/8272
< adiabat>
howdy, trying to sync testnet3 with the latest master (1922e5)
< adiabat>
this is at height 447195 of segnet3, though I don't think that's related to what caused this...
< adiabat>
447196 is pretty big but there's lots around that size I got through
< btcdrak>
you mean testnet3 i assume
< adiabat>
err yeah heh
< adiabat>
testnet3
< gmaxwell>
So, if the minimum difficulty were softfork increased to, say 2^24 (about 24 5TH/s miners), with an explicit exception for the existing blocks on the well known chain that are below that... would that eliminate the remaining unsolved reason for retaining the checkpoint code? (assuming it's also doing the signature skipping based on headers)
< gmaxwell>
e.g. the exception would work like, diff_bits < 24, store the 24-diff_bits least significant of the block hash... so then any replacement would need to do 2^56 work (24+32) per block to make a replacement of any of those blocks... which I think should make header flooding attacks sufficiently unattractive.
< sipa>
by store you mean hardcode?
< gmaxwell>
Yes. Effectively this would boost all blocks in the chain to at least 2^56 work to produce an alternative, without specifically hardcoding any blocks.
< sipa>
i don't understand how you get to 56
< gmaxwell>
diff 1 is effectively 2^32 work. So diff 2^24 is 2^56 work.
< sipa>
oh, duh
< gmaxwell>
Boosting all blocks to at least 2^56 replacement work, given their actual difficulties would require 489132 bytes of data.
< gmaxwell>
assuming the information were bitpacked.
< gmaxwell>
(more than I expected before I went and measured it)
< sipa>
an alternative is just hardcoding the hash of the first block past 2^24 difficulty, and not downloading any blocks until a header chain past that one was built
< gmaxwell>
that leaves open the attack where I give you infinity alternatives for block 1.
< gmaxwell>
and exaust your resources with headers alone.
< gmaxwell>
in theory a single 5TH/s miner can make 1164 diff1 headers per second. (in practice they can't because their whole control infrastructure is not setup for solutions that fast, but I wouldn't be surprised if the asics could, given alternative control)
< gmaxwell>
also, if the going forward minimum is not increased, someone could start at the 2^24 point, then do 2^57 work to make a chain moving the difficulty back to 1, then continue the headerflooding attack at diff 1.
< gmaxwell>
actually that rampdown would be 2^67.39 work, (I forgot to account for the fact that difficulty is held constant for 2016 blocks).
< gmaxwell>
assuming mining hardware were actually efficient at low difficulty header creation the cost of that rampdown in lost subsidy income vs mining at current difficulty would be 5.3827 BTC.
< gmaxwell>
Cost of a rampdown from diff 2**32 would be 1377.977 BTC.
< gmaxwell>
pinning up to diff 2^32 would be 292320 blocks, about 1.11MB data if pinned with 32bits/block.
< gmaxwell>
alternatively, including the first 292320 headers would add about 23MB to the package, but would actually save 23MB of data transfered from the network at start.
< gmaxwell>
14MB if it was 'compressed' by exploiting the prevhash.
< luke-jr>
when does cfields get back, and when he does, can we set <someone else> up wiht access to the dev webserver so it's not entirely dependent on him? :x
< sipa>
i believe he'll return next week
< sipa>
and yes
< Lightsword>
is there a debug flag needed to see what IP address a block is downloaded from?
< Lightsword>
I’m using logips=1 already
< sipa>
debug=net will should you which messages are sent to which peers
< sipa>
(by node id, but you can match up node ids with ip address using -logips, or getpeerinfo)
< Lightsword>
kk, no way to have it print IP’s directly? that would make grepping a lot easier :P