< conman>
will 0.16.0 have bech32 support? I don't see it in the readme
< gmaxwell>
conman: yes, it has BIP173 support for sending; and if you request it, for recieving too.
< conman>
great, so validateaddress will return true for it too then
< gmaxwell>
it won't use it for rx by default, but you can set the default wallet wide, or request BC1 addresses on a case by case basis.
< gmaxwell>
Yes.
< conman>
ack
< conman>
thanks
< conman>
guess I better add support in my pools for it soon then
< gmaxwell>
would be nice, ... though we were expecting the rollout to take a long time.
< gmaxwell>
Electrum has pushed it forward by making their segwit mode require it.
< conman>
nod
< conman>
my pool code asks bitcoin core to validate addresses so if I upgrade to .16 without adding support it will likely create corrupt generation transactions for bech32
< conman>
should look to see what new rpc commands are in .16...
< gmaxwell>
hm. how would it end up corrupt?
< conman>
I hard code to look for a 3x address and it does p2sh output on that
< conman>
if it doesn't see 3 it will assume it's a p2pkh and just code up the bech32 directly into that which will be of course a mess
< gmaxwell>
how would it do that? the bech32 won't decode as base58.
< gmaxwell>
even with an invalid checksum.
< conman>
yeah that's what I mean, it will explode
< gmaxwell>
okay, fair enough.
< gmaxwell>
I could see paying to an empty address or 0x00 or something as a result.
< conman>
exploding is actually preferable to that :P
< gmaxwell>
(though man, that would be fragile!)
< conman>
heh
< gmaxwell>
in any case, it's pretty straight forward to convert BC1 addressesto scriptpubkeys.
< conman>
yeah that's what I need to figure out how to do
< gmaxwell>
about the only gotcha is that the v0 vs other versions gap due to script. There are test vectors that tell you what the resulting scriptpubkey should be.
< * gmaxwell>
bbl
< conman>
ty
< conman>
hmm is there a core rpc that converts it to scriptpubkeys?
< conman>
I guess I need to investigate for myself
< conman>
ok decode is one function, no rpc for it tho afaics
< sipa>
conman: validateaddress will give you the scriptpubkey iirc
< conman>
oh? That's awesome
< conman>
indeed it does
< conman>
I should pay attention :P
< conman>
I seem to be duplicating work already done
< conman>
oh and it returns the decoded address already
< sipa>
what do you mean by decoded address?
< conman>
bech32
< conman>
no?
< conman>
I'm looking at the function, not actually trying it
< sipa>
if you give it a p2sh-p2wpkh, and it knows the script (which means it's your own address, really), it will report the embedded p2wpkh address
< conman>
okty
< conman>
ok this should be easy, check the validateaddress return value of "isscript" and then use the pubkey it returns with it
< conman>
can consolidate and remove some of my duplicate code
< sipa>
conman: why do you need to know of something is a script?
< sipa>
isscript will also return true for p2wsh
< conman>
sipa: because I'm generating transactions
< conman>
sec
< sipa>
i'd expect that you'd need to put the scriptPubKey in the output?
< conman>
I have two functions to determine what to put into the coinbase generation transaction
< kallewoof>
wumpus: we are in feature freeze right now, right? (was thinking of #10267)
< gribble>
https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
< sipa>
kallewoof: 0.16 is branched ofd
< sipa>
so i don't think there is any freeze on the master branch, just not a lot of focus
< kallewoof>
sipa: ah, okay, cool :)
< Randolf>
We need to be careful about updating copyright dates, and extending "2017" to a range of "2017-2018" instead of merely replacing with a new year of "2018." I made these comments in this PR, but also mention it here in case someone else also encounters a year that needs updating elsewhere:
< dafuq>
a pull request that changes the type of a variable in the code would fall under what prefix?
< dafuq>
not really trivial?
< bitcoin-git>
[bitcoin] murrayn opened pull request #12351: Libraries: Use type more precisely indicating usage and avoid compilers warnings. (master...ptrdiff_t) https://github.com/bitcoin/bitcoin/pull/12351
< bitcoin-git>
[bitcoin] Empact opened pull request #12357: Rationalize the CValidationState interface by splitting ::DoS across ::Invalid and ::Corrupt (master...validation-state-corrupt) https://github.com/bitcoin/bitcoin/pull/12357
< BlueMatt>
afaict you should absolutely be able to hit that same case in 0.15.1
< BlueMatt>
just as long as your disk is somewhat slow to get the first block loaded before you can quit
< BlueMatt>
oh, err...wow that's one hell of a race, you have to manage to kill right after pcoinsTip is created after the db is loaded and emptied and before the ActivateBestChain call in LoadChainTip (so that it returns from the ShutdownRequested() check)
< jtimon>
so jnewbery, regarding #12360, do we want to remove bip9? don't we want to reuse that code for bip8 ?
< jtimon>
nevermind you're just removing tests related to csv it seems, perhaps conserve some parts of feature_bip9_softforks with the dummy deployment?
< cfields>
BlueMatt: unsure. I hit it last night and didn't have time to look at it deeply, I just didn't want to forget about it. Looking now
< cfields>
BlueMatt: I assumed it was a regression caused by the FlushStateToDisk changes in init, but sure, maybe it's unrelated
< jnewbery>
jtimon: feature_bip9_softforks only tests CSV. it was never extended to test other bip9 deployments. It's also written using the comparison test framework, so i think it should just be removed
< jtimon>
jnewbery: makes sense, thanks, we have the unittests for the dummy deployment anyway
< arubi>
if anybody's got some spare time for more review on #12315 or #12321, I'd appreciate your input