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

Merge pull request #1459 from ktecho/patch-1

Browse Source 
Typos in bip-0119
This commit is contained in:
kallewoof 2023-06-30 14:25:57 +09:00 committed by GitHub
commit 8b41d49d33
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
bip-0119.mediawiki
View File

@ -61,7 +61,7 @@ references.
==Detailed Specification== ==Detailed Specification==
The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described
in pythonic pseduocode. The canonical specification for the semantics of in pythonic pseudocode. The canonical specification for the semantics of
OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can
be seen in the reference implementation. be seen in the reference implementation.
@ -225,12 +225,12 @@ A recent commit hash in that PR including tests and vectors can be found here ht
Once the PR is merged, this BIP should be updated to point to the specific code released. Once the PR is merged, this BIP should be updated to point to the specific code released.
Test vectors are available in [/bip-0119/vectors the bip-0119/vectors Test vectors are available in [/bip-0119/vectors the bip-0119/vectors
directory] for checking compatibility with the refrence implementation and BIP. directory] for checking compatibility with the reference implementation and BIP.
==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:
@ -250,7 +250,7 @@ Were these values not committed, it would be possible to delay the spending of
an output arbitrarily as well as possible to change the TXID. an output arbitrarily as well as possible to change the TXID.
Committing these values, rather than restricting them to specific values, is Committing these values, rather than restricting them to specific values, is
more flexible as it permits users of CHECKTEMPLATEVERIFY the set the version and more flexible as it permits users of CHECKTEMPLATEVERIFY to set the version and
locktime as they please. locktime as they please.
=====Committing to the ScriptSigs Hash===== =====Committing to the ScriptSigs Hash=====
@ -258,7 +258,7 @@ locktime as they please.
The scriptsig in a segwit transaction must be exactly empty, unless it is a P2SH The scriptsig in a segwit transaction must be exactly empty, unless it is a P2SH
segwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible segwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible
(unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit (unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit
to the ScriptSig, which must contain the redeemscript, which is a hash cycle. to the ScriptSig, which must contain the redeemscript, which is a hash cycle.
To prevent malleability when not using a segwit input, we also commit to the To prevent malleability when not using a segwit input, we also commit to the
scriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed scriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed