< morcos>
sipa: what were you wondering about with regards to BIP68 and the wallet. the previous implementation had code to indicate if your wallet txs were non-final which i removed. but that should be quite rare as it won't end up in your mempool in the first place
2016-02-08
< petertodd>
wumpus: I kept on getting pull-reqs meant for bitcoin/bips myself
< wumpus>
in a way having bitcoin/bips at the root is advantageous
< Luke-Jr>
wumpus: can you ask support@github.com to relink bitcoin/bips to the same network as genjix/bips?
2016-02-04
< jtimon>
I believe btcdrak somehow took over maaku's bip68/bip112 opened bips with no problem, maybe someone else can create it and somehow transfer control to you or something (random thoughts, who knows how github works inside for this)
< jtimon>
Luke-Jr: what do you mean? the parent of petertodd/bips was genjix/bips in github?
< Luke-Jr>
jtimon: a few weeks ago it seems they delinked genjix/bips from the rest
< jtimon>
Luke-Jr: just curious, has the github bug anything to do with the fact that bips is not a "base project" but a fork of ptodd's?
< jtimon>
mhmm, I believe destroying your repo, forking bitcoin/bips again, etc would solve it
< jtimon>
Luke-Jr: ack on number, or at least just open a PR to the bips repo
< Luke-Jr>
I should assign a number for biprevised so I don't need to keep saying "my BIP" for it..
< jtimon>
Luke-Jr: thanks for answering many questions, this was really helpful (but could have been even more productive if you had read bip99)
< jtimon>
last question: is it fine if bip99 stays as a darft while I wait to rebase the informational part on top of yours and move the code/hardfork-proposal part to a different bip to be linked from this one?
< jtimon>
Luke-Jr: how do you know if you haven't read bip99 yet?
< jtimon>
Luke-Jr: "hardforks should never use miner voting" as you hopefully know already, bip99 (and I believe petertodd) directly contradicts this, modulo s/miner voting/miner upgrade coordination/
< jtimon>
well the premise in bip99 is that uncontroversial things require bip9 regardless of them being softforks or hardforks
< jtimon>
Luke-Jr: I already admited we disagree on whether an asic-reset hardfork is intrinsically controversial (as bip99 indicates) or not (as you believe), let's please agree to disagree on that
< jtimon>
the recommendation in bip99 should be that if freiforkers know beforehand the two branches will never merge, they should consider starting an altcoin instead of a controversial hardfork
< Luke-Jr>
jtimon: "A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork has potentially-majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption.
2016-02-02
< Ylbam>
about 2015-12-10 IRC meeting minutes, it was about BIP68
< what_now>
There's also so much to keep up with regarding this project, so many bips so many discussions feels like its gonna take forever to get to a decent level. At the same time.. I can't leave you guys alone and have only 5-10 people know wtf is going on with everything :)
< phantomcircuit>
jonasschnelli, anybody using BIP70 payment protocol is already at extreme risk accepting unconfirmed transactions
2016-01-20
< warren>
ths, and also set a deadline for HF wishlist item implementation (BIPs and code) for a scheduled hardfork in early 2017. Whatever isn't fully approved in peer tech review before that deadline is cut. Everyone could become far more productive if we agreed to end the drama and work on real improvements together in this manner?
< jl2012>
BIP141 will allow only 1.75MB with normal use
< jl2012>
"2MB now but not activate it until 2017-01-01" is basically another BIP102. Personally I don't think it is bad, if the date is far enough
2016-01-13
< GitHub52>
bitcoin/0.12 5771b71 Wladimir J. van der Laan: doc: Remove BIP65 mention from release notes...
< michagogo>
Release notes talk about BIP65 locking in in future tense...
< jtimon>
CodeShark: and you really don't need to touch the old softfork stuff to implement bip9, that's actually one of the complains rusty had about your implementation (he didn't in his)
< CodeShark>
making it easier to deploy testnets with specific bips applied
2016-01-02
< jonasschnelli>
Luke-Jr: The write cycles and space of EPROMs are limited, ... so bip32 makes perfect sense for tiny devices.
< Luke-Jr>
jonasschnelli: eh, hardware wallets shouldn't realistically need software BIP32 support.. seems like just an excuse on their part to not do it IMO
< jonasschnelli>
Luke-Jr: right now, most(all?) hardware wallets use bip32 and do not store keys in the EPROM (just the seed). A bip32 pubkey only wallet in core would allow to use `create/fundrawtransaction`, take the hex, transmit it to the hardware wallet, get the signed hex back...
< jonasschnelli>
Luke-Jr: I still follow both plans... short term (0.13) I'd like to get a simple form of bip32 into the existing wallet. why: allows simple support of hardware wallets
< morcos>
if so we should be concentrating core development effort on all of these things so we can show progress. versionbits, BIP68/CSV, segwit
2015-12-22
< dcousens>
sipa: not sure of how bitcoind handles it, but, conceptually, in regards to say watching a BIP32 tree, and trying to 'rediscover' it, you'd be able to track whats used based on a deterministic witsig scriptpubkey
2015-12-18
< btcdrak>
(and BIP113 must be activated with BIP68)
< btcdrak>
JackH: #6564 is the CSV patch specifically, although we need BIP68 as well.
< morcos>
It seems resonable to me that within a month or two of releasing 0.12 we ought to be able to release a soft fork patch for BIP68
2015-12-17
< Luke-Jr>
good catch with the biplist difference
< jonasschnelli>
I think you need a "import biplist"
< jonasschnelli>
Luke-Jr: NameError: name 'biplist' is not defined
< Luke-Jr>
biplist is builtin to Python nowadays I think
< jonasschnelli>
I think your PR does the right, thing, expect of the byte-fiddling, why could you not use "biplist.Data(alias.to_bytes())"?
< jonasschnelli>
Luke-Jr: but `biplist.Data(alias.to_bytes())`?
< dcousens>
It'd be cool to see how much usage BIP65 has received over the last few days
2015-12-14
< btcdrak>
BIP65 enforced
< jcorgan>
jonasschnelli: i've also been chewing on the idea a "password keeper" that generates/regenerates passwords using BIP32-derived secret keys
< jonasschnelli>
A GPG/SSH hw wallet infrastructure that works together with bip32 would be a better solution.
2015-12-03
< jtimon>
btcdrak: could you make me a branch with bip68 and bip112 on top of 3cd836c1 ?
< jl2012>
Why Antpool is not upgrading to BIP65? It is the last major pool to upgrade
2015-12-02
< morcos>
yeah, thats' what i'd like to get out of it, except only the BIP68 valid height and time
< morcos>
releasing BIP68 soft fork i mean
2015-12-01
< gmaxwell>
Luke-Jr: would still require updating software. Come one, for BIP66 I recall having to pull teeth to get a new libblkmaker from you. :)
2015-11-28
< sipa>
so you can't validate bip65/bip112 that way :(
2015-11-25
< tulip>
it looks like there's mining software on the main network which is rolling the sequence number. not disastrous or particularly interesting at the moment, but it might be notable if anybody is altering the behaviour of sequence numbers with a consensus rule like in BIP112.
2015-11-24
< gmaxwell>
raskolnnikov: full nodes can freely omit transactions, thats one of the limitations in the design of BIP37. There are other schemes which lack that limitation which are possible but have not been implemented yet.
< tulip>
do you realise that BIP37 only allows lying by omission in most circumstances?
< gmaxwell>
raskolnnikov: it does not necessarily provide the whole block, the block can be filtered in way that proves the filtered subset is in there. See BIP37.
< tulip>
I didn't think btcd implemented BIP37 anyway?
2015-11-16
< GitHub193>
bitcoin/0.11 9730051 Alex Morcos: add bip65 tests to rpc-tests.sh -extended
< GitHub34>
[bitcoin] laanwj closed pull request #7021: add bip65 tests to rpc-tests.sh -extended (in 0.11 branch) (0.11...11rpcfixups) https://github.com/bitcoin/bitcoin/pull/7021
< gmaxwell>
for me bitcoin core sync runs at around 8000tx/s (with secp256k1), even though every tx is involving a non-cachable missing record check for bip30 (in addition to all the cached stuff)... thats really quite remarkable IMO.
2015-11-15
< GitHub64>
[bitcoin] morcos opened pull request #7021: add bip65 tests to rpc-tests.sh -extended (in 0.11 branch) (0.11...11rpcfixups) https://github.com/bitcoin/bitcoin/pull/7021
2015-11-13
< sdaftuar>
Luke-Jr: i wanted to follow up on the issue you reported with that bip65-cltv-p2p test this morning. i updated the issue with my observations
2015-11-12
< GitHub129>
bitcoin/master 33c90cf Alex Morcos: Make skipping BIP30 check chain agnostic
< GitHub129>
bitcoin/master 06d81ad Alex Morcos: Skip BIP30 check after BIP34 activation
< sipa>
bip37-based downloading does too
2015-11-10
< wangchun>
Dear core devs, how do you plan to response to the latest actions regarding BIP101?
2015-11-09
< GitHub130>
[bitcoin] laanwj closed pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
< GitHub67>
bitcoin/master c53d48a Jorge Timón: BIP70: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings...
2015-11-08
< btcdrak>
well it's probably just better to point them to BIP113
< harding>
michagogo: that's what I figured too, worst case they don't get used. :-) I think I'm almost done; I'm just trying to figure out good wording for the BIP65 stuff.
< GitHub88>
bitcoin/master c939792 Peter Todd: Add BIP65 CHECKLOCKTIMEVERIFY to release notes
2015-10-30
< gmaxwell>
the constant ancestor tests are slightly annoying but much better than running bip30 everywhere.
< gmaxwell>
yea, so we could disable BIP30 when BIP34 acitivates if and only if the the ancestor chain is the real one.
< sipa>
even post BIP34, a transaction that spends a previous duplicate coinbase is possible (in an alternative chain)
< gmaxwell>
Right but we could enforce BIP30 for all chains until the point where BIP34 activates.
< sipa>
gmaxwell: BIP34 or not is not enough
< gmaxwell>
sipa: the existing BIP30 violations overwrote without proliferation.
< sipa>
morcos: fundamentally, the bip30 check can be disabled for any transaction that depends on a bip34 coinbase
< sipa>
as BIP34 is only sufficient when there are no actual duplicate coinbases
< sipa>
gmaxwell: i'm trying to think whether enforcing it for all blocks (except those two) that don't have BIP34 is safe
< GitHub118>
[bitcoin] sipa closed pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
< GitHub92>
[bitcoin] sipa opened pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
< sipa>
morcos: we should get rid of the bip30 check; it's superseeded by bip34
< morcos>
sipa: still afk, but yep, thats a cause of SIGNIFICANT slowness in ConnectBlock. I think we'd have to change/remove the BIP30 check to really eliminate it, which might be the harder part, bc I think adjusting ModifyCoins to know its a new tx and not lookup seems easy and safe?
< morcos>
Also do we need to persist the BIP30 check? Is it still possible to violate that or now that the old duplicate coinbases are sufficiently buried, its not necessary
< morcos>
There is already an existince check for BIP30 earlier
2015-10-29
< GitHub107>
[bitcoin] jtimon opened pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
< gmaxwell>
For the nussance things, non-standardness is sufficient. For contracts BIP62 is insufficient, but CLTV covers a lot of them.
< sipa>
so if the network accepts those rules, we don't even need v2 transactions in bip62... just unconditionally make violations of its rules fatal
< gmaxwell>
BIP62 is infintely far off right now, no one is working on it. And I don't think the approach is likely to be very successful; except for blocking malleability in a few narrow cases (which we've already been breaking out)
< sipa>
all of bip62's rules are already nonstandard in 0.10.3 and 0.11.1
< sipa>
bip62 can be simplified a lot now, if we want just that
< aj>
gmaxwell: i was assuming that was a lot further off than bip62 though?
< 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