< sipa>
bip144 adds an extra serialization flag that is not hashed into the txid
< jonasschnelli>
gmaxwell, sipa: Bip151: what do you think by using HKDF instead of a single SHA_HMAC to derive the symmetric cipher key from the ECDH secret?
2016-07-06
< sipa>
how to serialize the witness data, read bip144
< dgenr8>
The partition risk to XT is a result of your sneak attack on its usage of bip37 for the original thin blocks mechanism. Thanks for that.
2016-07-01
< gmaxwell>
K. indeed 0.12 doesn't have BIP152. Perhaps that does suggest that it should default to four million in 0.13?
< gmaxwell>
luke-jr: we have BIP152 now.
< jl2012>
arubi: without BIP62, that's not reliable
<@wumpus>
at least for BIP32, in contrast to coin selection, the goal is well-defined and delimited :)
<@wumpus>
yes, that is true, ideally that should use some BIP32 construction
2016-06-30
< sipa>
2) needs some BIP changes (in BIP144, BIP152, or a separate bip entirely)
< sipa>
1) this allows us to test interaction between non-SW-BIP152 testnet and changed
< petertodd>
gmaxwell: as in, segwit bip152 right? +1
< gmaxwell>
#topic BIP152
< sdaftuar>
maybe bip152?
2016-06-28
< gmaxwell>
yes, thats an initially useful application, though we should also be considering directing our attention toward reducing relay overhead, because with BIP152, it's now the biggest user of bandwidth on a listening node.
2016-06-27
< dgenr8>
the best thing for bitcoin is for you guys to adopt bip109
< dgenr8>
so "yes" then? (since not only bip9 but anything in the block header is showing miner support)
< sipa>
dgenr8: i believe bip9 is unsuitable for hardforks
< gmaxwell>
if it were 109 I would have expected it to not trigger BIP9 due to the longer activation window and higher trehshold.
< sdaftuar>
wumpus: i assume the bit 28 activation on TESTNET is a bip109 thing (nothing to do with TESTDUMMY, which inadvertently reused the same bit)
< sipa>
and then there is bip130, which introduces direct fetch in response to headers
2016-06-23
< gmaxwell>
and part of the reason why BIP9 flag changes happen at retargets is to make the header unpredictable at the same time the bits change makes it unpredictable.
< da2ce7_mobile>
I really like BIP9. It is a really elegant solution and upgrade.
< gmaxwell>
Because past softforks would orphan your blocks if you had the wrong version. We specifically got rid of that behavior in BIP9 in part to discourage faking the versions, but this improvement is not yet well understood and the software is already written.
< sipa>
da2ce7_mobile: BIP9 suggests that they don't
< gmaxwell>
Miners are turning off their BIP9 signaling manually (which is what I was fussing about a few days ago). It's no longer required as it locked in.
< gmaxwell>
And sure, on _mainnet_ having consensus rules change without released software would be _insane_, thats why BIP9 got a starting date... but for testnet, that can make sense.
< sipa>
but for example, #7935 introduced the concept of gbt_force (bip9 rollouts which the GBT client needs explicit support for)
<@wumpus>
is there any way to see (in the GUI or through RPC) if a wallet is BIP32?
< gmaxwell>
is true is 224413, which seems to suggest that the BIP34 height in the chainparams is wrong?
< sipa>
btcdrak: bips.md has more info
< btcdrak>
gmaxwell: do you mean BIP34? according to the BIP text "Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block."
< btcdrak>
luke-jr: maybe we should update the BIPs with activation blocks when they activate
< btcdrak>
gmaxwell: BIP65 was activated on block #388380
< gmaxwell>
Anyone have exact IsSuperMajority heights for BIP30/65/66 on mainnet and testnet handy, by any chance?
2016-06-21
< jl2012>
i think all transactions including coinbase are subject to nLockTime and BIP113 rules
< jl2012>
4. make sure the coinbase tx compiles with BIP113 (in case someone use nLockTime for mining --> unlikely)
< jl2012>
3. make sure the coinbase tx compiles with BIP68
< jl2012>
Some miners didn't really understand bip9
< gmaxwell>
So the expectation with bip9 was that since it was no longer forced there would be no incentive to lie, and at least the measure of upgrade status would be faithful.
< gmaxwell>
This is seriously fucked up, miners signaling versions inconsistent with the consensus rules they were running already forked the network once and narrowly avoided an incident. BIP9's design was partially motivated in avoiding that. (with no "set version or get orphaned" the beliefe was there would be no reason to fake it.
< gmaxwell>
I thought BIP9 got us there, but apparently I was mistaken. An intended feature of the design isn't working.
< gmaxwell>
if it's most of the hashpower it means that BIP9 is a currently failed design. The initial switch to signal CSV was _Exactly_ at the starting time, so I felt confident that the version numbers weren't being faked.
< gmaxwell>
I think BIP9 is too unsafe to use with parties manually setting the bits. The issue is if they have old nodes that don't enforce the consensus rules and they're failing over to them and getting work from them it can split the network, and it would be completely silent.
< gmaxwell>
Since we're now aware of miners manually setting version bits we should start work on a new deployment mechenism and depricate BIP9. :(
< jl2012>
just want to confirm: during bip9 locked_in, blocks with any nVersion >=4 are valid?
2016-06-20
< btcdrak>
BIP9 spec
< btcdrak>
see BIP112
< btcdrak>
BIP141
< spudowiar>
I'll check them BIPs out
< btcdrak>
spudowiar: the current softfork bundle of BIP68,112,113.
2016-06-16
< luke-jr>
sipa: something to trigger BIP9-aware clients not to try merging the template
< Chris_St1>
sdaftuar: So BIP9 parameters need to be set in the pull request before being merged into master correct?
< MarcoFalke>
When the bip32 stuff is merged, we should make sure the test framework still runs the legacy wallet sometimes
< jonasschnelli>
sipa: Re bip32: You mentioned if users set -usehd=1 it should detect and abort when running on a non HD wallet.
2016-06-09
< GitHub176>
[bitcoin] MarcoFalke opened pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186
< gmaxwell>
I think important big PRs I'd really like to have in 0.13 are SW, Compact blocks, CFPF related, and BIP32.
< gmaxwell>
If the digests idea had come up at the time of BIP37, I think it would have been implemented and filtering of relayed transactions wouldn't have been.
< gmaxwell>
dgenr8: the addition of filtering the current transactions was a 12th hour addition to BIP37, and for many users saving an average of 13kbit/sec for a total loss of privacy is not all that interesting just to see unconfirmed transactions that their wallets can't even tell are at all remotely possily correct.
2016-06-08
< gmaxwell>
BIP152 actually adds a sutiable mechenism-- getblocktxn that fetches txn in a block by index, that only works for recent blocks.
< GitHub123>
bitcoin/master 72cd6b2 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
2016-06-07
< sipa>
luke-jr: good thing BIP8 was never assigned https://en.wikipedia.org/wiki/BIP-8 (image what would happen if something related to error correction or checksums got that...)
< sipa>
A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
< sipa>
jl2012: feel like updating bip141 for the program size extension?
< 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
2016-05-24
< jtimon>
actually, maybe not a after bip9...
2016-05-23
< 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?
< 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