bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

[BIP-119] Slim down motivation, add more references

Browse Source
This commit is contained in:
Jeremy Rubin 2022-05-10 09:09:44 -07:00
parent b1791c24aa
commit de0ff362fc
1 changed files with 24 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

141
bip-0119.mediawiki
View File

@ -39,125 +39,24 @@ The recommended standardness rules additionally:
==Motivation==
Covenants are restrictions on how a coin may be spent beyond key ownership. This is a general
definition based on the legal definition which even simple scripts using CSV would satisfy.
Covenants in Bitcoin transactions usually refer to restrictions on where coins can be transferred.
Covenants can be useful to construct smart contracts. As covenants are complex to implement
and risk of introducing fungibility discriminants they have not been seriously considered for
inclusion in Bitcoin.
Covenants are restrictions on how a coin may be spent beyond key ownership.
This is a general definition based on the legal definition which even simple
scripts using CSV would satisfy. Covenants in Bitcoin transactions usually
refer to restrictions on where coins can be transferred. Covenants can be
useful to construct smart contracts. As covenants are complex to implement and
risk of introducing fungibility discriminants they have not been seriously
considered for inclusion in Bitcoin.
This BIP introduces a simple covenant called a *template* which enables a limited set of highly
valuable use cases without significant risk.
This BIP introduces a simple covenant called a *template* which enables a
limited set of highly valuable use cases without significant risk. BIP-119
templates allow for non-recursive fully-enumerated covenants with no dynamic
state. CTV serves as a replacement for a pre-signed transaction oracle, which
eliminates the trust and interactivity requirements. Examples of uses include
wallet vaults, non-interactive payment channel creation, congestion controlled
batching, efficient to construct discreet log contracts, and payment pools,
among many others. For more details on these applications, please see the
references.
A few examples are described below, which should be the subject of future non-consensus
standardization efforts.
===Congestion Controlled Transactions===
When there is a high demand for blockspace it becomes very expensive to make transactions. A large
volume payment processor may aggregate all their payments into a single O(1) transaction commitment
for purposes of confirmation using CHECKTEMPLATEVERIFY. Then, some time later, the payments can
be expanded out of that UTXO when the demand for blockspace is decreased. These payments can be
structured in a tree-like fashion to reduce individual costs of redemption.
The below chart showcases the structure of these transactions in comparison to
normal transactions and batched transactions.
<img src="bip-0119/states.svg" align="middle"></img>
A simulation is shown below of what impact this could have on mempool backlog
given 5% network adoption, and 50% network adoption. The code for the simulation
is provided in this BIP's subdirectory.
<img src="bip-0119/five.png" align="middle"></img>
<img src="bip-0119/fifty.png" align="middle"></img>
===Payment Channels===
There are numerous payment channel related uses.
====Batched Channel Creation====
Using CHECKTEMPLATEVERIFY for Batched Channel Creation is similar to the use for Congestion Control,
except the leaf node transactions are channels instead of plain payments. The channel can be between
the sender and recipient or a target of recipient's choice. Using an CHECKTEMPLATEVERIFY, the
recipient may give the sender an address which makes a tree of channels unbeknownst to them.
These channels are time insensitive for setup, as all punishments are relative timelocked to the
penultimate transaction node.
Thus, coins sent using a congestion controlled transaction can still enjoy instant liquidity.
====Non-Interactive Channels====
When opening a traditional payment channel, both parties to the channel must participate. This is
because the channel uses pre-signed multi-sig transactions to ensure that a channel can always be
exited by either party, before entering.
With CHECKTEMPLATEVERIFY, it’s possible for a single party to construct a channel which either
party can exit from without requiring signatures from both parties.
These payment channels can operate in one direction, paying to the channel "listener" without need
for their private key to be online.
<img src="bip-0119/nic.svg" align="middle"></img>
====Increased Channel Routes====
In the Lightning Network protocol, Hashed Time Locked Contracts (HTLCS) are used in the construction
of channels. A new HTLC is required per route that the channel is serving in.
In BOLT #2, this maximum number of HTLCs in a channel is hard limited to 483 as the maximum safe
size to prevent the transaction from being too large to be valid. In common software implementations
such as LND, this limit is set much lower to 12 HTLCS. This is because accepting a larger number of
HTLCS makes it more difficult for transactions to confirm during congested periods as they must pay
higher fees.
Therefore, similarly to how congestion control is handled for normal transaction, lightning channel
updates can be done across an CHECKTEMPLATEVERIFY tree, allowing nodes to safely use many more
HTLCS.
Because each HTLC can have its own relative time lock in the tree, this also improves the latency
sensitivity of the lightning protocol on contested channel close.
===Wallet Vaults===
This section will detail two variants of wallet vault that can be built using
CTV. Wallet vaults are a useful tool when greater security is required for
cold storage solutions, providing default transactional paths that move funds
from one's cold storage to a hot wallet.
One type of cold wallet can be set up such that a customer support desk can,
without further authorization, move a portion of the funds (using multiple
pre-set amounts) into a lukewarm wallet operated by an isolated support desk.
The support desk can then issue some funds to a hot wallet, and send the
remainder back to cold storage with a similar withdrawal mechanism in place.
This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY
eliminates the need for coordination and online signers, as well as reducing
the ability for a support desk to improperly move funds. Furthermore, all such
designs can be combined with relative time locks to give time for compliance
and risk desks to intervene. This is a 'Coins at Rest' or 'Optically Isolated'
vault, and is shown below.
<img src="bip-0119/vaults.svg" align="middle"></img>
An alternative design for vaults is also highly effective and simpler to
implement in Sapio, a smart contract programming language. In this design, the
user commits to a single UTXO that contains a program for an annuity of
withdrawals from cold storage to a hot wallet. At any time, the remaining
balance for the annuity can be cancelled and funds locked entirely in cold
storage. The withdrawals to the hot wallet can be 'cancelled' before a maturity
date to ensure the action was authorized. These sort of vaults strongly benefit
from non-interactivity because the withdrawal program can be set up with cold
keys that are permanently offline, except in case of emergency. The image below
shows an instance of this type of wallet vault created with Sapio in Sapio
Studio. These types of wallet vault can also be chained together by taking
advantage of CTV's scriptSig commitment. This type of vault is a 'Coins in Motion'
variant where the coins move along the control path.
<img src="bip-0119/vaultanim.gif" align="middle"></img>
===CoinJoin / Payment Pools / Join Pools ===
CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than
previously because participants agree on a single output which pays all
participants, which will be lower fee than before. Further each participant
doesn't need to know the totality of the outputs committed to by that output,
they only have to verify their own sub-tree will pay them. These trees can
then, using a top-level Schnorr key, be interactively updated on a rolling basis
forming a "Payment Pool".
==Detailed Specification==
@ -725,6 +624,14 @@ for older node versions that can be patched but not upgraded to a newer major re
*[https://fc16.ifca.ai/bitcoin/papers/MES16.pdf Bitcoin Covenants]
*[https://bitcointalk.org/index.php?topic=278122.0 CoinCovenants using SCIP signatures, an amusingly bad idea.]
*[https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf Enhancing Bitcoin Transactions with Covenants]
*[https://github.com/jamesob/simple-ctv-vault Simple CTV Vaults]
*[https://github.com/kanzure/python-vaults Python Vaults]
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html CTV Dramatically Improves DLCs]
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html Calculus of Covenants]
*[https://rubin.io/bitcoin/2021/12/10/advent-13/ Payment Pools with CTV]
*[https://rubin.io/bitcoin/2021/12/11/advent-14/ Channels with CTV]
*[https://rubin.io/bitcoin/2021/12/09/advent-12/ Congestion Control with CTV]
*[https://rubin.io/bitcoin/2021/12/07/advent-10/ Building Vaults on Bitcoin]
===Note on Similar Alternatives===