From 420dc42f0e771b1ee131b4fff9c50530e140b463 Mon Sep 17 00:00:00 2001 From: Anthony Towns Date: Sun, 13 Jun 2021 09:18:06 +1000 Subject: BIP118: remove subliminal advertising of Simplicity --- bip-0118.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'bip-0118.mediawiki') diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki index bb66349..df3e42b 100644 --- a/bip-0118.mediawiki +++ b/bip-0118.mediawiki @@ -54,7 +54,7 @@ This proposal only supports ANYPREVOUT signatures via script path spends, and do This is for two reasons: first, not supporting key path spends allows this proposal to be independent of the core changes included in [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]]; second, it allows addresses to opt-in or opt-out of ANYPREVOUT support while remaining indistinguishable prior to being spent. (CHECKSIG, CHECKSIGVERIFY, and CHECKSIGADD) for public keys that have a length of 33 bytes and a first byte of 0x01 or the public key which is precisely the single byte vector 0x01'''Use of 0x01 public key type''' Because OP_0 leaves an empty vector on the stack it would not satisfy [[bip-0342.mediawiki|BIP 342]]'s rules for unknown public key types. As such, it is convenient to use one of OP_1..OP_16 or OP_1NEGATE as a way to reference the taproot internal key. -To keep things as simple as possible, we simply use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys. +To keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys. . These keys are termed '''BIP 118 public keys'''. @@ -67,9 +67,9 @@ The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by r ==== Public key ==== -To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply use the 32-byte taproot internal key, p, as defined in [[bip-0341.mediawiki|BIP 341]]. +To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, p, as defined in [[bip-0341.mediawiki|BIP 341]]. -To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply remove the 0x01 prefix and use the remaining 32 bytes. +To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the 0x01 prefix and use the remaining 32 bytes. ==== Signature message ==== @@ -161,7 +161,7 @@ Depending on the changes to the inputs, this might conflict with the original tr Further, for a chain of transactions using the same scriptPubKey and value, and only authenticated via ANYPREVOUT signatures (as envisioned in eltoo for failure cases), it may be possible for any third party to malleate the transactions (and their txids) without having access to any of the private keys, particularly by omitting intermediate transactions. -This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can simply be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid. +This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid. However child transactions that are authorised by a SIGHASH_ALL or SIGHASH_ANYONECANPAY signature will need new signatures if their inputs are malleated in this way. This risk may be mitigated somewhat by using [[bip-0068.mediawiki|BIP 68]]/[[bip-0112.mediawiki|BIP 112]] relative time locks before spending a UTXO that had been authorised via an ANYPREVOUT signature with SIGHASH_ALL or SIGHASH_ANYONECANPAY: a relative timelock can ensure that the inputs have enough confirmations that they can only be replaced in the event of a large block reorg. -- cgit v1.2.3