< jonasschnelli> Luke-Jr: right now, most(all?) hardware wallets use bip32 and do not store keys in the EPROM (just the seed). A bip32 pubkey only wallet in core would allow to use `create/fundrawtransaction`, take the hex, transmit it to the hardware wallet, get the signed hex back...
< jonasschnelli> Luke-Jr: I still follow both plans... short term (0.13) I'd like to get a simple form of bip32 into the existing wallet. why: allows simple support of hardware wallets
< GitHub49> [bitcoin] jonasschnelli opened pull request #7273: [Wallet] Simple HD/BIP32 support (master...2016/01/hdsimple) https://github.com/bitcoin/bitcoin/pull/7273


< morcos> if so we should be concentrating core development effort on all of these things so we can show progress. versionbits, BIP68/CSV, segwit


< dcousens> sipa: not sure of how bitcoind handles it, but, conceptually, in regards to say watching a BIP32 tree, and trying to 'rediscover' it, you'd be able to track whats used based on a deterministic witsig scriptpubkey


< btcdrak> (and BIP113 must be activated with BIP68)
< btcdrak> JackH: #6564 is the CSV patch specifically, although we need BIP68 as well.
< morcos> It seems resonable to me that within a month or two of releasing 0.12 we ought to be able to release a soft fork patch for BIP68


< Luke-Jr> good catch with the biplist difference
< jonasschnelli> I think you need a "import biplist"
< jonasschnelli> Luke-Jr: NameError: name 'biplist' is not defined
< Luke-Jr> biplist is builtin to Python nowadays I think
< jonasschnelli> I guess you need this tool: https://github.com/wooster/biplist
< jonasschnelli> I think your PR does the right, thing, expect of the byte-fiddling, why could you not use "biplist.Data(alias.to_bytes())"?
< jonasschnelli> Luke-Jr: but `biplist.Data(alias.to_bytes())`?
< dcousens> It'd be cool to see how much usage BIP65 has received over the last few days


< btcdrak> BIP65 enforced
< jcorgan> jonasschnelli: i've also been chewing on the idea a "password keeper" that generates/regenerates passwords using BIP32-derived secret keys
< jonasschnelli> A GPG/SSH hw wallet infrastructure that works together with bip32 would be a better solution.


< jtimon> btcdrak: could you make me a branch with bip68 and bip112 on top of 3cd836c1 ?
< jl2012> Why Antpool is not upgrading to BIP65? It is the last major pool to upgrade


< morcos> yeah, thats' what i'd like to get out of it, except only the BIP68 valid height and time
< morcos> releasing BIP68 soft fork i mean


< gmaxwell> Luke-Jr: would still require updating software. Come one, for BIP66 I recall having to pull teeth to get a new libblkmaker from you. :)


< sipa> so you can't validate bip65/bip112 that way :(


< tulip> it looks like there's mining software on the main network which is rolling the sequence number. not disastrous or particularly interesting at the moment, but it might be notable if anybody is altering the behaviour of sequence numbers with a consensus rule like in BIP112.


< gmaxwell> raskolnnikov: full nodes can freely omit transactions, thats one of the limitations in the design of BIP37. There are other schemes which lack that limitation which are possible but have not been implemented yet.
< tulip> do you realise that BIP37 only allows lying by omission in most circumstances?
< gmaxwell> raskolnnikov: it does not necessarily provide the whole block, the block can be filtered in way that proves the filtered subset is in there. See BIP37.


< btcdrak> BIP68 bip text has been updated https://github.com/bitcoin/bips/issues/245


< tulip> I didn't think btcd implemented BIP37 anyway?


< GitHub193> bitcoin/0.11 9730051 Alex Morcos: add bip65 tests to rpc-tests.sh -extended
< GitHub34> [bitcoin] laanwj closed pull request #7021: add bip65 tests to rpc-tests.sh -extended (in 0.11 branch) (0.11...11rpcfixups) https://github.com/bitcoin/bitcoin/pull/7021
< gmaxwell> for me bitcoin core sync runs at around 8000tx/s (with secp256k1), even though every tx is involving a non-cachable missing record check for bip30 (in addition to all the cached stuff)... thats really quite remarkable IMO.


< GitHub64> [bitcoin] morcos opened pull request #7021: add bip65 tests to rpc-tests.sh -extended (in 0.11 branch) (0.11...11rpcfixups) https://github.com/bitcoin/bitcoin/pull/7021


< sdaftuar> Luke-Jr: i wanted to follow up on the issue you reported with that bip65-cltv-p2p test this morning. i updated the issue with my observations


< GitHub129> bitcoin/master 33c90cf Alex Morcos: Make skipping BIP30 check chain agnostic
< GitHub129> bitcoin/master 06d81ad Alex Morcos: Skip BIP30 check after BIP34 activation
< sipa> bip37-based downloading does too


< wangchun> Dear core devs, how do you plan to response to the latest actions regarding BIP101?


< GitHub130> [bitcoin] laanwj closed pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
< GitHub67> bitcoin/master c53d48a Jorge Timón: BIP70: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings...


< btcdrak> well it's probably just better to point them to BIP113
< harding> Luke-Jr, anyone else: for the release notes, should I include a paragraph like this one (updated to BIP65): https://bitcoin.org/en/release/v0.10.0#mining-and-relay-policy-enhancements
< harding> michagogo: that's what I figured too, worst case they don't get used. :-) I think I'm almost done; I'm just trying to figure out good wording for the BIP65 stuff.


< GitHub106> [bitcoin] laanwj closed pull request #6934: Restores mempool only BIP113 enforcement (master...undo_undo) https://github.com/bitcoin/bitcoin/pull/6934


< GitHub128> [bitcoin] gmaxwell opened pull request #6934: Restores mempool only BIP113 enforces (master...undo_undo) https://github.com/bitcoin/bitcoin/pull/6934


< GitHub48> [bitcoin] laanwj closed pull request #6928: Revert MedianTimePast / mempool-only BIP113 (master...undo_113) https://github.com/bitcoin/bitcoin/pull/6928


< GitHub136> [bitcoin] gmaxwell opened pull request #6928: Revert MedianTimePast / mempool-only BIP113 (master...undo_113) https://github.com/bitcoin/bitcoin/pull/6928


< phantomcircuit> testnet is now 50/50 split between bip65 and !bip65
< dcousens> shouldn't BIP65 be Accepted now?
< gmaxwell> FWIW, I think testnet has activated BIP65.
< GitHub104> [bitcoin] laanwj closed pull request #6883: Add BIP65 CHECKLOCKTIMEVERIFY to release notes (master...cltv-release-notes-v0.12.0) https://github.com/bitcoin/bitcoin/pull/6883
< GitHub88> bitcoin/master c939792 Peter Todd: Add BIP65 CHECKLOCKTIMEVERIFY to release notes


< gmaxwell> the constant ancestor tests are slightly annoying but much better than running bip30 everywhere.
< gmaxwell> yea, so we could disable BIP30 when BIP34 acitivates if and only if the the ancestor chain is the real one.
< sipa> even post BIP34, a transaction that spends a previous duplicate coinbase is possible (in an alternative chain)
< gmaxwell> Right but we could enforce BIP30 for all chains until the point where BIP34 activates.
< sipa> gmaxwell: BIP34 or not is not enough
< gmaxwell> sipa: the existing BIP30 violations overwrote without proliferation.
< sipa> morcos: fundamentally, the bip30 check can be disabled for any transaction that depends on a bip34 coinbase
< sipa> as BIP34 is only sufficient when there are no actual duplicate coinbases
< sipa> gmaxwell: i'm trying to think whether enforcing it for all blocks (except those two) that don't have BIP34 is safe
< GitHub118> [bitcoin] sipa closed pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
< GitHub92> [bitcoin] sipa opened pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
< sipa> morcos: we should get rid of the bip30 check; it's superseeded by bip34
< morcos> sipa: still afk, but yep, thats a cause of SIGNIFICANT slowness in ConnectBlock. I think we'd have to change/remove the BIP30 check to really eliminate it, which might be the harder part, bc I think adjusting ModifyCoins to know its a new tx and not lookup seems easy and safe?
< morcos> Also do we need to persist the BIP30 check? Is it still possible to violate that or now that the old duplicate coinbases are sufficiently buried, its not necessary
< morcos> There is already an existince check for BIP30 earlier


< GitHub107> [bitcoin] jtimon opened pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
< GitHub96> [bitcoin] laanwj closed pull request #6894: [Tests] Fix BIP65 p2p test (master...fix-bip65-p2p-test) https://github.com/bitcoin/bitcoin/pull/6894
< GitHub111> bitcoin/master 3e187f2 Suhas Daftuar: Fix BIP65 p2p test...
< gmaxwell> For the nussance things, non-standardness is sufficient. For contracts BIP62 is insufficient, but CLTV covers a lot of them.
< sipa> so if the network accepts those rules, we don't even need v2 transactions in bip62... just unconditionally make violations of its rules fatal
< gmaxwell> BIP62 is infintely far off right now, no one is working on it. And I don't think the approach is likely to be very successful; except for blocking malleability in a few narrow cases (which we've already been breaking out)
< sipa> all of bip62's rules are already nonstandard in 0.10.3 and 0.11.1
< sipa> bip62 can be simplified a lot now, if we want just that
< aj> gmaxwell: i was assuming that was a lot further off than bip62 though?
< gmaxwell> (and because every time we've picked up BIP62 again we've found more cases that weren't covered. :( )
< gmaxwell> BIP62 which also protects against miners creating malleability for a subset of transactions likely has issues still, and needs to be rewritten... fortunately the parts of it that don't have issues are flowing in.
< aj> what's the status of BIP62 (malleability)? is there something documenting what's stopping it from being ready to be deployed, at least for third-party malleability?


< morcos> and wihtout storing more info, you'd have to recalc for coinbase, checklocktime and bip68 sequence, bc you don't know which was invalidated
< GitHub51> [bitcoin] sdaftuar opened pull request #6894: [Tests] Fix BIP65 p2p test (master...fix-bip65-p2p-test) https://github.com/bitcoin/bitcoin/pull/6894
< morcos> that way the locktime and bip68 checks that you do at ATMP don't have to be repeated (ugh... i guess unless there is a reorg that affects inputs)
< sipa> morcos: fair enough, bip68 does make this significantly more expensive
< morcos> what do you think about BIP68 and sequence numbers though
< btcdrak> gmaxwell: I also made a branch with BIP68+OP_CSV in one as some people asked for it. I'm debating if I should make a PR or just leave the two separate PRs as is.


< sipa> wumpus: this is with sending out a BIP35 "mempool" command, so at startup it receives zillions of transactions
< dcousens> for example for a wallet I maintain, we very often have users that come along with BIP39 mnemonics with 100's of used addresses, forcing a rescan for each time they introduce a new mnemonic/wallet would be a huge rescan burden for us
< GitHub137> [bitcoin] laanwj closed pull request #6879: doc: mention BIP65 softfork in bips.md (master...2015_10_bip65) https://github.com/bitcoin/bitcoin/pull/6879
< GitHub133> bitcoin/master ceb2a9c Wladimir J. van der Laan: doc: mention BIP65 softfork in bips.md


< sipa> bip9 specifies a replacement for the alert logic


< btcdrak> I rebased #6312 and #6564 (BIP68+CSV) into one branch for the people who asked to review both PRs in one changeset https://github.com/bitcoin/bitcoin/compare/master...btcdrak:sequenceandcsv


< GitHub65> [bitcoin] petertodd opened pull request #6883: Add BIP65 CHECKLOCKTIMEVERIFY to release notes (master...cltv-release-notes-v0.12.0) https://github.com/bitcoin/bitcoin/pull/6883
< GitHub121> [bitcoin] laanwj opened pull request #6879: doc: mention BIP65 softfork in bips.md (master...2015_10_bip65) https://github.com/bitcoin/bitcoin/pull/6879
< GitHub151> bitcoin/master 65ef372 Peter Todd: Add BIP65 to getblockchaininfo softforks list
< GitHub151> bitcoin/master 287f54f Peter Todd: Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic...
< GitHub151> bitcoin/master cde7ab2 Peter Todd: Add RPC tests for the CHECKLOCKTIMEVERIFY (BIP65) soft-fork...


< btcdrak> CodeShark: well obviously the bipdersig.py tests are for an ISM sf.
< CodeShark> it will be better to provide a list of BIPs you don't want to set the bit for
< GitHub77> [bitcoin] laanwj closed pull request #6848: Add DERSIG transaction test cases (master...bip66-tests) https://github.com/bitcoin/bitcoin/pull/6848


< GitHub58> [bitcoin] rnicoll opened pull request #6848: Add DERSIG transaction test cases (master...bip66-tests) https://github.com/bitcoin/bitcoin/pull/6848


< btcdrak> https://github.com/bitcoin/bitcoin/pull/6564 BIP112 for OP_CHECKSEQUENCEVERIFY
< btcdrak> https://github.com/bitcoin/bitcoin/pull/6566 BIP113 for median-past locktime
< btcdrak> all three really: https://github.com/bitcoin/bitcoin/pull/6312 BIP68 for sequence numbers


< GitHub2> [bitcoin] CodeShark opened pull request #6816: BIP9: versionbits (master...versionbits) https://github.com/bitcoin/bitcoin/pull/6816


< wumpus> well, BIPs are on topic when it relates to implementing them in Bitcoin Core, but not on their own
< CodeShark> is the bips repo offtopic here?
< CodeShark> hey! I'm not in the acknowledgements for BIP32
< CodeShark> kanzure: if you want to know anything about BIP32, I also had a thing or two to do with it in the past ;)
< kanzure> sipa: what is the nature and data type of the "master" variable specified in bip32 test vector 1? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Test_vector_1
< sipa> skyraider: read BIP32, it clearly specifies what master means
< wumpus> skyraider: questions about BIPs are really off topic here
< skyraider> what's the value of the master public key and master chain code in the Bip32 Test Vector 1? this doesn't seem to be specified.
< sipa> in backports you could keep the naming after activatiin, while for new major releases you could have a "0.12 includes softforks bip16, 34, 66, and 68 in all releases"
< CodeShark> BIP65 is a tad bit more complex in the sense that it also defines an op code
< CodeShark> well, if you take a look at how BIP65 and BIP66 are deployed, there aren't too many places really
< Luke-Jr> well, except BIP66 I guess
< aj> wumpus, Luke-Jr: am i completely off-base think bip68/nSequence for relative locktime will cause SPV clients to see bad confirmations on about 5% of blocks for a while after activation? cf http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011467.html


< stonecoldpat> wumpus: if it would help, I can look into making a module for bip70 that interfaces with bitcoind
< kanzure> what is the measure of bip70 adoption?
< wumpus> an example could interface to bitcoind and handle BIP70 either as client as server - as long as it is clear that it is a layer on top
< Luke-Jr> BIP70 adoption is not going fast enough IMO
< wumpus> then again, I think it'd be better to make a BIP70 handling library that is completely independent of bitcoind
< Luke-Jr> so to bring BIP70 to bitcoind probably means replacing that with libcurl or smth


< jonasschnelli> CodeShark: I keep my +1 credit because non of my PR are merge-or-review-ready state. I still like to get the bip32 patch into 0.12. Will come back to your offer soon. :)


< Luke-Jr> I think we moved the last 0.8 miners off it during the BIP66/OpenSSL fiasco
< gmaxwell> If we're going to backport BIP65 to 0.8 we should also apply lowS signatures there, (a28fb70e45d764e558966ba3b02bd16e02b11c14 from 0.9).
< CodeShark> regarding asking what bips apply, we need to maintain an index for this...so it seems like it would be convenient to have the same entrypoints we use to grab other block header info...but there are several alternatives to this
< sipa> you were saying the block should have a function to ask what bips apply to it
< CodeShark> then the rest of the block checking stuff can have conditionals like if(rules.contains(BIP66)) { }


< btcdrak> BIP68 was ironed out exactly that way. BIP112 just needs tweaking because of the references to BIP68.
< morcos> btcdrak: i know BIPs are supposed to be descriptive, not proscriptive, but it sure would be helpful for proposed soft forks like this if there is a clear consensus on the semantics separately and first, and then the code can be reviewed for compliance with that
< btcdrak> does anyone know which block BIP66 enforced on specifically?
< btcdrak> yeah the link is to brancn bip68 rather than master branch, ping @maaku
< DocHex> btcdrak: (it's been updated) if you have a link to something about what's missing in BIP62, or what remains to be done, I'm happy to link to that on the blog too.
< CodeShark> hmm...seems related to BIP34
< phantomcircuit> gmaxwell, well lets see, of the things on the BIP62 list the first is BIP66, right?
< gmaxwell> phantomcircuit: IIRC they aren't even all implemented, and as far as bip62 goes many were only to be applied to higher versioned transactions which don't exist.
< phantomcircuit> gmaxwell, at this point it seems like it would be best if BIP62 rules were made IsStandard
< gmaxwell> http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high "BIP62 is not currently deployed and we encourage all miners to enforce it as soon as possible." 0_o
< CodeShark> one of the goals, rusty, is to separate the review of BIPs for their features from the review of the deployment strategy


< btcdrak> since BIP113 builds on 68
< sipa> bip68 doesn't change locktime semantics
< btcdrak> gmaxwell: and in that case, it means BIP68 is required too.
< gmaxwell> maaku: has there been any objections (at all) to BIP113?
< btcdrak> maaku: so we could actually merge BIP112 now
< maaku> (it's kinda silly to have BIP112/CSV without BIP68/sequencenumbers, but technically they do not depend on each other in the same way that CLTV does not actually depend on nLockTime doing anything)
< maaku> BIP113 / #6566 builds off #6312
< maaku> BIP68 / #6312 and BIP112 / #6564 are dependency-free
< btcdrak> wumpus: BIP68 redefines nSequence, BIP112 creates an opcode for it.
< wumpus> BIP112 is 'CSV' right? are the others depndent on that?
< btcdrak> BIP112 Mempool-only CHECKSEQUENCEVERIFY https://github.com/bitcoin/bitcoin/pull/6564
< btcdrak> BIP113 Mempool-only Median time-past as endpoint for lock-time calculations https://github.com/bitcoin/bitcoin/pull/6566
< btcdrak> BIP68 Mempool-only sequence number constraint verification https://github.com/bitcoin/bitcoin/pull/6312
< sipa> i think we want to discuss things like the ongoing BIPs
< Cocodude> Got it. I'll keep an eye on BIP62's progress
< wumpus> Cocodude: that's BIP62, not BIP66. BIP66 forces strict DER encoding for signatures, it does not address other malleability issues
< Cocodude> A follower on twitter interestingly stated that BIP66 should have sorted out the fake double spends. Is BIP66 live?
< jgarzik> I wish BIPs were assigned 8-letter alphabetic codes; easier to disambiguate ;p
< btcdrak> jgarzik: Should be clear in the BIP68 text.
< jgarzik> Sorry, got my BIPs mixed up. It's BIP 68 that I need to understand deeply & thoroughly.
< btcdrak> jgarzik: BIP112 cites references where there are a ton of other uses
< jgarzik> Trolling for reviews, add bip32 pub key serialization #6215 https://github.com/bitcoin/bitcoin/pull/6215
< gmaxwell> in any case, still leaves the general BIP62 problem that we're really not sure we got all the mutation vectors. :(
< gmaxwell> for BIP66 we couldn't afford any debate, as we really needed to get the openssl consensus fix in, otherwise it would have been interesting to do it there.
< gmaxwell> if your transactions are BIP62 friendly you get no mutation, otherwise you're always mutated.
< CodeShark_> this raises an interesting point...BIP62 could be deployed along with a new relay policy that mutates transactions...
< gmaxwell> Even in BIP66 it was going to be version gated.
< CodeShark_> BIP62 does that - BIP66 was pushed out as a fix to a more urgent issue
< petertodd> no, bip66 doesn't deal with low-s/hig-s


< sipa> that's how the BIP34/66 implementation works as well