< BlueMatt> (comment text from above link https://github.com/bitcoin/bips/pull/423#issuecomment-245629813 )


< GitHub97> [bitcoin] jl2012 closed pull request #8533: Implement LOW_S and NULLDUMMY softfork (BIP146) (master...bip146) https://github.com/bitcoin/bitcoin/pull/8533


< petertodd> sdaftuar: yeah, obvious one would be to just do replacements if vout #1 == vout #2 regardless of BIP125, which handles malleability just fine
< sipa> empty invalid was not part of bip62
< GitHub130> bitcoin/0.12 40e81f5 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
< gmaxwell> yea, I was looking at the BIP31 changes and scratching my head.
< sipa> but he kills pre-bip31 nodes as well, which dates from 2012


< sipa> the bip32 support is very very basic
< sipa> bitcoin core does not implement bip44
< murch> sipa: I had read part of the discussion on the BIP status updates on the dev list. There was a bit about the gap limit there and I assumed that Bitcoin Core also implements BIP44.


< gmaxwell> I think too many speculative things are going for "BIP" now, this isn't really what the bip process is intended for. BIPs shouldn't be for speculative ideas. They should be so that implementations are documented and can interoperate.


< sipa> i think consensus change BIPs should have completely separate states
< btcdrak> also in some ways BIPs can be finalised by their authors, as in, they are not taking any more changes, so it is final, but that also doesnt reflect usage.
< btcdrak> The issue with BIPs is there are clearly two different tracks. but the workflow only covers on. there are consensus BIPs which have a clear objective state that doesnt really include accepted. Then there are non consensus BIPs which get adopted by a large chunk of the ecosystem, like BIP32 & BIP44


< luke-jr> BlueMatt: https://github.com/bitcoin/bips/pull/423 thoughts?


< jl2012> jonasschnelli: yes in the current BIP146
< kanzure> what is the request about bip146 about?
< kanzure> is the request re: bip146 for more review?
< wumpus> #topic BIP146
< jl2012> proposed topic: BIP146.
< jl2012> Without his patch, bip164-p2p.py will fail


< GitHub170> [bitcoin] jl2012 closed pull request #8514: Enforce LOW_S rules on all transactions with WITNESS BIP9 parameters (master...lows) https://github.com/bitcoin/bitcoin/pull/8514
< GitHub166> [bitcoin] jl2012 opened pull request #8533: Implement LOW_S and NULLDUMMY softfork (BIP146) (master...bip146) https://github.com/bitcoin/bitcoin/pull/8533
< luke-jr> jonasschnelli: used to be part of https://github.com/bitcoin/bips/pull/362, right?
< jonasschnelli> luke-jr: requesting BIP number for the authentication BIP: https://github.com/jonasschnelli/bips/blob/2016/07/auth_bip/bip-undef-0.mediawiki


< sipa> Chris_Stewart_5: also post BIP66
< Chris_Stewart_5> Is this the function that was used to check encoding pre BIP66?
< kanzure> jonasschnelli: re: peer authentication bip, https://github.com/jonasschnelli/bips/pull/1


< GitHub95> [bitcoin] jl2012 opened pull request #8514: Enforce LOW_S rules on all transactions with WITNESS BIP9 parameters (master...lows) https://github.com/bitcoin/bitcoin/pull/8514


< wumpus> in any case BIP152 has the number: A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are added: sendcmpct, cmpctblock, getblocktxn, and blocktxn.
< wumpus> does it cost a node a lot of resources to verify BIP66 compliance? if not, why does it warrant DoS banning?
< jtimon> instagibbs: also bip66, bip65 and bip112, no?
< sipa> so that's why BIP66 is not part of mandatory flags
< sipa> and we would ban them if they send a BIP66-invalid transaction, for example
< wumpus> #topic raising mandatory script flags to include bip66
< kanzure> luke-jr: that's at best an argument for your segwit bip9 activation decoupling idea.
< jtimon> if they go in the same release, why separate them in the bip9 sense?
< jtimon> I mean, we can also deploy low-s in, say 0.12.2 before segwit (oh, wait, backport bip9)
< luke-jr> (separate in the BIP9 sense, not necessarily a different release)
< luke-jr> (huh, it occurs to me - not a real suggestion - that we *could* have de-bundled the block size increase from segwit into a separate BIP9 bit, so long as all deployment of segwit included support for the separate blocksize-increase bit; IMO interesting)
< instagibbs> (duh, bip9)
< instagibbs> Oh, if the two bip9 aren't packaged, I think we should
< wumpus> sipa proposed some topics earlier today: 1) segwit policy limits 2) can we propose a softfork to make low-s required simultaneously with segwit? 3) 3) raising mandatory script flags to include bip66 4)
< sipa> wumpus: just so i don't forget, a few topics for the meeting 1) segwit policy limits 2) can we propose a softfork to make low-s required simultaneously with segwit? 3) raising mandatory script flags to include bip66?
< sipa> but mandatory doesn't even include BIP66


< cfields> got it. Ok, I'll PR a few clarifications there. Was trying to implement soley based on reading of bip9 changes.
< cfields> luke-jr: (i'm implementing the bip9 gbt changes in ckpool)
< GitHub7> [bitcoin] laanwj closed pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< GitHub52> bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
< GitHub120> [bitcoin] luke-jr opened pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< jonasschnelli> gmaxwell: I guess theres nothing holding back power users of doing this with the current bip151 (+auth) specification..
< gmaxwell> largely unrelated to BIP151 there is a question of it you'd like to have long lived node identities.
< sipa> gmaxwell: well in light of bip151... should they also carry a host pubkey?
< GitHub114> [bitcoin] laanwj closed pull request #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (master...bugfix_gbt_sigops_presegwit) https://github.com/bitcoin/bitcoin/pull/8489
< GitHub4> bitcoin/master edebf42 Wladimir J. van der Laan: Merge #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT)...
< GitHub4> bitcoin/master 160f895 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates


< GitHub3> [bitcoin] luke-jr opened pull request #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (master...bugfix_gbt_sigops_presegwit) https://github.com/bitcoin/bitcoin/pull/8489
< sipa> Chris_Stewart_5: bip37


< jonasschnelli> gmaxwell: sipa: I guess the current bip151 rekeying has no forward secrecy. It's hash(old-sym-key). What about hkdf(ecdh_secret, old_syn_key) instead?


< sipa> paveljanik: bip112
< jtimon> bip113 was deployed separately
< sipa> at the block/tx level, you'd have bip16, bip34, bip66, bip65, bip68_112_113, bip141
< jtimon> why are bip68_112_113 together?
< jtimon> agree on what you said about the caller, disagree that I want to expose more details than necessary to the caller, I'm happy to merge bip68 and bip112 flags, that seems orthogonal
< jtimon> but you don't want verifyScript to receive a CSV_bip68_bip112 flag that it internally maps to SCRIPT_VERIFY_CHECKSEQUENCEVERIFY (ignoring bip68 because at the script level it doesn't care)
< jtimon> I see, you want the block level ones to correspond with deployments, ie bip68 and bip112 go together
< sipa> and BIP16 would map to script verify P2SH
< jtimon> well, the flags for BIP68 and for BIP112 are separated in that branch
< jtimon> say I want to call verifytx specifying that I want p2sh and bip113 validated
< jtimon> there's no flag for say bip68 and bip113, because thouse would be needed for verifyTx, but not for verifyScript
< jtimon> well, what we're exposing in libconsensus are the BIP9/older_sf flags, no?
< sipa> there would be SCRIPT_VERIFY_CHECKSIGAWESOME, and a BIP9 deployment AWESOME
< morcos> "If a miner wishes to limit the actual size of a block in bytes then it is necessary to specify a blockmaxsize explicitly. If a miner wishes only to limit block creation by weight (BIP141) regardless of how large in bytes the block is they should only specify a blockmaxweight"


< jtimon> /** Block hash at which BIP34 becomes active (for BIP30 optimization)*/
< jtimon> uint256 BIP34Hash;
< jtimon> NicolasDorier: you are not removing BIP34Height BIP65Height and BIP66Height in Consensus::Params
< NicolasDorier> jtimon: I think one bool is enough. fAllowOverwriteSoftforks which both BIP9 and buried SF use
< NicolasDorier> -buriedsfparams=bip65:1351 -buriedsfparams=bip66:1251
< jtimon> NicolasDorier: in #8460, how do you modify a couple of them? -buriedsfparams=bip65:1351,bip66:1251 ?
< jtimon> NicolasDorier: cool, but I believe the right time was in your PR, at least with the new ones if you didn't wanted to touch bip34
< jtimon> well, maybe the time for https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 is whenever bip113 activation is simplified from bip9 in the same way
< jtimon> if we knew we weren't doing it, we could have made https://github.com/jtimon/bitcoin/commit/6f98197634026e740a9172405386b15c3a79b5a5 without bip34 directly in #8391...
< jtimon> the advantages are code simplification and a slight optimization (really no need to call GetAncestor if you don't care about the hash), and keep the optimization in case of pre-bip34 reorg, which is arguably a disadvantage
< jtimon> so, yes, theoretically always checking bip30 after bip34 has certain risk if there's that reorg...but aren't we screwed if that happens anyway?
< morcos> checking BIP30 is exteremely slow
< morcos> jtimon: yes you can either always check BIP30 even after BIP34, or you can examine the chain you're on pre BIP34 and decide whether you can now skip BIP30 checks (which is what we decided to do with mainnet, but requires manual intervention)
< morcos> are you opposed to leaving in the BIP34 hash
< jtimon> my node would not check bip30 after bip34, even after the reorg
< jtimon> and then a node without my change would always check bip30, even after bip34 activation, is that the desired behaviour?
< morcos> you can try this on regtest.. enforce BIP30 only up to height 100 and BIP34 only starting at height 100. create some coinbases, spend them and then create duplicates before 100.
< jtimon> yes, from now on you can stop checking bip30 in new blocks
< morcos> then you can spend A' and create the same txid as your spend of A b/c you aren't enforcing BIP30 any more
< morcos> then you create coinbase A' (allowed b/c it doesn't violate BIP30 , A is spent, and BIP34 is not active yet)
< morcos> now you activate BIP34 at height 227931
< jtimon> after bip34 activation, it is no longer necessary
< jtimon> bip 30 is checked before bip34 always except the exceptions
< jtimon> in a reorg that deep, if it was activated with another block, then bip30 will be checked always regardless of bip34 activation (no optimization, never)
< jtimon> with my suggested change, it would always do the optimization after bip34 activation height, even after such a long reorg
< jtimon> what is doing now is that if you are above that height and the block you activated bip34 in is 227931, then don't enforce bip30 since bip34 is enforced
< morcos> maybe because BIP30 is enforced for everythign except those two exceptions you're ok
< jtimon> and what we have now, if it reorgs that long, without code for ISM...what? bip34 is going to be activated at that height no matter what
< jtimon> I think it will only fail if we reorg below BIP34Height (227931)
< morcos> jtimon: its incorrect in that it'll be broken code on a mainnet chain that doesn't contain BIP34hash
< morcos> i can't remember off the top of my head, but if in an alternate chain you spent coinbase A before you generate coinbase A' then you activated BIP34, then you still need BIP30 to make sure the spend of A' doesn't conflict with the spend of A
< morcos> but in the BIP34hash chain we know that didn't happen
< morcos> if you activated BIP34 at the same height on a different chain, it would be unclear whether yous till needed to do BIP30
< morcos> jtimon: no, when you use BIP34 on the existing BIP34 hash then you dont' need to do it
< jtimon> you cannot remove it completely, but when you use bip34 you don't need to do it (this is current behaviour)
< morcos> you can't remove the BIP34Hash unless you are going to checkpoint the chain at that point
< sipa> isn't there some interaction between BIP30 and the no-overwrite optimization in coinscache?
< sipa> which needs a BIP30 check during IBD
< NicolasDorier> morcos: so basically we could remove BIP30 altogether as this is unlikely another chain manage to catch up the amount of work of the current one
< morcos> It's related. The point is once you are enforcing BIP34 then BIP30 is unnecessary except for historical violations. We're changing the rule to have BIP34 be enforced as of a certain height, however, it kind of requires that the chain be the same otherwise we dont' know what the historical violations are or might be
< NicolasDorier> I have a code question: I'm working on a commit similar to one from jtimon, he is removing one check here https://github.com/jtimon/bitcoin/compare/remove-ism...consensus-post-remove-ism#diff-7ec3c68a81efff79b6ca22ac1f1eabbaL2353 about BIP30, does somebody know if it is actually safe to do so ?
< gmaxwell> instagibbs: so without the bip32 changes?


< GitHub95> [bitcoin] laanwj closed pull request #8446: [Trivial] BIP9 parameters on regtest cleanup (master...20160802_shadow_bip9params) https://github.com/bitcoin/bitcoin/pull/8446
< GitHub141> bitcoin/master ced2d5e Wladimir J. van der Laan: Merge #8446: [Trivial] BIP9 parameters on regtest cleanup...


< GitHub103> [bitcoin] paveljanik opened pull request #8446: BIP9 parameters on regtest cleanup (master...20160802_shadow_bip9params) https://github.com/bitcoin/bitcoin/pull/8446
< GitHub156> bitcoin/master 56c87e9 Suhas Daftuar: Allow changing BIP9 parameters on regtest


< michagogo> My first thought was, wtf? Why is a list of BIPs its own package?


< GitHub133> bitcoin/0.13 8360d5b Jorge Timón: libconsensus: Expose a flag for BIP112...
< GitHub127> [bitcoin] sipa closed pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412
< GitHub106> bitcoin/master ad08763 Pieter Wuille: Merge #8412: libconsensus: Expose a flag for BIP112...
< GitHub106> bitcoin/master d12b732 Jorge Timón: libconsensus: Expose a flag for BIP112...
< sipa> jtimon: i vaguely remember there were ugly interactions between the cache code that avoids some database operation, bip30 and bip34... but i don't remember the details
< NicolasDorier> jtimon: I'd like to see it go personally, but I don't know the reason why bip34Hash was here in the first place
< sdaftuar> it has one changed behavior, the new command line option -bip9params


< jtimon> never mind, updated without bip112 at the end
< GitHub48> [bitcoin] jtimon opened pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412


< da2ce7_mobile> yeah. It would be great if BIP44 had a 'hardened only' option.
< jonasschnelli> gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
< jonasschnelli> I just think people would like to stick to bip44 or something in order to use the seed in other wallets once they want to move away from Core


< goatpig> also I see in BIP151 that it allows for negotiating the cypher, so will it support AES-GCM too?
< goatpig> anyone here familiar with the BIP151 discussion?
< goatpig> you mean the stuff in the example section of bip141?
< achow101> these are defined in bip141
< goatpig> there was nothing about changes in txout format in the bips so i was a bit confused
< sdaftuar> you're looking at bip144 i assume?


< gmaxwell> luke-jr: dude, wtf why are you whining about things like this https://www.reddit.com/r/Bitcoin/comments/4u38yt/bitcoins_nervous_system_gets_an_upgrade_with/d5mnpg9 when I can't even get you to test things like BIP152 and createnewblock improvements?


< jtimon> bip34Hash can still be deleted, right?


< jtimon> it will be replaced and we can leave it all preapare for where it will be replaced with something like bip34 and that will simplify things, I believe
< sdaftuar> i wonder if there are cases where we might want to test how a chain behaves when some blocks don't satisfy a rule (like bip34) and then later ones do.
< gmaxwell> sipa: see consensus.BIP34Height = 227931;
< jtimon> but I still believe that the refactor is much simpler if we put temporarily the locktime flags and the new ones (bip30 and bip34) in the script flags and then we separate them
< jtimon> sipa: I've been thinking more about the consensus vs script flags, I guess it has the advantage of having a much shorter list of consensus flags, basically only one per consensus deployment (well, we can keep bip68 and bip112 as separated flags), while the script flags have many more thant in principle don't need to be exposed in libconsensus
< jtimon> Ideally we would use an array, I wish I had seen the PR for BIP34 when it was open...
< jtimon> NicolasDorier: yeah, hardcoding the activations in Consensus::Params like CodeShark did with bip34, the other day gmaxwell said he was working on suh a branch


< instagibbs> I just tested the bip143 examples, so please test :)
< arubi> what about tracking using bip32? that's what I'm doing now so suddenly I think it's good for everything :)
< sipa> check bip9 status at tip.GetAncestor(144) instead of at tip
< jl2012> technically speaking, people could use native segwit with BIP70
< jonasschnelli> phantomcircuit: I guess you are refering to one of my closed PR Bip32 PRs?
< GitHub168> bitcoin/0.13 1fe7f40 Cory Fields: build: fix non-deterministic biplist...
< GitHub99> [bitcoin] laanwj closed pull request #8373: Fix OSX non-deterministic dmg (master...biplist-determinism) https://github.com/bitcoin/bitcoin/pull/8373
< GitHub21> bitcoin/master 3b3ce25 Cory Fields: build: fix non-deterministic biplist...


< GitHub16> [bitcoin] theuni opened pull request #8373: Fix OSX non-deterministic dmg (master...biplist-determinism) https://github.com/bitcoin/bitcoin/pull/8373
< sipa> BlueMatt: the alternative for the bip32 derivation is that we'd use the private key of the generated root as master key (with chaincode stored on disk), rather than treating it as a seed
< sipa> bip32 does not have any


< wumpus> there's also at least one other implementation of segwit that will have to be changed with the BIP141 change (the btcd implementation)
< sdaftuar> it seems strange to me that we'd choose to redefine a term...? at the least we'd have to say "total BIP141-sigops" or something
< wumpus> maybe just change the help message to "Set maximum BIP141 block cost"
< wumpus> e.g. generating errors like 'this wallet uses BIP32 which is not supported in this version'


< btcdrak> I think we should update softfork BIPs directly with activation heights.
< btcdrak> jtimon: I dont have any objection to consensus/flags.h - i only have an objection to stuffing unrelated things into units which have a specific purpose. versionbits.cpp is clearly for BIP9 logic. I would have thought this is self evident :-p :)
< gmaxwell> jtimon: yes the if statement at the top changes, e.g. into nheight >= consensusParams.bipblahblahHeight -- the check itself would logically remain in ContextualCheckBlock.
< gmaxwell> just elements of consensus. consensus.BIP65Height yadda yadda.
< gmaxwell> consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8");
< gmaxwell> consensus.BIP34Height = 227931;
< jtimon> but vDeployments uses BIP9


< jl2012> bsm2357: there are some test vectors in BIP143
< sipa> bip143 does not affect the behaviour of code separators
< bsm2357> Ok then client code. (I'm copying test cases from BIP143)
< jonasschnelli> sipa: while you are around (heh!), mind doing a quick review on https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/bip151_hkdf? Only technical, language will be checked by Jonathan Cross


< sipa> xinxi_: read BIP9 about how to deploy it
< sipa> (as can the new script versions introduced by BIP143)
< sipa> xinxi_: BIP143 (which we're in the process of finished up) makes that very easy
< jtimon> bip2 tries to clarify things, but it can only decided on whether something was "accepted" or not observing adoption a posteriori. BIP99 also tries to clarify things, but it's based on a vaguely defined concept of "uncontroversial"
< sipa> BIP34 used block versions above a certain number to let miners indicate they are enforcing the new rules
< sipa> BIP30 used a fixed timestamp for the changeover point
< jtimon> xinxi_: for softforks bip9 describes it, for hardforks there's different opinions on what would be the best way to signal activation
< sipa> xinxi_: there is also BIP50 which is a post-mortem of a consensus failure that occurred between old and new versions of the system
< sipa> (BIP9 is newer)
< sipa> a soft fork: read BIP34 and BIP9
< jtimon> for example, the code in bip99 fixes a known bug which is not a priority
< jonasschnelli> sipa, gmaxwell: maybe you find time to quickly review the BIP151 switch from HMAC_SHA512 "KDF" to HKDF: https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/bip151_hkdf?expand=1
< jtimon> I was working on https://github.com/jtimon/bitcoin/commits/jt but I broke the branch when backported bip9 and never cared to fix it (but review is still very welcomed since I plan to rewrite/cherry pick most of the stuff from there)


< bsm117532> sipa: okay, I'm comparing to your bip141 which writes scriptPubKey as: 0 <20-byte-key-hash>, but obviously b'' <20-byte-key-hash> is equivalent.
< sipa> or through the bip35 mempool command


< btcdrak> yes, he means BIP66
< sipa> and it triggered when bip65 activated
< sipa> not bip66, which was a year earlier
< Chris_Stewart_5> sipa: I just read the email, however the hard fork last July wasn't related to the implementation of BIP66 , it was just spv mining correct?
< sipa> xinxi: have you read my BIP66 writeup above?
< Chris_Stewart_5> Bip66 (or was it 62) comes to mind
< jtimon> that's useful, what about the bip34 check in ContextualCheckBlock(), can it be moved out?
< sipa> validating bip113 is not necessary i think
< jtimon> if we know it's not making a longer chain, why bother validating BIP113 ?


< GitHub189> [bitcoin] laanwj closed pull request #8303: [Doc] Update bips.md for CSV softfork. (master...bips-csv-softfork) https://github.com/bitcoin/bitcoin/pull/8303
< GitHub127> bitcoin/master 5077d2c Wladimir J. van der Laan: Merge #8303: [Doc] Update bips.md for CSV softfork....
< GitHub127> bitcoin/master ab0c35a fanquake: [Doc] Update bips.md for CSV softfork.


< sipa> bip144 adds an extra serialization flag that is not hashed into the txid
< jonasschnelli> gmaxwell, sipa: Bip151: what do you think by using HKDF instead of a single SHA_HMAC to derive the symmetric cipher key from the ECDH secret?


< sipa> how to serialize the witness data, read bip144


< GitHub121> [bitcoin] fanquake opened pull request #8303: [Doc] Update bips.md for CSV softfork. (master...bips-csv-softfork) https://github.com/bitcoin/bitcoin/pull/8303


< btcdrak> just generate blocks, bitcoind will set and unset the bit. you can see examples here https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/bip9-softforks.py


< dgenr8> The partition risk to XT is a result of your sneak attack on its usage of bip37 for the original thin blocks mechanism. Thanks for that.


< gmaxwell> K. indeed 0.12 doesn't have BIP152. Perhaps that does suggest that it should default to four million in 0.13?
< gmaxwell> luke-jr: we have BIP152 now.
< jl2012> arubi: without BIP62, that's not reliable
<@wumpus> at least for BIP32, in contrast to coin selection, the goal is well-defined and delimited :)
<@wumpus> yes, that is true, ideally that should use some BIP32 construction


< sipa> 2) needs some BIP changes (in BIP144, BIP152, or a separate bip entirely)
< sipa> 1) this allows us to test interaction between non-SW-BIP152 testnet and changed
< petertodd> gmaxwell: as in, segwit bip152 right? +1
< gmaxwell> #topic BIP152
< sdaftuar> maybe bip152?


< gmaxwell> yes, thats an initially useful application, though we should also be considering directing our attention toward reducing relay overhead, because with BIP152, it's now the biggest user of bandwidth on a listening node.


< dgenr8> the best thing for bitcoin is for you guys to adopt bip109
< dgenr8> so "yes" then? (since not only bip9 but anything in the block header is showing miner support)
< sipa> dgenr8: i believe bip9 is unsuitable for hardforks
< sipa> for a hardfork you don't nedd bip9
< GitHub19> [bitcoin] laanwj closed pull request #8258: RPC: Hide softfork if timeout is 0 (master...bip9rpcdisable) https://github.com/bitcoin/bitcoin/pull/8258
< gmaxwell> if it were 109 I would have expected it to not trigger BIP9 due to the longer activation window and higher trehshold.
< sdaftuar> wumpus: i assume the bit 28 activation on TESTNET is a bip109 thing (nothing to do with TESTDUMMY, which inadvertently reused the same bit)


< GitHub53> [bitcoin] jl2012 closed pull request #8209: Showing "not_applicable" if BIP9 timeout is 0 (master...patch-13) https://github.com/bitcoin/bitcoin/pull/8209
< GitHub9> [bitcoin] jl2012 opened pull request #8258: RPC: Hide softfork if timeout is 0 (master...bip9rpcdisable) https://github.com/bitcoin/bitcoin/pull/8258
< GitHub54> bitcoin/master 449f9b8 Pieter Wuille: BIP141: Witness program
< GitHub54> bitcoin/master 7030d9e Pieter Wuille: BIP144: Serialization, hashes, relay (sender side)...
< sipa> and then there is bip130, which introduces direct fetch in response to headers


< gmaxwell> and part of the reason why BIP9 flag changes happen at retargets is to make the header unpredictable at the same time the bits change makes it unpredictable.
< da2ce7_mobile> I really like BIP9. It is a really elegant solution and upgrade.
< gmaxwell> Because past softforks would orphan your blocks if you had the wrong version. We specifically got rid of that behavior in BIP9 in part to discourage faking the versions, but this improvement is not yet well understood and the software is already written.
< sipa> da2ce7_mobile: BIP9 suggests that they don't
< gmaxwell> Miners are turning off their BIP9 signaling manually (which is what I was fussing about a few days ago). It's no longer required as it locked in.
< da2ce7_mobile> has something happened to sipa's node, or the BIP9 chart looking very werid: http://bitcoin.sipa.be/ver9-2k.png
< gmaxwell> And sure, on _mainnet_ having consensus rules change without released software would be _insane_, thats why BIP9 got a starting date... but for testnet, that can make sense.
< btcdrak> CodeShark: they are already documented: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
< jtimon> are we merging the bip9 activation parameters for testnet?
< GitHub103> [bitcoin] laanwj closed pull request #8246: trivial: capitalize BIP32 in option help (master...2016_06_bip32_uppercase) https://github.com/bitcoin/bitcoin/pull/8246
< GitHub70> bitcoin/master 147a7b6 Wladimir J. van der Laan: Merge #8246: trivial: capitalize BIP32 in option help...
< GitHub70> bitcoin/master a1c92c2 Wladimir J. van der Laan: trivial: capitalize BIP32 in option help...
< GitHub7> [bitcoin] laanwj opened pull request #8246: trivial: capitalize BIP32 in option help (master...2016_06_bip32_uppercase) https://github.com/bitcoin/bitcoin/pull/8246


< sipa> but for example, #7935 introduced the concept of gbt_force (bip9 rollouts which the GBT client needs explicit support for)
<@wumpus> is there any way to see (in the GUI or through RPC) if a wallet is BIP32?
< gmaxwell> is true is 224413, which seems to suggest that the BIP34 height in the chainparams is wrong?
< sipa> btcdrak: bips.md has more info
< btcdrak> gmaxwell: do you mean BIP34? according to the BIP text "Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block."
< btcdrak> luke-jr: maybe we should update the BIPs with activation blocks when they activate
< btcdrak> gmaxwell: BIP65 was activated on block #388380
< gmaxwell> Anyone have exact IsSuperMajority heights for BIP30/65/66 on mainnet and testnet handy, by any chance?


< jl2012> i think all transactions including coinbase are subject to nLockTime and BIP113 rules
< jl2012> 4. make sure the coinbase tx compiles with BIP113 (in case someone use nLockTime for mining --> unlikely)
< jl2012> 3. make sure the coinbase tx compiles with BIP68
< jl2012> Some miners didn't really understand bip9
< gmaxwell> So the expectation with bip9 was that since it was no longer forced there would be no incentive to lie, and at least the measure of upgrade status would be faithful.
< gmaxwell> This is seriously fucked up, miners signaling versions inconsistent with the consensus rules they were running already forked the network once and narrowly avoided an incident. BIP9's design was partially motivated in avoiding that. (with no "set version or get orphaned" the beliefe was there would be no reason to fake it.
< gmaxwell> I thought BIP9 got us there, but apparently I was mistaken. An intended feature of the design isn't working.
< gmaxwell> if it's most of the hashpower it means that BIP9 is a currently failed design. The initial switch to signal CSV was _Exactly_ at the starting time, so I felt confident that the version numbers weren't being faked.
< gmaxwell> I think BIP9 is too unsafe to use with parties manually setting the bits. The issue is if they have old nodes that don't enforce the consensus rules and they're failing over to them and getting work from them it can split the network, and it would be completely silent.
< gmaxwell> Since we're now aware of miners manually setting version bits we should start work on a new deployment mechenism and depricate BIP9. :(
< jl2012> just want to confirm: during bip9 locked_in, blocks with any nVersion >=4 are valid?


< btcdrak> BIP9 spec
< btcdrak> see BIP112
< btcdrak> BIP141
< spudowiar> I'll check them BIPs out
< btcdrak> spudowiar: the current softfork bundle of BIP68,112,113.


< luke-jr> sipa: something to trigger BIP9-aware clients not to try merging the template
< Chris_St1> sdaftuar: So BIP9 parameters need to be set in the pull request before being merged into master correct?
< gmaxwell> Chris_St1: BIP9 starting date, yes.
< Chris_St1> 'activation' is wrt BIP9 right?
< GitHub121> [bitcoin] jl2012 opened pull request #8209: Showing "not_applicable" if BIP9 timeout is 0 (master...patch-13) https://github.com/bitcoin/bitcoin/pull/8209


< jonasschnelli> hmm... importwallet of a new bip32 dumped wallet will just import the keys and not the "hdness"...


< GitHub22> [bitcoin] laanwj closed pull request #8035: [Wallet] Add simplest BIP32/deterministic key generation implementation (master...2016/05/simplest_hd) https://github.com/bitcoin/bitcoin/pull/8035
< GitHub46> bitcoin/master 17c0131 Jonas Schnelli: [Docs] Add release notes and bip update for Bip32/HD wallets
< GitHub46> bitcoin/master c022e5b Jonas Schnelli: [Wallet] use constant for bip32 hardened key limit
< GitHub46> bitcoin/master f190251 Jonas Schnelli: [Wallet] Add simplest BIP32/deterministic key generation implementation


< MarcoFalke> When the bip32 stuff is merged, we should make sure the test framework still runs the legacy wallet sometimes
< jonasschnelli> sipa: Re bip32: You mentioned if users set -usehd=1 it should detect and abort when running on a non HD wallet.


< GitHub176> [bitcoin] MarcoFalke opened pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186
< gmaxwell> I think important big PRs I'd really like to have in 0.13 are SW, Compact blocks, CFPF related, and BIP32.
< gmaxwell> If the digests idea had come up at the time of BIP37, I think it would have been implemented and filtering of relayed transactions wouldn't have been.
< gmaxwell> dgenr8: the addition of filtering the current transactions was a 12th hour addition to BIP37, and for many users saving an average of 13kbit/sec for a total loss of privacy is not all that interesting just to see unconfirmed transactions that their wallets can't even tell are at all remotely possily correct.


< gmaxwell> BIP152 actually adds a sutiable mechenism-- getblocktxn that fetches txn in a block by index, that only works for recent blocks.
< GitHub123> bitcoin/master 72cd6b2 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates


< sipa> luke-jr: good thing BIP8 was never assigned https://en.wikipedia.org/wiki/BIP-8 (image what would happen if something related to error correction or checksums got that...)



< sipa> BIP130 also does not use a service bit


< sipa> A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
< sipa> jl2012: feel like updating bip141 for the program size extension?
< sipa> oh, the limit is not included in bip141
< Chris_Stewart_5> Are BIP141,143,144 finalized? Or is this witness program extra byte thing going to affect one of them?


< btcdrak> The codebase is significantly different between 0.11 and 0.12 with regards to BIP68
< btcdrak> luke-jr: morcos specific concern was the safety of BIP68 backport