< April 2024 >
Su Mo Tu We Th Fr Sa 1 2 3 4 5 6
7 8 91011121314151617181920
21 22 23 24 25 26 27
28 29 30
2016-05-23
< 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?
< 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.
< 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?
2016-05-14
< sipa>
sha512 is included in the source code for the purpose of bip32 derivation, but that functionality is not actually exposed
2016-05-12
< 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 ;)
< 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
< 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)
2016-04-19
< 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"?
2016-04-18
< 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
< 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....
< 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
< morcos>
sdaftuar: wumpus: i got a failure of bip68-sequence.py in 0.12.1rc2 . but its intermittant. looking into it.
2016-04-07
< 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)
2016-04-06
< Chris_Stewart_5>
why isn't the hash type being defined in the bip66 specification?
2016-04-05
< GitHub91>
bitcoin/master 92107d5 mruddy: RPC: add versionHex in getblock and getblockheader JSON results; expand data in getblockchaininfo bip9_softforks field.
2016-04-04
< 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
< 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
2016-03-30
< 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?
< sipa>
actually, the code snippet inside bip9 does define the behaviour fully
< Luke-Jr>
so to throw in a simply GBT section, how about "bips_supported":[141:28],"bips_required":[] ? does that seem practically complete?
< 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
< jonasschnelli>
What about using something similar than BIP32 to derive the session id, symmetric cipher key from the ecdh secret?
2016-03-29
< 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.
2016-03-24
< 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.
< 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)
2016-03-22
< 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
2016-03-20
< 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?
< 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)
< 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.
< 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
2016-03-11
< 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
2016-03-10
< 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?
2016-03-08
< 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)
2016-03-06
< 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
2016-03-04
< jtimon>
oh, bip9 now has a graph with the state machine, very nice
2016-03-03
< 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
< 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
2016-03-02
< sipa>
will look at it, once i'm done with some bip9 and segwit updates
2016-03-01
< 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.
2016-02-26
< 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?
2016-02-25
< 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
< 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?
< morcos>
I think it would be the wiser move technically and politically to do BIP9 first if we don't think the delay is too long. It's kind of the whole point of the thign.
< gmaxwell>
I am pretty fond of sipa's BIP9 implementation.
< GitHub137>
[bitcoin] jtimon opened pull request #7566: WIP: Implement BIP9 and get BIP113 to be deployed with it as an example (master...bip9-0.12.99) https://github.com/bitcoin/bitcoin/pull/7566