< 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?
2015-10-27
< 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
< 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.
2015-10-26
< 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
< 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
< 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