< btcdrak> the BIP68 backport in particular is complex
< sipa> 17:19:13 < sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7948 (RPC: augment getblockchaininfo bip9_softforks data)
< sipa> My plan right now is making the BIP9/GBT changes, removing segnet, removing the positive witness flag, and then creating a parallel rebase
< sipa> ping for review: https://github.com/bitcoin/bitcoin/pull/7948 (RPC: augment getblockchaininfo bip9_softforks data)
< jonasschnelli> Also the auth bip should probably be done before starting with the bip151 implementation


< GitHub78> [bitcoin] sipa closed pull request #8121: [Doc] Update implemented BIPs list (master...missing_bips) https://github.com/bitcoin/bitcoin/pull/8121
< GitHub92> bitcoin/master 58f0c92 Pieter Wuille: Merge #8121: [Doc] Update implemented BIPs list...
< GitHub92> bitcoin/master e4f73c7 fanquake: [Doc] Update implemented BIPs list



< GitHub15> [bitcoin] fanquake opened pull request #8121: [Doc] Update implemented BIPs list (master...missing_bips) https://github.com/bitcoin/bitcoin/pull/8121


< sipa> #action jonasschnelli make it more clean that bip151 uses openssh's chacha20-poly1305 standard
< petertodd> re: bip151, I mentioned it today at the conf I was at to some cryptographers, and their response to it not being an off the shelf standard was horror :) might be a pr issue
< sipa> status bip151: waiting for implementation
< kanzure> maybe bip151 things?
< sipa> and it's optional per bip37


< jtimon> actually, maybe not a after bip9...


< sipa> Chris_Stewart_5: according to bip9 now, yes
< sipa> but bip9 is just a suggestion for future sofrforks
< sipa> bip9 specifies that it's the same as the retarget interval
< sipa> have you read bip9?
< Chris_Stewart_5> Gotcha. Sipa while we are at it can you elaborate a little more on the 'sampling interval' you eluded to on BIP9 I'm having a hard time understanding that. Is this just how often we check to see how much progress a soft fork has?
< sipa> and the bips repository is only under the same org as bitfoin core due to historical reasons
< sipa> Chris_Stewart_5: bips are not about implementations


< Chris_Stewart_5> Seems like it isn't defined in BIP9 unless I am missing something..
< Chris_Stewart_5> How long is a 'retarget period' in BIP9?


< GitHub123> [bitcoin] morcos closed pull request #7716: [0.11] Backport BIP9 and softfork for BIP's 68,112,113 (0.11...backportBIP9SoftFork) https://github.com/bitcoin/bitcoin/pull/7716
< jonasschnelli> Yes. We should be careful with what we add to the gui level. Maybe I was to focused on bip125 and thought its important to see it "everywhere". But right,... its not.
< gmaxwell> jonasschnelli: sure the rpc and such shows the BIP125 replacability status. My only concern was that we not do something like printing a warning.
< jonasschnelli> luke-jr: requesting BIP number assignment for Peer-to-Peer Communication Encryption (https://github.com/bitcoin/bips/pull/362/files) (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012599.html)


< Chris_Stewart_5> Question about BIP113, if I have a locktime transaction I need the locktime on that tx to be < the median block timestamp for the last 11 blocks correct?


< sipa> sha512 is included in the source code for the purpose of bip32 derivation, but that functionality is not actually exposed


< jonasschnelli> There are concerns with importing single keys into the bip32 wallet...
< jonasschnelli> But most important we should enable flexible bip32 keypath
< kanzure> we should review existing bips for source code links that do not include a commit hash. branch names are not OK.
< wumpus> not 'blawallet implements bip32', no, *the code linked here shows how we implemented BIP32 in language Z*
< gmaxwell> (unfortunately, it's BIP32 that gets 95% of this-- key generation is an especially awkward place for random found on the internet code)
< petertodd> my BIP65 links to two separate demo repos that just give some sample code, which is probably something we can generally consider as acceptable (ignoring the issue of more complex implementations that aren't pure demos)
< wumpus> some other BIPs have far fewer implementations and the author may be happy to see one
< wumpus> I mean the author of bip32 could say 'enough is enough'
< gmaxwell> I could see the criteria being different for different BIPs.
< gmaxwell> And if we're not looking at it, we're eventually going to get a malware example BIP32 impl. :)
< sipa> wumpus: in BIP32 there are continuously pull requests to add links
< wumpus> many bips have a list of implementations; what's wrong with that?
< kanzure> okay this is just trivial though, luke-jr isn't going to stop me from ACKing on BIPs i didn't author :)
< sipa> i guess the question is where BIPs are to be discussed
< luke-jr> on that note, it'd be nice if people didn't ACK/NACK bips they are not a listed author of ;)
< wumpus> add a file bip-0009/assignments.md in the bips repository: btcdrak made a pull for that
< GitHub52> [bitcoin] laanwj closed pull request #8041: [qa] Fix bip9-softforks blockstore issue (master...Mf1604-qaBip9Blockstore) https://github.com/bitcoin/bitcoin/pull/8041
< GitHub120> bitcoin/master 5b736dd Wladimir J. van der Laan: Merge #8041: [qa] Fix bip9-softforks blockstore issue...
< GitHub120> bitcoin/master fad60b3 MarcoFalke: [qa] Fix bip9-softforks blockstore issue


< GitHub138> [bitcoin] MarcoFalke opened pull request #8041: [qa] Fix bip9-softforks blockstore issue (master...Mf1604-qaBip9Blockstore) https://github.com/bitcoin/bitcoin/pull/8041


< sdaftuar> MarcoFalke: hi -- i was pretty sure the bip9-softforks test would be failing for everyone, but maybe it's a local problem
< GitHub98> [bitcoin] jonasschnelli closed pull request #7273: [Wallet] Simple HD/BIP32 support (master...2016/01/hdsimple) https://github.com/bitcoin/bitcoin/pull/7273
< GitHub24> [bitcoin] jonasschnelli closed pull request #6265: Add HD/Bip32 support (master...2015/06/wallet_bip32) https://github.com/bitcoin/bitcoin/pull/6265
< GitHub8> [bitcoin] jonasschnelli opened pull request #8035: [Wallet] Add simplest BIP32/deterministic key generation implementation (master...2016/05/simplest_hd) https://github.com/bitcoin/bitcoin/pull/8035


< jonasschnelli> And how would we distinct between a normal CKey and a CKey thats used as bip32 masterkey?


< jl2012> same before we had bip9
< jl2012> maaku, I think BIP68 also backdated?
< luke-jr> cfields: there is a PR for the GBT BIP9 changes already
< luke-jr> morcos: right now, GBT is broken in 0.12.1 due to BIP9


< cfields> morcos: there's a proposal to bip9 that would require that miners set a flag signaling awareness of segwit
< wumpus> #action add a file bip-0009/assignments.md in the bips repository to keep track of an overview of current bit assignments separate from their bips
< btcdrak> wumpus: maybe we can add a file bip-0009/assignments.md in the bips repository
< wumpus> probably we should have some living document that keeps track of current bit assignments, outside the bips


< sipa> https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md <- does not list BIP68/112/113 ?


< instagibbs> did someone volunteer to fix up bip144? missed the last part of meeting
< petertodd> jonasschnelli: which is tricky, because any low fee tx is in practice replacable by fee regardless of whether bip125 is used or not
< jtimon> ack bip125-replaceable
< jonasschnelli> Also I think someone should refactor the RBF BIP125 rules to the new rbf.cpp
< wumpus> yes entry.push_back(Pair("bip125-replaceable", rbfStatus));
< petertodd> don't we already have a bip125-replacable or similar name used in the RPC anyway?
< wumpus> yes the 0.12 is implicit, the BIP125 part makes sense
< jonasschnelli> "standard-policy-0.12-BIP125-replaceable"
< jl2012> sipa: are we ready to define the testnet BIP9 parameter for segwit?
< wumpus> #topic status of the segwit BIPs
< sipa> cfields: i'd like some comments from you ob luke-jr's proposed bip9 gbt changes
< gmaxwell> What is the status of the segwit BIPs? are they all consistent with the implementation right now?
< Chris_Stewart_5> this is in BIP112


< sdaftuar> ERROR: ConnectBlock: contains a non-BIP68-final transaction
< GitHub176> [bitcoin] mruddy opened pull request #7948: RPC: add locked_in block hash to getblockchaininfo bip9_softforks data (master...version_bits_locked_in_block) https://github.com/bitcoin/bitcoin/pull/7948


< sipa> DERSIG is a subset of STRICTENC, which is set when BIP66 is active


< luke-jr> "version" did that pre-BIP9, and "rules" does it with BIP 9
< Lightsword> like CSV and BIP66?
< sipa> and bip141
< sipa> bip30 and bip34
< luke-jr> Lightsword: see https://github.com/bitcoin/bips/pull/365
< luke-jr> sipa: does BIP68+112+113 have a VB name?
< instagibbs> I read it as "BIP141 by itself is somehow a hardfork"
< luke-jr> ok, step 1 done I hope: https://github.com/bitcoin/bips/pull/365
< sipa> it's in the bips
< luke-jr> so today I will focus/prioritise 1) finish revising GBT BIP changes, 2) split BIP9 GBT code from segwit, 3) update libblkmaker to detect 0.12.1 situation
< sipa> i think it may be best to disentangle the segwit changes from bip9 changes to gbt
< luke-jr> as long as the next softfork uses BIP9 GBT changes, that would protect against bit reuse
< luke-jr> I suppose libblkmaker can treat the case of (currentsoftforkversion && !bip9)
< sipa> i'm fine with reporting what bip9 deployments are active and available in GBT


< sipa> luke-jr: first figure out the bip9 related changes, i guess


< kanzure> sipa: i replied re: SignatureHash namecalling :) https://github.com/bitcoin/bips/pull/374#issuecomment-212632899
< morcos> yeah in talking to sdaftuar, i don't really see the feefilter as analogous to the bip37filter. feefilter seems almost unlikely to be used by lite clients, why would you not want to know about all relevant txs to you anyway, you can do your own logic if you dont' think the fees are high enough. i see feefilter as a tool for full nodes to eliminate traffic that would be dropped at mempool acceptance anyway
< sipa> but there are arguments against it: 1) what if you want both a bip37 filter and a feefilter? sending either will turn on invs before sending the second
< sipa> (same as with bip37 filters)


< sdaftuar> Should BIP61 be interpreted to mean that reject messages with code 0x01 (REJECT_MALFORMED) should NOT have a hash payload, even if the message that triggered the reject is "block" or "tx"?


< sipa> the CSV deployment (bip68/112/113) only starts on may 1st
< assder> Is version 0x20000000 voting for BIP68/112/113?
< sipa> it's BIP9 without supporting any specific deployment


< GitHub199> [bitcoin] laanwj closed pull request #6215: add bip32 pub key serialization (master...2015/06/extkey_ser) https://github.com/bitcoin/bitcoin/pull/6215


< btcdrak> kanzure: it got published BIP114
< jonasschnelli> Features I'd like to see in 0.13: wallet/RBF (+GUI), simple profiles (maybe GUI only), BIP32 (probably not in 0.13 because of lack of review)
< gmaxwell> sipa: yes, it seems we kinda flubbed the part of the motivation with the BIP9 starting dates to remove the possibility of warings in advance of a release. :)
< Luke-Jr> I wonder sometimes if it should be named "bip9", but I can argue both ways, so I haven't brought it up.
< GitHub19> [bitcoin] laanwj closed pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (master...bip9-status-as-object) https://github.com/bitcoin/bitcoin/pull/7863
< GitHub61> bitcoin/master 72c54e3 Wladimir J. van der Laan: Merge #7863: getblockchaininfo: make bip9_softforks an object, not an array....
< GitHub61> bitcoin/master 85c807c Rusty Russell: getblockchaininfo: make bip9_softforks an object, not an array....


< jl2012> Chris_Stewart_5, instagibbs: more comments added to the reference implementation https://github.com/jl2012/bips/blob/bip114ref/bip-0114.mediawiki#Reference_Implementation


< GitHub99> [bitcoin] rustyrussell opened pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (master...bip9-status-as-object) https://github.com/bitcoin/bitcoin/pull/7863


< GitHub192> [bitcoin] laanwj closed pull request #7852: [0.12] Add missing reference to release notes (0.12...bip113) https://github.com/bitcoin/bitcoin/pull/7852
< GitHub100> bitcoin/0.12 de7c34c BtcDrak: Add missing link to BIP113


< GitHub0> [bitcoin] btcdrak opened pull request #7852: [0.12] Add missing reference to release notes (0.12...bip113) https://github.com/bitcoin/bitcoin/pull/7852


< morcos> sdaftuar: wumpus: i got a failure of bip68-sequence.py in 0.12.1rc2 . but its intermittant. looking into it.


< sipa> petertodd: spv does not imply bip37
< jonasschnelli> My proposal for a concept: extend #7830: copy the wallet, remove backward compatibility (not required), remove accounts, replace BDB with LogDB, add BIP32, add SPV (= process separation)


< Chris_Stewart_5> why isn't the hash type being defined in the bip66 specification?


< GitHub91> bitcoin/master 92107d5 mruddy: RPC: add versionHex in getblock and getblockheader JSON results; expand data in getblockchaininfo bip9_softforks field.


< GitHub1> [bitcoin] laanwj closed pull request #7543: [0.12] Backport BIP9, BIP68 and BIP112 with softfork (0.12...dot12_backport_bip68) https://github.com/bitcoin/bitcoin/pull/7543
< GitHub144> bitcoin/0.12 0d09af7 Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
< jonasschnelli> gmaxwell: the rekeying is local policy, but should not be under 600 seconds to avoid dos (https://github.com/bitcoin/bips/pull/362/files#diff-0bd7a3b80179294f4bcb38cae13c8534R142)
< jonasschnelli> gmaxwell, sipa: If you interested to review the enc/auth BIP again, a new version is here https://github.com/bitcoin/bips/pull/362/files
< jonasschnelli> <flag|flag> could be {"bip125rbf":true, etc.}
< gmaxwell> e.g. sequence: 12345 / and seqtype: "BIP12" and have their use be mutually exclusive would seem preferable to me.
< jonasschnelli> {"txid": <txid>, "vout" : 0, "sequence": "BIP12"} <--- feels ugly
< jonasschnelli> But the BIP125 MAXINT-2 is a policy we should offer directly.
< jonasschnelli> The per-tx-general opt-in-to-Bip125 is probably to high. I agree.
< jonasschnelli> At least we should offer some nSequence=BIP125 abstraction.


< jonasschnelli> Can directly be PRed (no I'm getting impudent) https://github.com/jonasschnelli/bips/commits/2016/03/auth_enc2
< jonasschnelli> kanzure: If you have time, I need a native english to fix the enc/auth BIPs. https://github.com/bitcoin/bips/pull/362/files


< jtimon> let me expain, if you throw 2 UTC clocks in perpendicular directions, you may be deceived into thinking that either the earth is not moving or you have to grow a withe mustache to undesrstand the universe: it's neither of them, you just have to use median time, see BIP113
< morcos> the timeframe is set by the startdate in BIP9 anyway, so no reason not to let 0.12.1 penetrate for a little bit longer if we can
< btcdrak> jonasschnelli: continuing to work on those BIPs is a clear win
< sipa> it's also rebased on top of the bip68/112/113 backport, and a new segnet (segnet4) is up and running with bip9 activation logic


< GitHub77> [bitcoin] mruddy opened pull request #7774: RPC: BIP9 version bits related, format version as hex in getblock and getblockheader (master...hexver) https://github.com/bitcoin/bitcoin/pull/7774
< sipa> the deployment being considered now is called "csv", and it activates the rules specified by bip68, bip112, and bip113
< sipa> maybe BIP145 should specify that every BIP9 softfork should also list a canonical name?
< Luke-Jr> so to throw in a simply GBT section, how about "bips_supported":[141:28],"bips_required":[] ? does that seem practically complete?
< sipa> actually, the code snippet inside bip9 does define the behaviour fully
< sipa> it was merged for BIP34
< GitHub193> [bitcoin] laanwj closed pull request #7648: BIP9 versionbits softfork for BIP68, BIP112 and BIP113 (master...vb_68_112_113_1) https://github.com/bitcoin/bitcoin/pull/7648
< GitHub114> bitcoin/master 478fba6 BtcDrak: Soft fork logic for BIP113
< GitHub114> bitcoin/master 02c2435 BtcDrak: Soft fork logic for BIP68
< GitHub114> bitcoin/master 65751a3 Pieter Wuille: Add CHECKSEQUENCEVERIFY softfork through BIP9
< jonasschnelli> sipa: did I got this right: the (truncated) mac tag (https://github.com/bitcoin/bips/pull/362/files#diff-0bd7a3b80179294f4bcb38cae13c8534R87) should be after the crypted message to allow faster hashing or chunk based sending?
< jonasschnelli> What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?


< morcos> wumpus: 7648 is actually relatively simple code wise, i believe it has gotten a lot of review. i believe at least one of petertodd's comments were about testing of the consensus code in bip68 which is tested fairly heavily by the new rpc test.


< sipa> in addition, there is warning logic for each bip9 bit position, which works retroactively
< sipa> petertodd: how is the bip9 warning code broken?
< sipa> as soon as we have 0.12.1, i will rebase segwit on top, so segnet can benefit from its bip9/68/112/113 support
< btcdrak> #action 0.11 review #7716 Backport BIP9 and softfork for BIP's 68,112,113
< wumpus> #action people need to also look at backport #7543: [0.12] Backport BIP9, BIP68 and BIP112 with softfork
< btcdrak> Luke-Jr: even BIP68 backport to 0.11 was tricky, not a clean cherry-pick.
< sipa> bip68/112/113 are quite a bit of code
< btcdrak> I think if there is a 0.10.5 release it should be extremely minimal... and frankly, backporting BIP68 wont be fun or easy.
< jonasschnelli> Right. I'll try to update the Bips with what we have discusses and ask for another review.
< sipa> BIP66 was not a hard fork... there were some miners that mined invalid blocks, and kept going
< Chris_Stewart_5> is there a BIP66 post mortem some where about the hard fork?


< jonasschnelli> cfields: hmm... IIRC I wrote in both bips that the wrapped messages also contains the HDR.
< jonasschnelli> sipa: I have wrote two separate BIPs because auth could also make sense for non-encrypted coms.
< sipa> (i have not looked at your bips) i think it should be a single authentication+encryption extension that is either off or on; if the identity of the peer is not known, a randomly generated key is used, otherwise a known key is used
< wumpus> btcdrak: you've introduced a new blockchain historical video media extension in #7648? *ducks* "BIP113 Media Time Past."
< sipa> fanatid: adding that would not have added anything; the total length check is included because otherwise the rest of the bip66 code would have needed to be able to deal with >1-byte length descriptors
< fanatid> I understand that there are not all restrictions, it's just very strange to see that BIP66 checks total length, but not checks r|s length
< fanatid> for example this (in hex) will be valid for BIP66: 3044021458a2f39bd87f0000000506030000000000050603022c402dde9afe7f0000010000000100000004000000040000000000000000000000000000000a00000000000000 but invalid for secp256k1
< fanatid> Hey to all, can somebody explain, why BIP66 not checks that R or S more than 33 bytes (but checks that total length can't be more than 73 bytes)


< Chris_Stewart_5> gmaxwell: So after BIP66 this would fail, pre BIP66 this would pass, correct?
< Chris_Stewart_5> BIP66 says that "if the signature does not pass the IsValidSignatureEncoding check below, the entire script evaluates to false immediately."
< Chris_Stewart_5> "BIP66 example 6, without DERSIG"
< Chris_Stewart_5> I have a question about BIP66 and this test case inside of script_valid.json


< Ylbam> sipa: it looks like BIP9 requires a 95% consensus for activation, are you feeling concerned about Classic mining currently being above the 5% veto threshold?
< sipa> Ylbam: yes, that's next on the todo list: uodate the segwit code to be bip9 based
< Ylbam> simple question: will BIP9 be used for SW deployment?


< GitHub157> [bitcoin] btcdrak closed pull request #7693: [0.11] Backport BIP112 CHECKSEQUENCEVERIFY mempool-only (0.11...bip112-backport-0.11) https://github.com/bitcoin/bitcoin/pull/7693
< GitHub85> [bitcoin] morcos opened pull request #7716: [0.12] Backport BIP9 and softfork for BIP's 68,112,113 (0.11...backportBIP9SoftFork) https://github.com/bitcoin/bitcoin/pull/7716
< JackH> nice on BIP9 btw :)
< GitHub90> [bitcoin] laanwj closed pull request #7575: Minimal BIP9 implementation (master...bip9) https://github.com/bitcoin/bitcoin/pull/7575
< GitHub197> bitcoin/master 6851107 Pieter Wuille: BIP9 Implementation...


< btcdrak> morcos: this is what I came up with https://github.com/bitcoin/bips/compare/master...btcdrak:cvsdeploy
< jtimon> morcos: for bip68/bip112/bip113 ? testnet should definitely have an earlier starttime
< * btcdrak> hands jtimon some BIP9 party beers
< jtimon> good meeting, more re bip9. Again, I'm super-happy with #7575. And I'm glad that CodeShark rusty and sipa don't seem to hate me after my heterdox review method for bip9, and I'm sorry for being to open too open to offer resistance for potentially/probably/likely stupid things. I feel I've been a pain in the ass with this. I really needed to maintain a parallel branch to whatever was going to be merged for me to review , but next
< btcdrak> "This BIP is to be deployed by "versionbits" BIP9 using bit 0 with a '''starttime''' of midnight 1st May 2016 UTC (Unix timestamp 1462060800) and '''timeout''' of 1 year at midnight 1st May 2016 UTC (Unix timestamp 1483228800)."
< btcdrak> morcos: do I need to mention testnet starttime/timeout in the BIPs?
< sipa> i'm glad bip9 seems final
< btcdrak> morcos: but the topic was "Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113"
< jtimon> sorry, late, reading, super happy with bip9
< btcdrak> top bit 010, so it's not actually part of the BIP9 spec
< btcdrak> BIP109 uses one of the top 3 ::sigh::
< btcdrak> ok so action point is update BIP68/112/113 deployment section
< morcos> CSV deployment makes sense to me, it captures most of it, perhaps it would be helpful to add a comment next to the deployment, which BIPS it implements
< morcos> btcdrak: that language is confusing. the date for the first BIP9 soft fork is May 1st
< btcdrak> so is the BIP9 start date May 1st?
< sdaftuar> good point about updating BIP68/112/113
< btcdrak> morcos: BIP9 text is uptodate with the implementation
< sipa> we want to announce out intention to go ahead with a deployment based on bip9, for 68/112/113, with a given start date
< btcdrak> is that the start date for BIP9?
< btcdrak> this is built on #7575 and has additional RPC tests that exercise the BIP9 softfork process and the BIP enforcements for 68,112 and 113
< wumpus> we had an action item last time to review the backports for r BIP68 and 112
< wumpus> #topic c: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113
< morcos> suggested meeting topic: Scheduling the first BIP 9 sort fork for BIPs 68, 112, 113 (have to merge 7575 first, click the button wumpus)
< GitHub60> [bitcoin] laanwj closed pull request #6816: BIP9: versionbits (master...versionbits) https://github.com/bitcoin/bitcoin/pull/6816


< btcdrak> The mempool behaviours for BIP68/112 have been backported by cherry-pick to 0.11 and 0.12 in PRs #7543, #7695 and #7693. Can I ask a few eyes you verify they are correct.
< wumpus> that's why we moved the BIPs to git


< GitHub97> [bitcoin] btcdrak opened pull request #7693: [0.11 backport] BIP112 CHECKSEQUENCEVERIFY mempool-only (0.11...bip112-backport-0.11) https://github.com/bitcoin/bitcoin/pull/7693
< GitHub85> [bitcoin] btcdrak closed pull request #7561: IsSuperMajority() softfork for BIPs 68,112 and 113 (master...softfork) https://github.com/bitcoin/bitcoin/pull/7561
< GitHub2> [bitcoin] btcdrak closed pull request #7544: Backport BIP112 implementation for 0.12 (0.12...dot12_backport_bip112) https://github.com/bitcoin/bitcoin/pull/7544
< morcos> It seems like its the case now that anybody running .11.2 or .12.0 might miss warnings of the upgrade to BIP9 right? they'll have that warning set once, but then it might be wiped out by one of the frivolous warnings
< sipa> maybe it does need fixing separately before we release any bip9 code


< morcos> hmm... so i was hoping to write the BIP112 rpc tests with the {locktime OP_CSV OP_DROP} in the scriptPubKey to keep things as close to actual usage as possible


< gmaxwell> morcos: in the long term I think it's adequate to refuse to serve GBT requests after a BIP9 activiation triggers. (and perhaps mine only empty blocks during the quiet period for further visibility)
< morcos> they will happily mine version 4 blocks for months until they accidentally mine an invalid BIP68 tx, and then all the SPV miners will just build off them
< gmaxwell> morcos: the existing warning stuff is stupid, boarderline broken-- which is why I was suggesting it only for BIP9 activation.
< gmaxwell> BIP9 softforks.
< sipa> and if it's not consnesus, we can say bip9 miners without active rollouts use 001000...
< btcdrak> bip68/112/113 have the p2p RPC tests in #7648
< btcdrak> bip65 had RPC tests.
< jonasschnelli> bip65 had rpc tests from petertodd?!
< morcos> btcdrak: i saw, and i agree, BIP65 made it out withotu adequate tests
< btcdrak> morcos: yes there are. same standard as for BIP65
< sipa> CodeShark: yes, see bip9
< btcdrak> morcos: you'd be the best person to backport BIP68 to 0.11.
< morcos> i think i can make sure BIP68 for 0.11 backports properly
< btcdrak> btw the backports for BIP68,112 are #7543 and #7544, I forgot to mention the numbers earlier
< btcdrak> the backports to 0.12 are trivial, but 0.11 will be a little more annoying, especially for BIP68 I believe
< wumpus> #action review backport PRs for BIP68 and 112
< btcdrak> Can I ask people to review the backport PRs for BIP68 and 112? They were straight cherry-picks into 0.12 but they do need a couple eyes on them.
< jonasschnelli> +1 for P2WPKH bip142
< sipa> the reason against incorporating bip142 is people yelling "see! sehwit needs new address types! everyone has to upgrade! not backward compatible!"
< wumpus> would be good to have concrete proposals for address formats ,say as BIPs
< sipa> jonasschnelli: you mean bip142?
< btcdrak> sipa I thought we did? BIP142?
< sipa> my plan was to rebase segwit on top of bip9, add the rewind logic to continie after post-softfork uograde, and do a new testnet
< morcos> seems to me it would nice to buckle down and prioritize BIP 9, BIPs 68,112,113 , segwit. i mean i think we are all working on those things, but there is still more to do on all of them
< sipa> so what is the current state of the pull request against my bip9 pr?


< morcos> after bip9 an old node needs to be able to detect transient activations, which means i think that the warning logic needs to run during IBD
< morcos> before bip9 an old node would always detect when soft forks activated b/c the signal was permanent (version number incremented)


< GitHub4> [bitcoin] btcdrak opened pull request #7648: BIP9 versionbits softfork for BIP68, BIP112 and BIP113 (master...vb_68_112_113_1) https://github.com/bitcoin/bitcoin/pull/7648


< jtimon> oh, bip9 now has a graph with the state machine, very nice


< morcos> we still need tests for the soft fork BIPS right
< paveljanik> BIP113
< gmaxwell> #action after sipa pushes a few changes; reivew/test 7575, review BIP9
< sdaftuar> sipa: is 7575 going to eventually include deployment code for BIP68/112/113, or are you going to remove the last commit for a different PR?
< sipa> so BIP9 currently guarantees that as long as the start/end times of deployments are non-overlapping, the bits are never ambiguous
< gmaxwell> #topic Versionbits (BIP9)
< GitHub13> [bitcoin] jtimon closed pull request #7565: bip9/bip113/libconsensus-p2a: Deployment preparations forBIP113 + #7552 + Introduce Consensus::VerifyTx() (master...libconsensus-p2a-verifytx-bip113-0.12.99) https://github.com/bitcoin/bitcoin/pull/7565
< GitHub133> [bitcoin] jtimon closed pull request #7566: WIP: Implement BIP9 and get BIP113 to be ready to be deployed with it as an example (master...bip9-0.12.99) https://github.com/bitcoin/bitcoin/pull/7566


< sipa> will look at it, once i'm done with some bip9 and segwit updates


< Giszmo> Thanks Luke. Back to study the bips ...
< Giszmo> Looking into bip142 I wonder if there is a schema to optionally allow segWit that would be compatible with bip21? some bitcoin:1....?amount=12&segWitAllowed=true kind of downwards compatible style we could use in mycelium to leave it to the sender if he wants to use segwit?
< catlasshrugged> "onsidering those questionare answers which were mostly privacy positive (BIP 69 where kristov gave a misleading answer-- I don't think we should implement BIP69, it doesn't improve privacy and could hurt it); it's remarkable to me that they rated Bitcoin-QT poorly if thats where their information was coming from." the only criteria relevant Bitcoin-Qt received full marks for for random sorting of outputs.
< gmaxwell> Considering those questionare answers which were mostly privacy positive (BIP 69 where kristov gave a misleading answer-- I don't think we should implement BIP69, it doesn't improve privacy and could hurt it); it's remarkable to me that they rated Bitcoin-QT poorly if thats where their information was coming from.


< jtimon> stupid me, just trying to replace bip112 with bip113 told me the answer, rebase!
< jtimon> petertodd: in any case, github/bitcoin/jtimon/bip9-0.12.99-bip113-just-in-case should be easy to rebase on top of both #7575 and #7566
< petertodd> jtimon: wait, why do you want to decouple bip113? it's a very simple and easy bip, and we really don't want it to become an issue in of itself because it fixes a potential exploit
< jtimon> sipa well, I'm ok with doing both, but if I deploy BIP113 and you don't, my implementation doesn't have any chance to compete with yours in minimal-ness (just like if I don't decouple it from the commits it has from #7563), anyway, the part that really worries me from using BIP113 as example, is the fact that #7565 is making both (itself and #7566 ) fail on travis, and trying the couple of things that I thought could be causing
< jtimon> sipa: thoughts on moving to BIP112 instead of BIP113 as an example?


< jtimon> in the meantime, I think I will decouple my PR from BIP113 (I don't know why #7565 is currently failing in travis anyway, but doesn't inspire confidence) and use BIP112 as example as well
< jtimon> BIP113 is ready, right? or do we plan to wait some more time of it being deployed as relay policy ?
< jtimon> I think it makes a lot of sense that BIP68 and BIP112 are deployed together (in fact, I would have been happy if they had been a single BIP), but I'm not so sure about BIP113.
< jtimon> @petertodd mentioned that BIP68 required more testing and that's why I went with BIP113 in my implementation (although I'm happy to change it to something else and that will probably mean less code in my PR).
< jtimon> Assuming BIP9 was reviewed, tested and ready for merge, what would be the BIPs from this 3 that are ready to be deployed right now (modulo backports)?
< jtimon> btw, my wip bip9 implementation is #7566 I started before sipa but got distracted maximizing its libconsensus friendly-ness and...sipa codes faster than me
< jtimon> CodeShark: when I first reviewed your BIP9 implementation I first complained aboutthe start time but then reading the code more was convinced that it could actually simplify the implementation, after implementing it myself, I realized it does not simplify things, but it's just a couple of extra lines for a very reaonable feature (specially needed if we are ever going to use versionbits for hardfork deployment as recommended by
< jtimon> bip99 anyway)
< sipa> i'm going afk now; i'll look at bip9 and 7575 and tests next week
< gmaxwell> Any other topics? (we can discuss BIP9 more out of meeting and maybe when sipa has better connectivity?
< btcdrak> our roadmap FAQ tentatively pencilled BIP68,112,113 for March.
< sipa> morcos: 7575 is where i want it to be, but the logic should also go in bip9
< CodeShark> https://github.com/bitcoin/bips/pull/219 didn't even get merged over this whole starttime crap :(
< gmaxwell> I can't imagine doin BIP9 without a start time. Rusty was opposed on principle, I think, but expirence trumps.
< sipa> btcdrak: and i had to make some interoretation as bip9 is ambiguous about what hapoens when both transitiin to failed and lockedin happen simultaneously
< sipa> btcdrak: it impkements a start time, which is not in bip9
< morcos> CodeShark: are you referring to BIP68 stuff. (I mostly agree, but we merged that already)
< jonasschnelli> #action talk to BTCD folk about bips 9/68/112/113
< morcos> two steps seems logical, and bumping the default isn't particularly important while we don't have wallet code for sending BIP68 locked txs anyway right?
< btcdrak> Unless miners were change their signalling, I think we should go for BIP9 this time. It shouldnt take too long to convert the RPC tests over to sipa's PR.
< morcos> gmaxwell: yes thats my point exactly, i think much less likely to have complaints if we are doing it via bip9
< btcdrak> BIP68 obviously requires v2 transactions, which currently dont relay. So we need to bump the relay policy. the question is do we go for sf enforcement first, and then bump the policy or do we change the relay policy with the sf deployment?