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] Whitspace Consistency

Browse Source
This commit is contained in:
Jeremy Rubin 2021-10-16 09:00:48 -07:00
parent b305d56352
commit 6058f2f669
1 changed files with 13 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
bip-0119.mediawiki
View File

@ -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 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. structured in a tree-like fashion to reduce individual costs of redemption.
The below chart showcases the structure of these transactions in comparison to The below chart showcases the structure of these transactions in comparison to
normal transactions and batched transactions. 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> <img src="bip-0119/fifty.png" align="middle"></img>
===Payment Channels=== ===Payment Channels===
There are numerous payment channel related uses. There are numerous payment channel related uses.
====Channel Factories==== ====Channel Factories====
@ -84,6 +84,7 @@ penultimate transaction node.
Thus, coins sent using a congestion controlled transaction can still enjoy instant liquidity. Thus, coins sent using a congestion controlled transaction can still enjoy instant liquidity.
====Non-Interactive Channels==== ====Non-Interactive Channels====
When opening a traditional payment channel, both parties to the channel must participate. This is 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 because the channel uses pre-signed multi-sig transactions to ensure that a channel can always be
exited by either party, before entering. 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> <img src="bip-0119/nic.svg" align="middle"></img>
====Increased Channel Routes==== ====Increased Channel Routes====
In the Lightning Network protocol, Hashed Time Locked Contracts (HTLCS) are used in the construction 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. 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 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 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. sensitivity of the lightning protocol on contested channel close.
===Wallet Vaults=== ===Wallet Vaults===
When greater security is required for cold storage solutions, there can be 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. that output, they only have to verify their own sub-tree will pay them.
==Detailed Specification== ==Detailed Specification==
The below code is the main logic for verifying CHECKTEMPLATEVERIFY, and is the canonical The below code is the main logic for verifying CHECKTEMPLATEVERIFY, and is the canonical
specification for the semantics of OP_CHECKTEMPLATEVERIFY. specification for the semantics of OP_CHECKTEMPLATEVERIFY.
@ -203,7 +205,6 @@ The hash is computed as follows:
return h.GetSHA256(); return h.GetSHA256();
} }
A PayToBareDefaultCheckTemplateVerifyHash output matches the following template: A PayToBareDefaultCheckTemplateVerifyHash output matches the following template:
bool CScript::IsPayToBareDefaultCheckTemplateVerifyHash() const bool CScript::IsPayToBareDefaultCheckTemplateVerifyHash() const
@ -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 execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS for policy and a NOP for
consensus. consensus.
In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
PayToBareDefaultCheckTemplateVerifyHash PayToBareDefaultCheckTemplateVerifyHash
with no scriptSig data shall be made standard to permit relaying. Future template types may be 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: A reference implementation and tests are available here:
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify. https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify.
==Rationale== ==Rationale==
The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the 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. 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: 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 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, 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 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. as the redemption TXID could be malleated and pre-signed transactions invalidated.
=====Committing to the version and locktime===== =====Committing to the version and locktime=====
Were these values not committed, it would be possible to delay the spending of 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 Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
script. script.
=====Committing to the number of inputs===== =====Committing to the number of inputs=====
If we allow more than one input to be spent in the transaction then it would be 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), able to express a "don't care" index easily (e.g., for decentralized kickstarter-type transactions),
this value is placed last. this value is placed last.
===Design Tradeoffs and Risks=== ===Design Tradeoffs and Risks===
Covenants have historically been controversial given their potential for fungibility risks -- coins 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 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 Furthermore, templates are restricted to be spendable as a known number of inputs only, preventing
unintentional introduction of the 'half spend' problem. unintentional introduction of the 'half spend' problem.
Templates, as restricted as they are, bear some risks. Templates, as restricted as they are, bear some risks.
====Permanently Unspendable Outputs==== ====Permanently Unspendable Outputs====
The preimage argument passed to CHECKTEMPLATEVERIFY may be unknown or otherwise unsatisfiable. 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 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 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. from the leafs of the CHECKTEMPLATEVERIFY tree.
====Forwarding Addresses==== ====Forwarding Addresses====
Key-reuse with CHECKTEMPLATEVERIFY may be used as a form of "forwarding address contract". 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. 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 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 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. guaranteed to execute in separate transactions which reduces the risk of "half-spend" type issues.
====NOP-Default and Standardness Rules==== ====NOP-Default and Standardness Rules====
If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP. 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 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. consensus-valid transaction may be caused, leading to a potential loss of funds.
====Feature Redundancy==== ====Feature Redundancy====
CHECKTEMPLATEVERIFY templates are substantially less risky than other covenant systems. If CHECKTEMPLATEVERIFY templates are substantially less risky than other covenant systems. If
implemented, other covenant systems could make the CHECKTEMPLATEVERIFY's functionality redundant. 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 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 Alternatively, SIGHASH_ANYPREVOUTANYSCRIPT based covenant designs can implement
something similar to templates, via a scriptPubKey like: 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 <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 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 from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential
recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin. 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 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 applications, CHECKTEMPLATEVERIFY's template based approach is proposed in lieu of more complete
covenants system. 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. the future as well as synergies with other possible upgrades.
=====CHECKTEMPLATEVERIFY Versions===== =====CHECKTEMPLATEVERIFY Versions=====
OP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments. 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 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 OP_SIZE 4 OP_EQUALVERIF
<nVersion || nLockTime || input count || sequences hash || output count || outputs hash> <nVersion || nLockTime || input count || sequences hash || output count || outputs hash>
OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY
== Backwards Compatibility == == Backwards Compatibility ==
OP_CHECKTEMPLATEVERIFY replaces a OP_NOP4 with stricter verification semantics. Therefore, scripts 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 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). being "trusted" (i.e., eligible for spending before the transaction is confirmed).
Backports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation) 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. for older node versions that can be patched but not upgraded to a newer major release.
== References == == References ==
*[https://utxos.org utxos.org informational site] *[https://utxos.org utxos.org informational site]
*[https://www.youtube.com/watch?v=YxsjdIl0034&t=2451 Scaling Bitcoin Presentation] *[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] *[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=== ===Note on Similar Alternatives===
An earlier version of CHECKTEMPLATEVERIFY, CHECKOUTPUTSHASHVERIFY, is withdrawn An earlier version of CHECKTEMPLATEVERIFY, CHECKOUTPUTSHASHVERIFY, is withdrawn
in favor of CHECKTEMPLATEVERIFY. CHECKOUTPUTSHASHVERIFY did not commit to the in favor of CHECKTEMPLATEVERIFY. CHECKOUTPUTSHASHVERIFY did not commit to the
version or lock time and was thus insecure. 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. to aid in searching and referencing discussion on this BIP.
==Copyright== ==Copyright==
This document is licensed under the 3-clause BSD license. This document is licensed under the 3-clause BSD license.