< 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
< 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
2015-10-05
< 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. :)
2015-10-04
< 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)) { }
2015-10-02
< 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.
< 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
< CodeShark>
one of the goals, rusty, is to separate the review of BIPs for their features from the review of the deployment strategy
2015-10-01
< 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?
< 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
2015-09-30
< sipa>
that's how the BIP34/66 implementation works as well