< 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
< conman> address_to_pubkeytxn and address_to_scripttxn is what I currently use
< conman> it's extremely braindead
< sipa> right, but for p2wsh and p2wpkh you'll need more
< conman> hrm that's what I feared
< sipa> there is reference c code for doing that, btw
< conman> I must be looking in the wrong places
< conman> ty
< sipa> it's listed in the bip
< conman> that's to decode, understood thanks
< sipa> it does both
< conman> but I'm still fuzzy on what extra is needed on creating a generation transaction from a decoded segwit address as opposed to a p2sh address
< conman> you say I'll need more
< sipa> yes, it needs to be a segwit output
< sipa> it's not hard
< sipa> but it will be different logic
< sipa> it OP_0 + 20-byte push for P2WPKH
< sipa> and OP_0 + 32-byte push for P2WSH
< conman> ah
< conman> so if there was a current p2wsh address in the coinbase txn in my current code's form it would go to a random nowhere
< sipa> presumably
< sipa> i didn't look very closely
< conman> :\
< conman> that's okay
< luke-jr> how would a p2wsh address get in the txn if you don't put it there?
< conman> huh?
< conman> it just applies the existing logic for any 3x address to all 3x addresses
< conman> in a braindead fashion
< luke-jr> all 3x addresses should work with your code; I think sipa is talking about the new bc1 addresses
< conman> hrm
< sipa> yes,p2sh-p2wpkh addresses are for the sender indistinguishable from p2sh addresses, by design
< conman> okay so it's still okay
< sipa> i'm talking about bech32 address, which encode p2wsh and p2wpkh addresses, without bech32
< conman> yeah so once bech32 is decoded, what to do with it then is what I'm still coming to grips with
< luke-jr> sipa's reference code has: int segwit_addr_decode(int* witver, uint8_t* witdata, size_t* witdata_len, const char* hrp, const char* addr)
< luke-jr> test to be sure, but I think you can just concatenate the witver, witdata_len, and witdata
< luke-jr> to make the scriptpubkey
< sipa> the unit test code even demosnstrates that, actually
< sipa> it's not part of the reference itaelf, because in production wallet code it would likely tie in with existing scriot creation code already
< luke-jr> oh, right, you need to add 0x50 to any witver != 0
< conman> bech32 automatically guarantees it is a p2w* address?
< conman> oh my UPS hit
< * conman> wonders if he's still connected
< luke-jr> it guaranteed it's a native segwit address, at least
< luke-jr> conman: yes
< conman> thanks, it's coming and going
< luke-jr> if there's a p2w-random-other-mode added in the future, bech32 will probably support that too without change
< conman> ok
< bitcoin-git> [bitcoin] kien999 opened pull request #12350: i want (master...master) https://github.com/bitcoin/bitcoin/pull/12350
< bitcoin-git> [bitcoin] fanquake closed pull request #12350: i want (master...master) https://github.com/bitcoin/bitcoin/pull/12350
< 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:
< FTBCraig> ho
< Randolf> FTBCraig: ?
< FTBCraig> hi
< Randolf> Hello.
< dafuq> is it possible to get a log with the full output of a build? to see "g++ -Wall -whatever -o foo.o foo.c" instead of just "CXX foo.o"
< dafuq> also ho
< Randolf> dafuq: Do you have access to a tool called "script" (Unix, probably in Linux too)? If so, that should capture everything for you.
< dafuq> no the problem is I don't see the "g++ ...", just "CXX ..." (which is cleaner admittedly)
< kallewoof> dafuq: do V=1 make
< dafuq> cool, V for verbose?
< kallewoof> Yeah
< Randolf> You're asking to see the full commands. That's actually quite interesting to know that V=1 will expose that.
< dafuq> thanks kallewoof what I was looking for
< kallewoof> dafuq: great! :)
< Randolf> Nice!
< 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] murrayn opened pull request #12352: Libraries: Get rid of compiler warning (master...logging_warning_fix) https://github.com/bitcoin/bitcoin/pull/12352
< bitcoin-git> [bitcoin] fanquake closed pull request #12352: Libraries: Get rid of compiler warning (master...logging_warning_fix) https://github.com/bitcoin/bitcoin/pull/12352
< bitcoin-git> [bitcoin] fivepiece opened pull request #12353: Add fivepiece gpg key (master...add-fivepiece-gpg-key) https://github.com/bitcoin/bitcoin/pull/12353
< bitcoin-git> [bitcoin] fivepiece closed pull request #12353: Add fivepiece gpg key (master...add-fivepiece-gpg-key) https://github.com/bitcoin/bitcoin/pull/12353
< arubi> err sorry, wrong branch
< bitcoin-git> [bitcoin] fivepiece opened pull request #12354: add gpg key for fivepiece (master...add-fivepiece-gpg-key) https://github.com/bitcoin/bitcoin/pull/12354
< arubi> there we go
< bitcoin-git> [bitcoin] Empact opened pull request #12356: Fix 'mempool min fee not met' debug output (master...minfee-message) https://github.com/bitcoin/bitcoin/pull/12356
< 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
< bitcoin-git> [bitcoin] filips123 opened pull request #12359: Update license year range to 2018 (master...master) https://github.com/bitcoin/bitcoin/pull/12359
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12348: Update year to 2018 (master...master) https://github.com/bitcoin/bitcoin/pull/12348
< bitcoin-git> [bitcoin] jnewbery opened pull request #12360: Bury bip9 deployments (master...bury_bip9_deployments) https://github.com/bitcoin/bitcoin/pull/12360
< sipa> wumpus, mesh_: i went over the release notes and added some things about validateaddress
< sipa> and made some more edits
< BlueMatt> cfields: #12349 isnt a regression, right?
< gribble> https://github.com/bitcoin/bitcoin/issues/12349 | shutdown: fix crash on shutdown with reindex-chainstate by theuni · Pull Request #12349 · bitcoin/bitcoin · GitHub
< 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 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/12360 | Bury bip9 deployments by jnewbery · Pull Request #12360 · bitcoin/bitcoin · GitHub
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/12315 | Bech32 addresses in dumpwallet by fivepiece · Pull Request #12315 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12321 | p2wsh address in decodescript by fivepiece · Pull Request #12321 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d32528e733f2...2a30e67d20f7
< bitcoin-git> bitcoin/master c409b1a João Barbosa: [rpc] Reduce scope of cs_main and cs_wallet locks in listtransactions
< bitcoin-git> bitcoin/master 2a30e67 MarcoFalke: Merge #12330: Reduce scope of cs_main and cs_wallet locks in listtransactions...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12330: Reduce scope of cs_main and cs_wallet locks in listtransactions (master...2018-02-listtransactions) https://github.com/bitcoin/bitcoin/pull/12330
< BlueMatt> cfields: I dont recall any such changes in 0.16, though we did do a few late in 0.15
< cfields> BlueMatt: looks like you're right, I was thinking commit 3192975 was new for 0.16
< bitcoin-git> [bitcoin] fanquake closed pull request #11398: Hardcode CSV and SEGWIT deployment (master...csvburied) https://github.com/bitcoin/bitcoin/pull/11398
< bitcoin-git> [bitcoin] promag opened pull request #12361: Replace unreachable error handling with assertions in feebumber (master...2018-02-feebumper) https://github.com/bitcoin/bitcoin/pull/12361
< promag> ryanofsky: are you aiming at me?