< GitHub95>
[bitcoin] jl2012 opened pull request #8514: Enforce LOW_S rules on all transactions with WITNESS BIP9 parameters (master...lows) https://github.com/bitcoin/bitcoin/pull/8514
2016-08-11
< wumpus>
in any case BIP152 has the number: A new inv type (MSG_CMPCT_BLOCK == 4) and several new protocol messages are added: sendcmpct, cmpctblock, getblocktxn, and blocktxn.
< wumpus>
does it cost a node a lot of resources to verify BIP66 compliance? if not, why does it warrant DoS banning?
< jtimon>
instagibbs: also bip66, bip65 and bip112, no?
< sipa>
so that's why BIP66 is not part of mandatory flags
< sipa>
and we would ban them if they send a BIP66-invalid transaction, for example
< wumpus>
#topic raising mandatory script flags to include bip66
< kanzure>
luke-jr: that's at best an argument for your segwit bip9 activation decoupling idea.
< jtimon>
if they go in the same release, why separate them in the bip9 sense?
< jtimon>
I mean, we can also deploy low-s in, say 0.12.2 before segwit (oh, wait, backport bip9)
< luke-jr>
(separate in the BIP9 sense, not necessarily a different release)
< luke-jr>
(huh, it occurs to me - not a real suggestion - that we *could* have de-bundled the block size increase from segwit into a separate BIP9 bit, so long as all deployment of segwit included support for the separate blocksize-increase bit; IMO interesting)
< instagibbs>
(duh, bip9)
< instagibbs>
Oh, if the two bip9 aren't packaged, I think we should
< wumpus>
sipa proposed some topics earlier today: 1) segwit policy limits 2) can we propose a softfork to make low-s required simultaneously with segwit? 3) 3) raising mandatory script flags to include bip66 4)
< sipa>
wumpus: just so i don't forget, a few topics for the meeting 1) segwit policy limits 2) can we propose a softfork to make low-s required simultaneously with segwit? 3) raising mandatory script flags to include bip66?
< sipa>
but mandatory doesn't even include BIP66
2016-08-10
< cfields>
got it. Ok, I'll PR a few clarifications there. Was trying to implement soley based on reading of bip9 changes.
< cfields>
luke-jr: (i'm implementing the bip9 gbt changes in ckpool)
< GitHub7>
[bitcoin] laanwj closed pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< GitHub52>
bitcoin/0.13 8b0eee6 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates...
< GitHub120>
[bitcoin] luke-jr opened pull request #8495: [0.13] Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (0.13...bugfix_gbt_sigops_presegwit-0.13.x) https://github.com/bitcoin/bitcoin/pull/8495
< jonasschnelli>
gmaxwell: I guess theres nothing holding back power users of doing this with the current bip151 (+auth) specification..
< gmaxwell>
largely unrelated to BIP151 there is a question of it you'd like to have long lived node identities.
< sipa>
gmaxwell: well in light of bip151... should they also carry a host pubkey?
< GitHub114>
[bitcoin] laanwj closed pull request #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (master...bugfix_gbt_sigops_presegwit) https://github.com/bitcoin/bitcoin/pull/8489
< GitHub4>
bitcoin/master edebf42 Wladimir J. van der Laan: Merge #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT)...
< GitHub4>
bitcoin/master 160f895 Luke Dashjr: Bugfix: Use pre-BIP141 sigops until segwit activates
2016-08-08
< GitHub3>
[bitcoin] luke-jr opened pull request #8489: Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (master...bugfix_gbt_sigops_presegwit) https://github.com/bitcoin/bitcoin/pull/8489
< sipa>
Chris_Stewart_5: bip37
2016-08-06
< jonasschnelli>
gmaxwell: sipa: I guess the current bip151 rekeying has no forward secrecy. It's hash(old-sym-key). What about hkdf(ecdh_secret, old_syn_key) instead?
2016-08-05
< sipa>
paveljanik: bip112
< jtimon>
bip113 was deployed separately
< sipa>
at the block/tx level, you'd have bip16, bip34, bip66, bip65, bip68_112_113, bip141
< jtimon>
why are bip68_112_113 together?
< jtimon>
agree on what you said about the caller, disagree that I want to expose more details than necessary to the caller, I'm happy to merge bip68 and bip112 flags, that seems orthogonal
< jtimon>
but you don't want verifyScript to receive a CSV_bip68_bip112 flag that it internally maps to SCRIPT_VERIFY_CHECKSEQUENCEVERIFY (ignoring bip68 because at the script level it doesn't care)
< jtimon>
I see, you want the block level ones to correspond with deployments, ie bip68 and bip112 go together
< sipa>
and BIP16 would map to script verify P2SH
< jtimon>
well, the flags for BIP68 and for BIP112 are separated in that branch
< jtimon>
say I want to call verifytx specifying that I want p2sh and bip113 validated
< jtimon>
there's no flag for say bip68 and bip113, because thouse would be needed for verifyTx, but not for verifyScript
< jtimon>
well, what we're exposing in libconsensus are the BIP9/older_sf flags, no?
< sipa>
there would be SCRIPT_VERIFY_CHECKSIGAWESOME, and a BIP9 deployment AWESOME
< morcos>
"If a miner wishes to limit the actual size of a block in bytes then it is necessary to specify a blockmaxsize explicitly. If a miner wishes only to limit block creation by weight (BIP141) regardless of how large in bytes the block is they should only specify a blockmaxweight"
2016-08-04
< jtimon>
/** Block hash at which BIP34 becomes active (for BIP30 optimization)*/
< jtimon>
uint256 BIP34Hash;
< jtimon>
NicolasDorier: you are not removing BIP34Height BIP65Height and BIP66Height in Consensus::Params
< NicolasDorier>
jtimon: I think one bool is enough. fAllowOverwriteSoftforks which both BIP9 and buried SF use
< jtimon>
the advantages are code simplification and a slight optimization (really no need to call GetAncestor if you don't care about the hash), and keep the optimization in case of pre-bip34 reorg, which is arguably a disadvantage
< jtimon>
so, yes, theoretically always checking bip30 after bip34 has certain risk if there's that reorg...but aren't we screwed if that happens anyway?
< morcos>
checking BIP30 is exteremely slow
< morcos>
jtimon: yes you can either always check BIP30 even after BIP34, or you can examine the chain you're on pre BIP34 and decide whether you can now skip BIP30 checks (which is what we decided to do with mainnet, but requires manual intervention)
< morcos>
are you opposed to leaving in the BIP34 hash
< jtimon>
my node would not check bip30 after bip34, even after the reorg
< jtimon>
and then a node without my change would always check bip30, even after bip34 activation, is that the desired behaviour?
< morcos>
you can try this on regtest.. enforce BIP30 only up to height 100 and BIP34 only starting at height 100. create some coinbases, spend them and then create duplicates before 100.
< jtimon>
yes, from now on you can stop checking bip30 in new blocks
< morcos>
then you can spend A' and create the same txid as your spend of A b/c you aren't enforcing BIP30 any more
< morcos>
then you create coinbase A' (allowed b/c it doesn't violate BIP30 , A is spent, and BIP34 is not active yet)
< morcos>
now you activate BIP34 at height 227931
< jtimon>
after bip34 activation, it is no longer necessary
< jtimon>
bip 30 is checked before bip34 always except the exceptions
< jtimon>
in a reorg that deep, if it was activated with another block, then bip30 will be checked always regardless of bip34 activation (no optimization, never)
< jtimon>
with my suggested change, it would always do the optimization after bip34 activation height, even after such a long reorg
< jtimon>
what is doing now is that if you are above that height and the block you activated bip34 in is 227931, then don't enforce bip30 since bip34 is enforced
< morcos>
maybe because BIP30 is enforced for everythign except those two exceptions you're ok
< jtimon>
and what we have now, if it reorgs that long, without code for ISM...what? bip34 is going to be activated at that height no matter what
< jtimon>
I think it will only fail if we reorg below BIP34Height (227931)
< morcos>
jtimon: its incorrect in that it'll be broken code on a mainnet chain that doesn't contain BIP34hash
< morcos>
i can't remember off the top of my head, but if in an alternate chain you spent coinbase A before you generate coinbase A' then you activated BIP34, then you still need BIP30 to make sure the spend of A' doesn't conflict with the spend of A
< morcos>
but in the BIP34hash chain we know that didn't happen
< morcos>
if you activated BIP34 at the same height on a different chain, it would be unclear whether yous till needed to do BIP30
< morcos>
jtimon: no, when you use BIP34 on the existing BIP34 hash then you dont' need to do it
< jtimon>
you cannot remove it completely, but when you use bip34 you don't need to do it (this is current behaviour)
< morcos>
you can't remove the BIP34Hash unless you are going to checkpoint the chain at that point
< sipa>
isn't there some interaction between BIP30 and the no-overwrite optimization in coinscache?
< sipa>
which needs a BIP30 check during IBD
< NicolasDorier>
morcos: so basically we could remove BIP30 altogether as this is unlikely another chain manage to catch up the amount of work of the current one
< morcos>
It's related. The point is once you are enforcing BIP34 then BIP30 is unnecessary except for historical violations. We're changing the rule to have BIP34 be enforced as of a certain height, however, it kind of requires that the chain be the same otherwise we dont' know what the historical violations are or might be
< michagogo>
My first thought was, wtf? Why is a list of BIPs its own package?
2016-07-28
< GitHub133>
bitcoin/0.13 8360d5b Jorge Timón: libconsensus: Expose a flag for BIP112...
< GitHub127>
[bitcoin] sipa closed pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412
< GitHub106>
bitcoin/master ad08763 Pieter Wuille: Merge #8412: libconsensus: Expose a flag for BIP112...
< GitHub106>
bitcoin/master d12b732 Jorge Timón: libconsensus: Expose a flag for BIP112...
< sipa>
jtimon: i vaguely remember there were ugly interactions between the cache code that avoids some database operation, bip30 and bip34... but i don't remember the details
< NicolasDorier>
jtimon: I'd like to see it go personally, but I don't know the reason why bip34Hash was here in the first place
< sdaftuar>
it has one changed behavior, the new command line option -bip9params
2016-07-27
< jtimon>
never mind, updated without bip112 at the end
< GitHub48>
[bitcoin] jtimon opened pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412
2016-07-26
< da2ce7_mobile>
yeah. It would be great if BIP44 had a 'hardened only' option.
< jonasschnelli>
gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
< jonasschnelli>
I just think people would like to stick to bip44 or something in order to use the seed in other wallets once they want to move away from Core
< jtimon>
it will be replaced and we can leave it all preapare for where it will be replaced with something like bip34 and that will simplify things, I believe
< sdaftuar>
i wonder if there are cases where we might want to test how a chain behaves when some blocks don't satisfy a rule (like bip34) and then later ones do.
< gmaxwell>
sipa: see consensus.BIP34Height = 227931;
< jtimon>
but I still believe that the refactor is much simpler if we put temporarily the locktime flags and the new ones (bip30 and bip34) in the script flags and then we separate them
< jtimon>
sipa: I've been thinking more about the consensus vs script flags, I guess it has the advantage of having a much shorter list of consensus flags, basically only one per consensus deployment (well, we can keep bip68 and bip112 as separated flags), while the script flags have many more thant in principle don't need to be exposed in libconsensus
< jtimon>
Ideally we would use an array, I wish I had seen the PR for BIP34 when it was open...
< jtimon>
NicolasDorier: yeah, hardcoding the activations in Consensus::Params like CodeShark did with bip34, the other day gmaxwell said he was working on suh a branch
< sipa>
BlueMatt: the alternative for the bip32 derivation is that we'd use the private key of the generated root as master key (with chaincode stored on disk), rather than treating it as a seed
< sipa>
bip32 does not have any
2016-07-18
< wumpus>
there's also at least one other implementation of segwit that will have to be changed with the BIP141 change (the btcd implementation)
< sdaftuar>
it seems strange to me that we'd choose to redefine a term...? at the least we'd have to say "total BIP141-sigops" or something
< wumpus>
maybe just change the help message to "Set maximum BIP141 block cost"
< wumpus>
e.g. generating errors like 'this wallet uses BIP32 which is not supported in this version'
2016-07-17
< btcdrak>
I think we should update softfork BIPs directly with activation heights.
< btcdrak>
jtimon: I dont have any objection to consensus/flags.h - i only have an objection to stuffing unrelated things into units which have a specific purpose. versionbits.cpp is clearly for BIP9 logic. I would have thought this is self evident :-p :)
< gmaxwell>
jtimon: yes the if statement at the top changes, e.g. into nheight >= consensusParams.bipblahblahHeight -- the check itself would logically remain in ContextualCheckBlock.
< gmaxwell>
just elements of consensus. consensus.BIP65Height yadda yadda.
< sipa>
(as can the new script versions introduced by BIP143)
< sipa>
xinxi_: BIP143 (which we're in the process of finished up) makes that very easy
< jtimon>
bip2 tries to clarify things, but it can only decided on whether something was "accepted" or not observing adoption a posteriori. BIP99 also tries to clarify things, but it's based on a vaguely defined concept of "uncontroversial"
< sipa>
BIP34 used block versions above a certain number to let miners indicate they are enforcing the new rules
< sipa>
BIP30 used a fixed timestamp for the changeover point
< jtimon>
xinxi_: for softforks bip9 describes it, for hardforks there's different opinions on what would be the best way to signal activation
< sipa>
xinxi_: there is also BIP50 which is a post-mortem of a consensus failure that occurred between old and new versions of the system
< sipa>
(BIP9 is newer)
< sipa>
a soft fork: read BIP34 and BIP9
< jtimon>
for example, the code in bip99 fixes a known bug which is not a priority
< jtimon>
I was working on https://github.com/jtimon/bitcoin/commits/jt but I broke the branch when backported bip9 and never cared to fix it (but review is still very welcomed since I plan to rewrite/cherry pick most of the stuff from there)
2016-07-12
< bsm117532>
sipa: okay, I'm comparing to your bip141 which writes scriptPubKey as: 0 <20-byte-key-hash>, but obviously b'' <20-byte-key-hash> is equivalent.
< sipa>
or through the bip35 mempool command
2016-07-11
< btcdrak>
yes, he means BIP66
< sipa>
and it triggered when bip65 activated
< sipa>
not bip66, which was a year earlier
< Chris_Stewart_5>
sipa: I just read the email, however the hard fork last July wasn't related to the implementation of BIP66 , it was just spv mining correct?
< sipa>
xinxi: have you read my BIP66 writeup above?
< Chris_Stewart_5>
Bip66 (or was it 62) comes to mind
< jtimon>
that's useful, what about the bip34 check in ContextualCheckBlock(), can it be moved out?
< sipa>
validating bip113 is not necessary i think
< jtimon>
if we know it's not making a longer chain, why bother validating BIP113 ?
< GitHub127>
bitcoin/master 5077d2c Wladimir J. van der Laan: Merge #8303: [Doc] Update bips.md for CSV softfork....
2016-07-07
< 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