mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
[BIP-119] Whitspace Consistency
This commit is contained in:
Jeremy Rubin
parent
b305d56352
commit
6058f2f669
@ -57,7 +57,6 @@ for purposes of confirmation using CHECKTEMPLATEVERIFY. Then, some time later, t
|
||||
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.
|
||||
|
||||
@ -71,6 +70,7 @@ is provided in this BIP's subdirectory.
|
||||
<img src="bip-0119/fifty.png" align="middle"></img>
|
||||
|
||||
===Payment Channels===
|
||||
|
||||
There are numerous payment channel related uses.
|
||||
|
||||
====Channel Factories====
|
||||
@ -84,6 +84,7 @@ 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.
|
||||
@ -94,6 +95,7 @@ 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
|
||||
@ -107,7 +109,6 @@ 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===
|
||||
|
||||
When greater security is required for cold storage solutions, there can be
|
||||
@ -133,6 +134,7 @@ before. Further Each participant doesn't need to know the totality of the outpu
|
||||
that output, they only have to verify their own sub-tree will pay them.
|
||||
|
||||
==Detailed Specification==
|
||||
|
||||
The below code is the main logic for verifying CHECKTEMPLATEVERIFY, and is the canonical
|
||||
specification for the semantics of OP_CHECKTEMPLATEVERIFY.
|
||||
|
||||
@ -203,7 +205,6 @@ The hash is computed as follows:
|
||||
return h.GetSHA256();
|
||||
}
|
||||
|
||||
|
||||
A PayToBareDefaultCheckTemplateVerifyHash output matches the following template:
|
||||
|
||||
bool CScript::IsPayToBareDefaultCheckTemplateVerifyHash() const
|
||||
@ -223,7 +224,7 @@ NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft.
|
||||
|
||||
For the avoidance of unclarity, the parameters to be determined are:
|
||||
|
||||
// Deployment of CTV (BIP 119)
|
||||
// Deployment of CTV (BIP 119)
|
||||
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].bit = 5;
|
||||
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nStartTime = Consensus::BIP9Deployment::NEVER_ACTIVE;
|
||||
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
|
||||
@ -234,7 +235,6 @@ SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is set, the network should
|
||||
execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS for policy and a NOP for
|
||||
consensus.
|
||||
|
||||
|
||||
In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
|
||||
PayToBareDefaultCheckTemplateVerifyHash
|
||||
with no scriptSig data shall be made standard to permit relaying. Future template types may be
|
||||
@ -245,17 +245,13 @@ standardized later as policy changes.
|
||||
A reference implementation and tests are available here:
|
||||
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify.
|
||||
|
||||
|
||||
==Rationale==
|
||||
|
||||
The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the
|
||||
future, as we become aware of more complex but shown to be safe use cases new template types can be added.
|
||||
|
||||
|
||||
Below we'll discuss the rules one-by-one:
|
||||
|
||||
|
||||
|
||||
====The DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stack====
|
||||
|
||||
The set of data committed to is a superset of data which can impact the TXID of the transaction,
|
||||
@ -263,8 +259,6 @@ other than the inputs. This ensures that for a given known input, the TXIDs can
|
||||
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Channel Factory type constructions
|
||||
as the redemption TXID could be malleated and pre-signed transactions invalidated.
|
||||
|
||||
|
||||
|
||||
=====Committing to the version and locktime=====
|
||||
|
||||
Were these values not committed, it would be possible to delay the spending of
|
||||
@ -296,7 +290,6 @@ precomputed for each transaction to optimize SIGHASH_ALL signatures.
|
||||
Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
|
||||
script.
|
||||
|
||||
|
||||
=====Committing to the number of inputs=====
|
||||
|
||||
If we allow more than one input to be spent in the transaction then it would be
|
||||
@ -459,7 +452,6 @@ does not make sense for input index to be the last field. However, given the des
|
||||
able to express a "don't care" index easily (e.g., for decentralized kickstarter-type transactions),
|
||||
this value is placed last.
|
||||
|
||||
|
||||
===Design Tradeoffs and Risks===
|
||||
Covenants have historically been controversial given their potential for fungibility risks -- coins
|
||||
could be minted which have a permanent restriction on how they may or may not be spent or required
|
||||
@ -474,10 +466,10 @@ transactions which create all the inputs directly in this regard.
|
||||
Furthermore, templates are restricted to be spendable as a known number of inputs only, preventing
|
||||
unintentional introduction of the 'half spend' problem.
|
||||
|
||||
|
||||
Templates, as restricted as they are, bear some risks.
|
||||
|
||||
====Permanently Unspendable Outputs====
|
||||
|
||||
The preimage argument passed to CHECKTEMPLATEVERIFY may be unknown or otherwise unsatisfiable.
|
||||
However, requiring knowledge that an address is spendable from is incompatible with sender's ability
|
||||
to spend to any address (especially, OP_RETURN). If a sender needs to know the template can be spent
|
||||
@ -485,6 +477,7 @@ from before sending, they may request a signature of an provably non-transaction
|
||||
from the leafs of the CHECKTEMPLATEVERIFY tree.
|
||||
|
||||
====Forwarding Addresses====
|
||||
|
||||
Key-reuse with CHECKTEMPLATEVERIFY may be used as a form of "forwarding address contract".
|
||||
A forwarding address is an address which can automatically execute in a predefined way.
|
||||
For example, a exchange's hot wallet might use an address which can automatically be moved to a cold
|
||||
@ -510,7 +503,6 @@ reuse-unsafe.
|
||||
Because CHECKTEMPLATEVERIFY commits to the input index currently being spent, reused-keys are
|
||||
guaranteed to execute in separate transactions which reduces the risk of "half-spend" type issues.
|
||||
|
||||
|
||||
====NOP-Default and Standardness Rules====
|
||||
|
||||
If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP.
|
||||
@ -523,8 +515,8 @@ stricter standardness rules to be enforced during consensus. Should that develop
|
||||
transaction directly to the network relying on standardness rejection, an standardness-invalid but
|
||||
consensus-valid transaction may be caused, leading to a potential loss of funds.
|
||||
|
||||
|
||||
====Feature Redundancy====
|
||||
|
||||
CHECKTEMPLATEVERIFY templates are substantially less risky than other covenant systems. If
|
||||
implemented, other covenant systems could make the CHECKTEMPLATEVERIFY's functionality redundant.
|
||||
However, given CHECKTEMPLATEVERIFY's simple semantics and low on chain cost it's likely that it
|
||||
@ -538,7 +530,6 @@ unintended behavior.
|
||||
Alternatively, SIGHASH_ANYPREVOUTANYSCRIPT based covenant designs can implement
|
||||
something similar to templates, via a scriptPubKey like:
|
||||
|
||||
|
||||
<sig of desired TX with PK and fixed nonce R || SIGHASH_ANYPREVOUTANYSCRIPT <PK with public SK> OP_CHECKSIG
|
||||
|
||||
SIGHASH_ANYPREVOUTANYSCRIPT bears additional technical and implementation risks
|
||||
@ -564,7 +555,6 @@ 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.
|
||||
|
||||
|
||||
Given the simplicity of this approach to implement and analyze, and the benefits realizable by user
|
||||
applications, CHECKTEMPLATEVERIFY's template based approach is proposed in lieu of more complete
|
||||
covenants system.
|
||||
@ -575,6 +565,7 @@ This section describes updates to OP_CHECKTEMPLATEVERIFY that are possible in
|
||||
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
|
||||
example, a 33-byte argument could just the last byte as a control program. In
|
||||
@ -623,6 +614,7 @@ concatenates it to the template and checks the template matches the transaction.
|
||||
OP_SIZE 4 OP_EQUALVERIF
|
||||
<nVersion || nLockTime || input count || sequences hash || output count || outputs hash>
|
||||
OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY
|
||||
|
||||
== Backwards Compatibility ==
|
||||
|
||||
OP_CHECKTEMPLATEVERIFY replaces a OP_NOP4 with stricter verification semantics. Therefore, scripts
|
||||
@ -638,13 +630,11 @@ Older wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY
|
||||
require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as
|
||||
being "trusted" (i.e., eligible for spending before the transaction is confirmed).
|
||||
|
||||
|
||||
|
||||
Backports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation)
|
||||
for older node versions that can be patched but not upgraded to a newer major release.
|
||||
|
||||
|
||||
== References ==
|
||||
|
||||
*[https://utxos.org utxos.org informational site]
|
||||
*[https://www.youtube.com/watch?v=YxsjdIl0034&t=2451 Scaling Bitcoin Presentation]
|
||||
*[https://bitcoinops.org/en/newsletters/2019/05/29/ Optech Newsletter Covering OP_CHECKOUTPUTSHASHVERIFY]
|
||||
@ -656,6 +646,7 @@ for older node versions that can be patched but not upgraded to a newer major re
|
||||
|
||||
|
||||
===Note on Similar Alternatives===
|
||||
|
||||
An earlier version of CHECKTEMPLATEVERIFY, CHECKOUTPUTSHASHVERIFY, is withdrawn
|
||||
in favor of CHECKTEMPLATEVERIFY. CHECKOUTPUTSHASHVERIFY did not commit to the
|
||||
version or lock time and was thus insecure.
|
||||
@ -668,4 +659,5 @@ CHECKTEMPLATEVERIFY has also been previously referred to as OP_SECURETHEBAG, whi
|
||||
to aid in searching and referencing discussion on this BIP.
|
||||
|
||||
==Copyright==
|
||||
|
||||
This document is licensed under the 3-clause BSD license.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user