1
0
mirror of https://github.com/bitcoin/bips.git synced 2026-02-23 15:38:22 +00:00

Monthly typo fixups

Co-authored-by: xiaobei0715 <1505929057@qq.com>
Co-authored-by: wgyt <wgythe@gmail.com>
Co-authored-by: Ragnar <rodiondenmark@gmail.com>
This commit is contained in:
Jon Atack
2025-04-17 15:46:10 +08:00
parent b60b886414
commit 8137279570
16 changed files with 21 additions and 22 deletions

View File

@@ -370,7 +370,7 @@ OP_CHECKTEMPLATEVERIFY is not subject to this sort of vulnerability as the
hashes are effectively tagged externally, that is, by OP_CHECKTEMPLATEVERIFY
itself and therefore cannot be confused for another hash.
It would be a conservative design decisison to make it a tagged hash even if
It would be a conservative design decision to make it a tagged hash even if
there was no obvious benefit and no cost. However, in the future, if OP_CAT were
to be introduced to Bitcoin, it would make programs which dynamically build
OP_CHECKTEMPLATEVERIFY hashes less space-efficient. Therefore, bare untagged hashes
@@ -472,7 +472,7 @@ from the leaves of the CHECKTEMPLATEVERIFY tree.
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
For example, an exchange's hot wallet might use an address which can automatically be moved to a cold
storage address after a relative timeout.
The issue is that reusing addresses in this way can lead to loss of funds.