mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 21:35:13 +01:00
Code Issues Projects Releases Wiki Activity

Merge pull request #1320 from JeremyRubin/delete-motivations-119

Browse Source 
[BIP-119] Slim down motivation, add more references
This commit is contained in:
Luke Dashjr 2022-07-25 21:11:42 +00:00 committed by GitHub
commit d1b1ec476b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 30 additions and 123 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

153
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. Covenants have historically been widely
considered to be unfit for Bitcoin because they are too complex to implement
and risk reducing the fungibility of coins bound by them.
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
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==
@ -263,7 +162,7 @@ For the avoidance of unclarity, the parameters to be determined are:
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0;
Until BIP-119 reaches ACTIVE state and the
Until BIP-119 reaches ACTIVE state and the
SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to)
execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS (to deny entry to the mempool) for policy and must evaluate as
a NOP for consensus (during block validation).
@ -296,7 +195,7 @@ Below we'll discuss the rules one-by-one:
The set of data committed to is a superset of data which can impact the TXID of the transaction,
other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels
are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that
may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more
@ -442,7 +341,7 @@ programs.
RIPEMD160, a 20 byte hash, might also be a viable hash in some contexts and has some benefits. For fee efficiency,
RIPEMD160 saves 12 bytes. However, RIPEMD160 was not chosen for BIP-119 because it introduces
risks around the verification of programs created by third parties to be subject to a
risks around the verification of programs created by third parties to be subject to a
[birthday-attack https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh] on
transaction preimages.
@ -624,11 +523,11 @@ CHECKTEMPLATEVERIFY has benefits in terms of script size (depending on choice of
PK, SIGHASH_ANYPREVOUTANYSCRIPT may use about 2x-3x the bytes) and verification
speed, as OP_CHECKTEMPLATEVERIFY requires only hash computation rather than
signature operations. This can be significant when constructing large payment
trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise
trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise
benefit in that it provides a robust pathway for future template upgrades.
OP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate
CHECKTEMPLATEVERIFY. However such constructions are more complicated to use
CHECKTEMPLATEVERIFY. However such constructions are more complicated to use
than CHECKTEMPLATEVERIFY, and encumbers additional verification overhead absent
from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential
recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin.
@ -646,7 +545,7 @@ the future as well as synergies with other possible upgrades.
=====CHECKTEMPLATEVERIFY Versions=====
OP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments.
In the future, meaning could be ascribed to other length arguments. For
In the future, meaning could be ascribed to other length arguments. For
example, a 33-byte argument could just the last byte as a control program. In
that case, DefaultCheckTemplateVerifyHash could be computed when the flag byte
is set to CTVHASH_ALL. Other programs could be added similar to SIGHASH_TYPEs.
@ -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===