< December 2023 >
Su Mo Tu We Th Fr Sa 12
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
2016-01-02
< 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