I’d like to propose a softfork deployment that activates the consensus changes outlined in
These changes make possible a number of use-cases that are broadly beneficial to users of Bitcoin, including
- vaults (reactive custodial security),
- efficient implementations of DLCs,
- non-interactive channel openings,
- congestion control,
- decentralized mining pools (via CTV compression in coinbase payouts),
- various Lightning efficiency improvements,
- using covenant based timeout-trees to scale Lightning, and more generally enabling channel factories.
We also see that many speculative scaling solutions (e.g. Ark, Spacechains) require locking coins to be spent to a particular set of outputs without any additional authorization (i.e. CTV, or APO’s emulation of it).
The patches for BIP-118 and BIP-119 have long been stable and well scrutinized; they each haven’t changed in some time.
BIP-345 (OP_VAULT) is the newest of the three by a good margin, and originally I was going to exclude it from this proposal. But after a number of discussions, it became clear that BIP-345 may be the most immediately usable of the three in terms of a major use-case:
- LN-symmetry (the major use of ANYPREVOUT) will require a good amount of time to coordinate deployment, and
- CTV, while an important primitive, has mostly niche direct uses (DLC efficiency, possible decentralized mining pools, congestion control, …) outside of BIP-345-style vaults.
Vaults with BIP-345, on the other hand, would be delayed only by the speed of wallet implementers. Example wallet implementations already exist, and the appetite for safer modes of custody is almost universally present among both industrial and individual users.
The implementation for these consensus changes is only about 7,000 lines, and that includes comprehensive testing. The limited nature of these changes relative to the last two softforks that we’ve had in Bitcoin give me some comfort in proposing the relatively young code for BIP-345 – with focused effort, the limited line count and tight scope will make it a tractable deployment to review.
I will be opening this branch as a draft PR in the Core repo.
The activation mechanism is currently drafted as the same modified version of BIP-9 described in BIP-341, but I am agnostic in this department. There is currently no signaling period specified - we will wait until further indications of consensus before choosing specific dates.
What do you think?