[bitcoin-dev] BIP68: Relative lock-time through consensus-enforced sequence numbers (update)
As I am sure you are aware, for the last 5 months work has been on-going to create a relative lock-time proposal using sequence numbers. The implementation can be found at https://github.com/bitcoin/bitcoin/pull/6312. The current implementation is "mempool-only" and the soft-fork would be deployed at a later stage. Over these months there has been various discussion back and forth to refine the details. I have updated the BIP text now according to the details that were discussed in mid-October[1][2] and have extensively clarified the text. To recap, the overall picture for relative lock-time is that BIP68 introduces consensus rules using some of the nSequence field, while BIP112 creates a new opcode OP_CHECKSEQUENCEVERIFY (PR #6564) so relative lock-time can be verified from the Bitcoin scripting language. Ideally we would soft-fork BIP68, BIP112 (CSV) and 113 (MTP) together. BIP113 has been deployed in 0.11.2 as mempool policy so miners should be applying this policy as they deploy version 4 blocks for the ongoing CLTV soft-fork (currently at 42% at the time of writing). I am writing this mail to draw your attention to the BIP68 pull-requests and to request final review at: BIP68 text - https://github.com/bitcoin/bips/pull/245 BIP68 implementation - https://github.com/bitcoin/bitcoin/pull/6312 Discussion references: [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011357.html [2] http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444928045.0 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamic Hierarchical Deterministic Key Trees
Tamas, You could use a key for both signing and for derivation of a deeper level (and perhaps there are some applications for this, if you think of any please let me know), but the use cases being considered involve generation of signing key sequences from seeds that are easy to backup and easy to share with others to simplify multidevice synchronization, key management, account structures, etc... while also allowing for privacy by making it nontrivial to associate transactions for an account without knowing the seed/chain code. As such, we generally refer to such sequences by a path to the immediate parent node in the tree and reserve the children themselves for the signing keys. - Eric -- Original Message -- From: "Tamas Blummer" To: "Eric Lombrozo" ; "Eric Lombrozo via bitcoin-dev" Sent: 11/17/2015 5:10:17 AM Subject: Re: [bitcoin-dev] Dynamic Hierarchical Deterministic Key Trees Hi Eric, Would you please enumerate, or point to, arguments that discourage the use of a key both for signing and for derivation of a deeper level of the hierarchy ? Tamas Blummer On Nov 17, 2015, at 12:40, Eric Lombrozo via bitcoin-dev wrote: I've submitted a BIP proposal that solves the issue of needing to predefine HD wallet structures and not being able to arbitrarily nest deeper levels. Comments appreciated. https://github.com/bitcoin/bips/pull/242 - Eric ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
