From 9329af381f02d5fcf38f4db6b185c73beae3c930 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vis=20Virial=20=28a=2Ek=2Ea=2E=20=E3=81=B3=E3=82=8A?= =?UTF-8?q?=E3=81=82=E3=82=8B=29?= Date: Thu, 20 Feb 2020 16:24:06 +0900 Subject: Fix "Using a single OP_CHECKSIGADD-based script" 1. CHECKSIG / CHECKSIGADD is confused Only the first OP-code for the first public key should be "CHECKSIG" and the following (second to n-th) OP-codes should be "CHECKSIGADD". It is confusing because it is only specified the first and last OP-codes, so I specified the second OP-code clearly. (I recommend to describe why only the first OP-code should be "CHECKSIG", not "CHECKSIGADD".) 2. Order of the signatures in witness In the original sentence, the stack status after the all witness elements are pushed will be | w_n | | : | | w_1 | and then, the first element of the script, "" will be pushed to the stack | pubkey_1 | | w_n | | : | | w_1 | so the "pubkey_1" and "w_n" won't match. The order of either "pubkey_i"s or "w_i"s should be inverted. --- bip-0342.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'bip-0342.mediawiki') diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki index 3da9904..c4af38a 100644 --- a/bip-0342.mediawiki +++ b/bip-0342.mediawiki @@ -76,7 +76,7 @@ The execution rules for tapscript are based on those for P2WSH according to BIP1 * '''OP_SUCCESSx opcodes''' As listed above, some opcodes are renamed to OP_SUCCESSx, and make the script unconditionally valid. * '''Signature opcodes'''. The OP_CHECKSIG and OP_CHECKSIGVERIFY are modified to operate on Schnorr public keys and signatures (see [[bip-0340.mediawiki|BIP340]]) instead of ECDSA, and a new opcode OP_CHECKSIGADD is added. ** The opcode 186 (0xba) is named as OP_CHECKSIGADD. '''OP_CHECKSIGADD''' This opcode is added to compensate for the loss of OP_CHECKMULTISIG-like opcodes, which are incompatible with batch verification. OP_CHECKSIGADD is functionally equivalent to OP_ROT OP_SWAP OP_CHECKSIG OP_ADD, but only takes 1 byte. All CScriptNum-related behaviours of OP_ADD are also applicable to OP_CHECKSIGADD.'''Alternatives to CHECKMULTISIG''' There are multiple ways of implementing a threshold ''k''-of-''n'' policy using Taproot and Tapscript: -* '''Using a single OP_CHECKSIGADD-based script''' A CHECKMULTISIG script m ... n CHECKMULTISIG with witness 0 ... can be rewritten as script CHECKSIG ... CHECKSIGADD m NUMEQUAL with witness ... . Every witness element w_i is either a signature corresponding to pubkey_i or an empty vector. A similar CHECKMULTISIGVERIFY script can be translated to BIP342 by replacing NUMEQUAL with NUMEQUALVERIFY. This approach has very similar characteristics to the existing OP_CHECKMULTISIG-based scripts. +* '''Using a single OP_CHECKSIGADD-based script''' A CHECKMULTISIG script m ... n CHECKMULTISIG with witness 0 ... can be rewritten as script CHECKSIG CHECKSIGADD ... CHECKSIGADD m NUMEQUAL with witness ... . Every witness element w_i is either a signature corresponding to pubkey_i or an empty vector. A similar CHECKMULTISIGVERIFY script can be translated to BIP342 by replacing NUMEQUAL with NUMEQUALVERIFY. This approach has very similar characteristics to the existing OP_CHECKMULTISIG-based scripts. * '''Using a ''k''-of-''k'' script for every combination''' A ''k''-of-''n'' policy can be implemented by splitting the script into several leaves of the Merkle tree, each implementing a ''k''-of-''k'' policy using CHECKSIGVERIFY ... CHECKSIGVERIFY CHECKSIG. This may be preferable for privacy reasons over the previous approach, as it only exposes the participating public keys, but it is only more cost effective for small values of ''k'' (1-of-''n'' for any ''n'', 2-of-''n'' for ''n ≥ 6'', 3-of-''n'' for ''n ≥ 9'', ...). Furthermore, the signatures here commit to the branch used, which means signers need to be aware of which other signers will be participating, or produce signatures for each of the tree leaves. * '''Using an aggregated public key for every combination''' Instead of building a tree where every leaf consists of ''k'' public keys, it is possible instead build a tree where every leaf contains a single ''aggregate'' of those ''k'' keys using [https://eprint.iacr.org/2018/068 MuSig]. This approach is far more efficient, but does require a 3-round interactive signing protocol to jointly produce the (single) signature. * '''Native Schnorr threshold signatures''' Multisig policies can also be realized with [http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps threshold signatures] using verifiable secret sharing. This results in outputs and inputs that are indistinguishable from single-key payments, but at the cost of needing an interactive protocol (and associated backup procedures) before determining the address to send to. -- cgit v1.2.3