diff options
107 files changed, 2574 insertions, 454 deletions
diff --git a/README.mediawiki b/README.mediawiki index 5c993a6..170b053 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -251,6 +251,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard | Proposed +|- +| [[bip-0046.mediawiki|46]] +| Applications +| Address Scheme for Timelocked Fidelity Bonds +| Chris Belcher, Thebora Kompanioni +| Standard +| Draft |- style="background-color: #cfffcf" | [[bip-0047.mediawiki|47]] | Applications @@ -448,13 +455,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Ethan Kosakovsky | Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0086.mediawiki|86]] | Applications | Key Derivation for Single Key P2TR Outputs | Ava Chow | Standard -| Draft +| Final |- style="background-color: #ffffcf" | [[bip-0087.mediawiki|87]] | Applications @@ -700,13 +707,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak | Standard | Proposed -|- style="background-color: #ffffcf" +|- style="background-color: #cfffcf" | [[bip-0130.mediawiki|130]] | Peer Services | sendheaders message | Suhas Daftuar | Standard -| Proposed +| Final |- style="background-color: #ffcfcf" | [[bip-0131.mediawiki|131]] | Consensus (hard fork) @@ -832,7 +839,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Peer Authentication | Jonas Schnelli | Standard -| Draft +| Deferred |- style="background-color: #ffcfcf" | [[bip-0151.mediawiki|151]] | Peer Services @@ -882,13 +889,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Olaoluwa Osuntokun, Alex Akselrod | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0159.mediawiki|159]] | Peer Services | NODE_NETWORK_LIMITED service bit | Jonas Schnelli | Standard -| Draft +| Final |- style="background-color: #ffcfcf" | [[bip-0171.mediawiki|171]] | Applications @@ -994,13 +1001,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Karl-Johan Alm | Standard | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0324.mediawiki|324]] | Peer Services | Version 2 P2P Encrypted Transport Protocol | Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille | Standard -| Draft +| Final |- style="background-color: #ffffcf" | [[bip-0325.mediawiki|325]] | Applications @@ -1023,6 +1030,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Informational | Draft |- +| [[bip-0328.mediawiki|328]] +| Applications +| Derivation Scheme for MuSig2 Aggregate Keys +| Ava Chow +| Informational +| Draft +|- | [[bip-0329.mediawiki|329]] | Applications | Wallet Labels Export Format @@ -1044,19 +1058,26 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0337.mediawiki|337]] +| API/RPC +| Compressed Transactions +| Tom Briar +| Standard +| Draft +|- style="background-color: #ffcfcf" | [[bip-0338.mediawiki|338]] | Peer Services | Disable transaction relay message | Suhas Daftuar | Standard -| Draft -|- +| Withdrawn +|- style="background-color: #cfffcf" | [[bip-0339.mediawiki|339]] | Peer Services | WTXID-based transaction relay | Suhas Daftuar | Standard -| Draft +| Final |- style="background-color: #cfffcf" | [[bip-0340.mediawiki|340]] | @@ -1121,19 +1142,26 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Proposed |- +| [[bip-0353.mediawiki|353]] +| Applications +| DNS Payment Instructions +| Matt Corallo, Bastien Teinturier +| Standard +| Draft +|- style="background-color: #cfffcf" | [[bip-0370.mediawiki|370]] | Applications | PSBT Version 2 | Ava Chow | Standard -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0371.mediawiki|371]] | Applications | Taproot Fields for PSBT | Ava Chow | Standard -| Draft +| Final |- | [[bip-0372.mediawiki|372]] | Applications @@ -1142,61 +1170,75 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0373.mediawiki|373]] +| Applications +| MuSig2 PSBT Fields +| Ava Chow +| Standard +| Draft +|- +| [[bip-0379.md|379]] +| Applications +| Miniscript +| Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Antoine Poinsot, Ava Chow +| Informational +| Draft +|- style="background-color: #cfffcf" | [[bip-0380.mediawiki|380]] | Applications | Output Script Descriptors General Operation | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0381.mediawiki|381]] | Applications | Non-Segwit Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0382.mediawiki|382]] | Applications | Segwit Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0383.mediawiki|383]] | Applications | Multisig Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0384.mediawiki|384]] | Applications | combo() Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0385.mediawiki|385]] | Applications | raw() and addr() Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0386.mediawiki|386]] | Applications | tr() Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft -|- +| Final +|- style="background-color: #cfffcf" | [[bip-0387.mediawiki|387]] | Applications | Tapscript Multisig Output Script Descriptors | Pieter Wuille, Ava Chow | Informational -| Draft +| Final |- style="background-color: #ffffcf" | [[bip-0388.mediawiki|388]] | Applications @@ -1211,6 +1253,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Ava Chow | Informational | Draft +|- +| [[bip-0390.mediawiki|390]] +| Applications +| musig() Descriptor Key Expression +| Ava Chow +| Informational +| Draft +|- +| [[bip-0431.mediawiki|431]] +| Applications +| Topology Restrictions for Pinning +| Gloria Zhao +| Informational +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index f7fbad1..1883562 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -119,7 +119,7 @@ other one simultaneously transitions to STARTED, which would mean both would dem Note that a block's state never depends on its own nVersion; only on that of its ancestors. - case STARTED: + case STARTED: if (GetMedianTimePast(block.parent) >= timeout) { return FAILED; } diff --git a/bip-0015.mediawiki b/bip-0015.mediawiki index 52a698f..635fb7f 100644 --- a/bip-0015.mediawiki +++ b/bip-0015.mediawiki @@ -36,7 +36,7 @@ Their FirstBits alias becomes: It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments. -Together with [[vanitygen|Vanitygen (vanity generator)]], it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination. +Together with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination. However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing. @@ -208,7 +208,7 @@ NameResolutionService::~NameResolutionService() void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain) { - // split address at @ furthrest to the right + // split address at @ furthest to the right size_t nPosAtsym = strHandle.rfind('@'); strNickname = strHandle.substr(0, nPosAtsym); strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size()); diff --git a/bip-0017.mediawiki b/bip-0017.mediawiki index 671f75a..aeb8764 100644 --- a/bip-0017.mediawiki +++ b/bip-0017.mediawiki @@ -86,7 +86,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca * A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners. -To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. +To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time. To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create. diff --git a/bip-0038.mediawiki b/bip-0038.mediawiki index ab1a158..6bcf411 100644 --- a/bip-0038.mediawiki +++ b/bip-0038.mediawiki @@ -64,7 +64,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are * How the user sees it: 58 characters always starting with '6P' ** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag. * Count of payload bytes (beyond prefix): 37 -** 1 byte (''flagbyte''): +** 1 byte (''flagbyte''): *** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00. *** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format. *** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification. @@ -75,10 +75,10 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are **16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used) * Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR): ** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's) -** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's) +** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's) * Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY): ** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's) -** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's) +** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's) * Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf): ** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's) ** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's) @@ -272,7 +272,7 @@ Test 2: Test 1: *Passphrase: MOLON LABE -*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX +*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX *Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j *Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh *Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8 @@ -280,9 +280,9 @@ Test 1: *Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD *Lot/Sequence: 263183/1 -Test 2: +Test 2: *Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ -*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK +*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK *Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH *Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf *Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 5acf87d..7cf8fcb 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -28,7 +28,7 @@ for two smaller words (This would be a problem with any of the 3 character sets ### Spanish -1. Words can be uniquely determined typing the first 4 characters (sometimes less). +1. Words can be uniquely determined by typing the first 4 characters (sometimes less). 2. Special Spanish characters like 'ñ', 'ü', 'á', etc... are considered equal to 'n', 'u', 'a', etc... in terms of identifying a word. Therefore, there is no need to use a Spanish keyboard to introduce the passphrase, an application with the Spanish wordlist will be able to identify the words after the first 4 chars have been typed even if the chars with accents have been replaced with the equivalent without accents. @@ -92,7 +92,7 @@ Credits: @zizelevak (Jan Lansky zizelevak@gmail.com) Words chosen using the following rules: 1. Words are 4-8 letters long. -2. Words can be uniquely determined typing the first 4 letters. +2. Words can be uniquely determined by typing the first 4 letters. 3. Only words containing all letters without diacritical marks. (It was the hardest task, because one third of all Czech letters has diacritical marks.) 4. Only nouns, verbs and adverbs, no other word types. All words are in basic form. 5. No personal names or geographical names. @@ -104,7 +104,7 @@ Words chosen using the following rules: Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus -1. Words can be uniquely determined typing the first 4 characters. +1. Words can be uniquely determined by typing the first 4 characters. 2. No accents or special characters. 3. No complex verb forms. 4. No plural words, unless there's no singular form. diff --git a/bip-0042.mediawiki b/bip-0042.mediawiki index 2c5de6d..c233e26 100644 --- a/bip-0042.mediawiki +++ b/bip-0042.mediawiki @@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak ===Floating-point approximation=== -An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. +An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript. ===Truncation=== diff --git a/bip-0046.mediawiki b/bip-0046.mediawiki new file mode 100644 index 0000000..1602f81 --- /dev/null +++ b/bip-0046.mediawiki @@ -0,0 +1,193 @@ +<pre> + BIP: 46 + Layer: Applications + Title: Address Scheme for Timelocked Fidelity Bonds + Author: Chris Belcher <belcher@riseup.net> + Thebora Kompanioni <theborakompanioni+bip46@gmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0046 + Status: Draft + Type: Standards Track + Created: 2022-04-01 + License: CC0-1.0 + Post-History: 2022-05-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html +</pre> + +== Abstract == + +This BIP defines the derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds. It also gives advice to wallet developers on how to use fidelity bonds to sign over messages, such as certificates, which are needed when using fidelity bonds that are stored offline. + +== Copyright == + +This document is licensed under the Creative Commons CC0 1.0 Universal license. + +== Motivation == + +Fidelity bonds are used to resist sybil attacks in certain decentralized anonymous protocols. They are created by locking up bitcoins using the `OP_CHECKLOCKTIMEVERIFY` opcode. + +Having a common derivation scheme allows users of wallet software to have a backup of their fidelity bonds by storing only the HD seed and a reference to this BIP. Importantly the user does not need to backup any timelock values. + +We largely use the same approach used in BIPs 49, 84 and 86 for ease of implementation. + +This allows keeping the private keys of fidelity bonds in cold storage, which increases the sybil resistance of a system without hot wallet risk. + +== Backwards Compatibility == + +This BIP is not backwards compatible by design as described in the Considerations section of [[bip-0049.mediawiki|BIP 49]]. An incompatible wallet will not discover fidelity bonds at all and the user will notice that something is wrong. + +== Background == + +=== Fidelity bonds === + +A fidelity bond is a mechanism where bitcoin value is deliberately sacrificed to make a cryptographic identity expensive to obtain. A way to create a fidelity bond is to lock up bitcoins by sending them to a timelocked address. The valuable thing being sacrificed is the time-value-of-money. + +The sacrifice must be done in a way that can be proven to a third party. This proof can be made by showing the UTXO outpoint, the address redeemscript and a signature which signs a message using the private key corresponding to the public key in the redeemscript. + +The sacrificed value is an objective measurement that can't be faked and which can be verified by anybody (just like, for example PoW mining). Sybil attacks can be made very expensive by forcing a hypothetical sybil attacker to lock up many bitcoins for a long time. JoinMarket implements fidelity bonds for protection from sybil attackers. At the time of writing over 600 BTC in total have been locked up with some for many years. Their UTXOs and signatures have been advertised to the world as proof. We can calculate that for a sybil attacker to succeed in unmixing all the CoinJoins, they would have to lock up over 100k BTC for several years. + +=== Fidelity bonds in cold storage === + +To allow for holding fidelity bonds in cold storage, there is an intermediate keypair called the certificate. + + UTXO key ---signs---> certificate ---signs---> endpoint + +Where the endpoint might be a IRC nickname or Tor onion hostname. The certificate keypair can be kept online and used to prove ownership of the fidelity bond. Even if the hot wallet private keys are stolen, the coins in the timelocked address will still be safe, although the thief will be able to impersonate the fidelity bond until the expiry. + +== Rationale == + +It is useful for the user to avoid having to keep a record of the timelocks in the time-locked addresses. So only a limited small set of timelocks are defined by this BIP. This way the user must only store their seed phrase, and knowledge that they have coins stored using this BIP standard. The user doesn't need to remember or store any dates. + +This standard is already implemented and deployed in JoinMarket. As most changes would require a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all. + +== Specifications == + +This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate that can be signed by the deterministic address key. + +=== Public key derivation === + +To derive a public key from the root account, this BIP uses a similar account-structure as defined in BIP [[bip-0084.mediawiki|44]] but with <tt>change</tt> set to <tt>2</tt>. + +<pre> +m / 84' / 0' / 0' / 2 / index +</pre> + +A key derived with this derivation path pattern will be referred to as <tt>derived_key</tt> further +in this document. + +For <tt>index</tt>, addresses are numbered from 0 in a sequentially increasing manner with a fixed upper bound: The index only goes up to <tt>959</tt> inclusive. Only 960 addresses can be derived for a given BIP32 master key. Furthermore there is no concept of a gap limit, instead wallets must always generate all 960 addresses and check for all of them if they have a balance and history. + +=== Timelock derivation === + +The timelock used in the time-locked address is derived from the <tt>index</tt>. The timelock is a unix time. It is always at the start of the first second at the beginning of the month (see [[#Test vectors|Test vectors]]). The <tt>index</tt> counts upwards the months from January 2020, ending in December 2099. At 12 months per year for 80 years this totals 960 timelocks. Note that care must be taken with the year 2038 problem on 32-bit systems. + +<pre> +year = 2020 + index // 12 +month = 1 + index % 12 +</pre> + + +=== Address derivation === + +To derive the address from the above calculated public key and timelock, we create a <tt>witness script</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>witness script</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>witness program</tt> in the output script of the P2WSH address. + + witnessScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <derived_key> OP_CHECKSIG + witness: <signature> <witnessScript> + scriptSig: (empty) + scriptPubKey: 0 <32-byte-hash> + (0x0020{32-byte-hash}) + +=== Message signing === + +In order to support signing of certificates, implementors should support signing ASCII messages. + +The certificate message is defined as `"fidelity-bond-cert" || "|" || cert_pubkey || "|" || cert_expiry`. + +The certificate expiry `cert_expiry` is the number of the 2016-block period after which the certificate is no longer valid. For example, if `cert_expiry` is 330 then the certificate will become invalid after block height 665280 (:=330x2016). The purpose of the expiry parameter is so that in case the certificate keypair is compromised, the attacker can only impersonate the fidelity bond for a limited amount of time. + +A certificate message can be created by another application external to this standard. It is then prepended with the string `0x18 || "Bitcoin Signed Message:\n"` and a byte denoting the length of the certificate message. The whole thing is then signed with the private key of the <tt>derived_key</tt>. This part is identical to the "Sign Message" function which many wallets already implement. + +Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ASCII string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages. + +It is most important for wallet implementions of this standard to support creating the certificate signature. Verifying the certificate signature is less important. + + +== Test vectors == + +<pre> +mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about +rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu +rootpub = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8 + +// First timelocked address = m/84'/0'/0'/2/0 +derived private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d +derived public_key = 02a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011 +unix locktime = 1577836800 +string locktime = 2020-01-01 00:00:00 +redeemscript = 0400e10b5eb1752102a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011ac +scriptPubKey = 0020bdee9515359fc9df912318523b4cd22f1c0b5410232dc943be73f9f4f07e39ad +address = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84 + +// Test certificate using the first timelocked address +// Note that as signatures contains a random nonce, it might not be exactly the same when your code generates it +// p2pkh address is the p2pkh address corresponding to the derived public key, it can be used to verify the message +// signature in any wallet that supports Verify Message. +// As mentioned before, it is more important for implementors of this standard to support signing such messages, not verifying them +message = fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375 +address = bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84 +p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6 +signature = H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo= + +// 2nd timelocked address = m/84'/0'/0'/2/1 +derived private_key = KxctaFBzetyc9KXeUr6jxESCZiCEXRuwnQMw7h7hroP6MqnWN6Pf +derived public_key = 02599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002d +unix locktime = 1580515200 +string locktime = 2020-02-01 00:00:00 +redeemscript = 0480bf345eb1752102599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002dac +scriptPubKey = 0020b8f898643991608524ed04e0c6779f632a57f1ffa3a3a306cd81432c5533e9ae +address = bc1qhrufsepej9sg2f8dqnsvvaulvv490u0l5w36xpkds9pjc4fnaxhq7pcm4h + +// timelocked address after the year 2038 = m/84'/0'/0'/2/240 +derived private_key = L3SYqae23ZoDDcyEA8rRBK83h1MDqxaDG57imMc9FUx1J8o9anQe +derived public_key = 03ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226 +unix locktime = 2208988800 +string locktime = 2040-01-01 00:00:00 +redeemscript = 05807eaa8300b1752103ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226ac +scriptPubKey = 0020e7de0ad2720ae1d6cc9b6ad91af57eb74646762cf594c91c18f6d5e7a873635a +address = bc1qul0q45njptsadnymdtv34at7karyva3v7k2vj8qc7m2702rnvddq0z20u5 + +// last timelocked address = m/84'/0'/0'/2/959 +derived private_key = L5Z9DDMnj5RZMyyPiQLCvN48Xt7GGmev6cjvJXD8uz5EqiY8trNJ +derived public_key = 0308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3 +unix locktime = 4099766400 +string locktime = 2099-12-01 00:00:00 +redeemscript = 0580785df400b175210308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3ac +scriptPubKey = 0020803268e042008737cf439748cbb5a4449e311da9aa64ae3ac56d84d059654f85 +address = bc1qsqex3czzqzrn0n6rjayvhddygj0rz8df4fj2uwk9dkzdqkt9f7zs5c493u + +// Test certificate and endpoint signing using the first timelocked address = m/84'/0'/0'/2/0 (see above) +bond private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d +bond p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6 + +certificate private_key = KyZpNDKnfs94vbrwhJneDi77V6jF64PWPF8x5cdJb8ifgg2DUc9d +certificate public_key = 0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c +certificate p2pkh address = 1JaUQDVNRdhfNsVncGkXedaPSM5Gc54Hso + +certificate message = fidelity-bond-cert|0330d54fd0dd420a6e5f8d3624f5f3482cae350f79d5f0753bf5beef9c2d91af3c|375 +certificate signature = INOP3cB9UW7F1e1Aglj8rI9QhnyxmgWDEPt+nOMvl7hJJne7rH/KCNDYvLiqNuB9qWaWUojutjRsgPJrvyDQ+0Y= + +// example endpoint signing two IRC nicknames (used in JoinMarket) +endpoint message = J54LS6YyJPoseqFS|J55VZ6U6ZyFDNeuv +endpoint signature = H18WE4MugDNoWZIf9jU0njhQptdUyBDUf7lToG9bpMKmeJK0lOoABaDs5bKnohSuZ0e9gnSco5OL9lXdKU7gP5E= +</pre> + +Code generating these test vectors can be found here: https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors + +== Reference == + +* [[https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/|Design for improving JoinMarket's resistance to sybil attacks using fidelity bonds]] +* [[https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/fidelity-bonds.md|JoinMarket fidelity bonds doc page]] +* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]] +* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] +* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]] +* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]] +* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]] +* [[bip-0086.mediawiki|BIP86 - Key Derivation for Single Key P2TR Outputs]] diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index dc1f588..c44bea9 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -17,7 +17,7 @@ RECENT CHANGES: ==Status== -This BIP can be be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process. +This BIP can be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process. The Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc @@ -275,7 +275,7 @@ Normal operation of a payment code-enabled wallet can be performed by an SPV cli Recovering a wallet from a seed, however, does require access to a fully-indexed blockchain. -The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable blockchain explorer. +The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queryable blockchain explorer. When querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other. @@ -350,12 +350,12 @@ Version 2 payment codes behave identifically to version 1 payment codes, except ====Definitions==== -* Notification change output: the change output from a notification transaction which which resides in the sender's wallet, but can be automatically located by the intended recipient +* Notification change output: the change output from a notification transaction which resides in the sender's wallet, but can be automatically located by the intended recipient * Payment code identifier: a 33 byte representation of a payment code constructed by prepending 0x02 to the SHA256 hash of the binary serialization of the payment code ====Notification Transaction==== -Note: this procedure is used if Bob uses a version 2 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification. +Note: this procedure is used if Bob uses a version 2 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification. # Construct a notification transaction as per the version 1 instructions, except do not create the output to Bob's notification address # Create a notification change address as follows: diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index a13b437..3e37a01 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -92,10 +92,10 @@ This BIP is not backwards compatible by design as described under [[#considerati // Account 0, first receiving private key = m/49'/1'/0'/0/0 account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8 - account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f + account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f // Address derivation - keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3 + keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3 scriptSig = <0 <keyhash>> = 0x001438971f73930f6c141d977ac4fd4a727c854935b3 addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742 diff --git a/bip-0052.mediawiki b/bip-0052.mediawiki index ea60f13..aa42ab3 100644 --- a/bip-0052.mediawiki +++ b/bip-0052.mediawiki @@ -25,7 +25,7 @@ Bitcoin network cannot profitably mine Bitcoin even if they have the capital to invest in mining hardware. From a practical perspective, Bitcoin adoption by companies like Tesla (which recently rescinded its acceptance of Bitcoin as payment) has been hampered by its massive energy consumption and perceived -environmental impact. +environmental impact. <img src="bip-0052/btc_energy-small.png"></img> @@ -137,7 +137,7 @@ x1 <- keccak(input) x2 <- reshape(x1, 64) // Perform a matrix-vector multiplication. -// The result is 64-vector of 14-bit unsigned. +// The result is 64-vector of 14-bit unsigned. x3 <- vector_matrix_mult(x2, M) // Truncate all values to 4 most significant bits. diff --git a/bip-0064.mediawiki b/bip-0064.mediawiki index 82a6cfd..02c4c2a 100644 --- a/bip-0064.mediawiki +++ b/bip-0064.mediawiki @@ -86,7 +86,7 @@ If the requesting client is looking up outputs for a signed transaction that the client can partly verify the returned output by running the input scripts with it. Currently this verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also allow the value to be checked in this way. It does not show that the output is really unspent or was -ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey +ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE. If the requesting client has a mapping of chain heights to block hashes in the best chain e.g. diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 1365884..db10c0c 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -170,7 +170,7 @@ Proving the sacrifice of some limited resource is a common technique in a variety of cryptographic protocols. Proving sacrifices of coins to mining fees has been proposed as a ''universal public good'' to which the sacrifice could be directed, rather than simply destroying the coins. However doing so is -non-trivial, and even the best existing technqiue - announce-commit sacrifices +non-trivial, and even the best existing technique - announce-commit sacrifices - could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to create outputs that are provably spendable by anyone (thus to mining fees assuming miners behave optimally and rationally) but only at a time @@ -205,19 +205,19 @@ transaction output ''can'' be spent. Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. - + case OP_NOP2: { // CHECKLOCKTIMEVERIFY // // (nLockTime -- nLockTime ) - + if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) break; // not enabled; treat as a NOP - + if (stack.size() < 1) return false; - + // Note that elsewhere numeric opcodes are limited to // operands in the range -2**31+1 to 2**31-1, however it is // legal for opcodes to produce results exceeding that @@ -233,13 +233,13 @@ semantics and detailed rationale for those semantics. // to 5-byte bignums, which are good until 2**32-1, the // same limit as the nLockTime field itself. const CScriptNum nLockTime(stacktop(-1), 5); - + // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKLOCKTIMEVERIFY. if (nLockTime < 0) return false; - + // There are two types of nLockTime: lock-by-blockheight // and lock-by-blocktime, distinguished by whether // nLockTime < LOCKTIME_THRESHOLD. @@ -252,12 +252,12 @@ semantics and detailed rationale for those semantics. (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) )) return false; - + // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nLockTime > (int64_t)txTo.nLockTime) return false; - + // Finally the nLockTime feature can be disabled and thus // CHECKLOCKTIMEVERIFY bypassed if every txin has been // finalized by setting nSequence to maxint. The @@ -270,9 +270,9 @@ semantics and detailed rationale for those semantics. // required to prove correct CHECKLOCKTIMEVERIFY execution. if (txTo.vin[nIn].IsFinal()) return false; - + break; - + } https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4 diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index 936d507..53289f5 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -75,7 +75,7 @@ bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) { // Verify that the length of the signature matches the sum of the length // of the elements. if ((size_t)(lenR + lenS + 7) != sig.size()) return false; - + // Check whether the R element is an integer. if (sig[2] != 0x02) return false; @@ -140,7 +140,7 @@ An implementation for the reference client is available at https://github.com/bi ==Acknowledgements== -This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well. +This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well. ==Disclosures== diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index a31cc3d..94153d3 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -19,7 +19,7 @@ This BIP describes a method to deterministically generate multi-signature pay-to ==Motivation== -Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts. +Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts. Multi-signature pay-to-script-hash transactions are defined in BIP-0016<ref>[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]</ref>. The redeem script does not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. @@ -27,31 +27,31 @@ By adopting a sorting and encoding standard, compliant wallets will always produ While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this. -Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions. +Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions. This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider. ==Specification== For a set of public keys, ensure that they have been received in compressed form: - + 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da - 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 + 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 - -Sort them lexicographically according to their binary representation: - + +Sort them lexicographically according to their binary representation: + 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 -..before using the resulting list of keys in a standard multisig redeem script: - +..before using the resulting list of keys in a standard multisig redeem script: + OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG Hash the redeem script according to BIP-0016 to get the P2SH address. - + 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba - + ==Compatibility== * Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. * P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. @@ -75,11 +75,11 @@ Vector 1 ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z Vector 2 (Already sorted, no action required) -* List: +* List: ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404 -* Sorted: +* Sorted: ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404 @@ -89,12 +89,12 @@ Vector 2 (Already sorted, no action required) ** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH Vector 3: -* List: +* List: ** 030000000000000000000000000000000000004141414141414141414141414141 ** 020000000000000000000000000000000000004141414141414141414141414141 ** 020000000000000000000000000000000000004141414141414141414141414140 ** 030000000000000000000000000000000000004141414141414141414141414140 -* Sorted: +* Sorted: ** 020000000000000000000000000000000000004141414141414141414141414140 ** 020000000000000000000000000000000000004141414141414141414141414141 ** 030000000000000000000000000000000000004141414141414141414141414140 @@ -105,11 +105,11 @@ Vector 3: ** 32V85igBri9zcfBRVupVvwK18NFtS37FuD Vector 4: (from bitcore) -* List: +* List: ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da -** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 +** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 -* Sorted: +* Sorted: ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 @@ -119,13 +119,13 @@ Vector 4: (from bitcore) ** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba ==Acknowledgements== -The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP. +The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP. -==Usage & Implementations== -* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets -* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]] +==Usage & Implementations== +* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets +* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]] * [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell -* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]] +* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]] * [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]] == References == diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki index ea0761d..a84fce7 100644 --- a/bip-0068.mediawiki +++ b/bip-0068.mediawiki @@ -33,7 +33,7 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time. -The sequence number encoding is interpreted as follows: +The sequence number encoding is interpreted as follows: Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks. @@ -65,7 +65,7 @@ enum { /* Interpret sequence numbers as relative lock-time constraints. */ LOCKTIME_VERIFY_SEQUENCE = (1 << 0), }; - + /* Setting nSequence to this value for every input in a transaction * disables nLockTime. */ static const uint32_t SEQUENCE_FINAL = 0xffffffff; @@ -245,7 +245,7 @@ The most efficient way to calculate sequence number from relative lock-time is w // 0 <= nHeight < 65,535 blocks (1.25 years) nSequence = nHeight; nHeight = nSequence & 0x0000ffff; - + // 0 <= nTime < 33,554,431 seconds (1.06 years) nSequence = (1 << 22) | (nTime >> 9); nTime = (nSequence & 0x0000ffff) << 9; diff --git a/bip-0072.mediawiki b/bip-0072.mediawiki index d5e295e..ab9c32d 100644 --- a/bip-0072.mediawiki +++ b/bip-0072.mediawiki @@ -69,4 +69,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe ==References== -[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 +[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1 diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 8c49645..ebd5b37 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -18,11 +18,11 @@ This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol. -# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. +# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. # It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details. -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ==Copyright== @@ -217,9 +217,9 @@ message EncryptedProtocolMessage { |} ==Payment Protocol Process with InvoiceRequests== -The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below. +The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below. <br/><br/> -All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]]. +All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]]. <br/><br/> All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown. <br/><br/> @@ -257,14 +257,14 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL ===Payment Protocol Status Communication=== -Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately. +Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately. <br/><br/> The status_message value SHOULD be set with a human readable explanation of the status code. ====Payment Protocol Status Codes==== {| class="wikitable" ! Status Code !! Description -|- +|- | 1 || OK |- | 2 || Cancel @@ -324,7 +324,7 @@ For the following we assume the Sender already knows the Receiver's public key, ** Set '''signature''' value to the computed signature ===InvoiceRequest Validation=== -* Validate '''sender_public_key''' is a valid EC public key +* Validate '''sender_public_key''' is a valid EC public key * Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc). * If '''pki_type''' is None, [[#InvoiceRequest|InvoiceRequest]] is VALID * If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID @@ -366,7 +366,7 @@ For the following we assume the Sender already knows the Receiver's public key, The 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST be prefixed to the returned ciphertext. The decrypt operation will use the first 16 bytes of the ciphertext as the GCM authentication tag and the remainder of the ciphertext as the ciphertext in the decrypt operation. ====AES-256 GCM Additional Authenticated Data==== -When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated. +When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated. ===Initial Public Key Retrieval for InvoiceRequest Encryption=== Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following: @@ -387,7 +387,7 @@ Clients SHOULD keep in mind Receivers can broadcast a transaction without return ==Public Key & Signature Encoding== * All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. -* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed. +* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed. * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded. * All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1. diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki index 3528725..cc3ef5c 100644 --- a/bip-0078.mediawiki +++ b/bip-0078.mediawiki @@ -95,7 +95,7 @@ The payjoin proposal PSBT is sent in the HTTP response body, base64 serialized w To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header <code>Access-Control-Allow-Origin: *</code>. -The sender must ensure that the url refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a url representing an unencrypted or unauthenticated connection. +The sender must ensure that the URL refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a URL representing an unencrypted or unauthenticated connection. The original PSBT MUST: * Have all the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> information filled in. @@ -108,7 +108,7 @@ The original PSBT MAY: The payjoin proposal MUST: * Use all the inputs from the original PSBT. -* Use all the outputs which do not belongs to the receiver from the original PSBT. +* Use all the outputs which do not belong to the receiver from the original PSBT. * Only finalize the inputs added by the receiver. (Referred later as <code>additional inputs</code>) * Only fill the <code>witnessUTXO</code> or <code>nonWitnessUTXO</code> for the additional inputs. @@ -187,10 +187,10 @@ The well-known error codes are: |The receiver rejected the original PSBT. |} -The receiver is allowed to return implementation specific errors which may assist the sender to diagnose any issue. +The receiver is allowed to return implementation-specific errors which may assist the sender to diagnose any issue. However, it is important that error codes that are not well-known and that the message do not appear on the sender's software user interface. -Such error codes or messages could be used maliciously to phish a non technical user. +Such error codes or messages could be used maliciously to phish a non-technical user. Instead those errors or messages can only appear in debug logs. It is advised to hard code the description of the well known error codes into the sender's software. @@ -213,7 +213,7 @@ To prevent this, the sender can agree to pay more fee so the receiver make sure * The sender's transaction is time sensitive. -When a sender pick a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm. +When a sender picks a specific fee rate, the sender expects the transaction to be confirmed after a specific amount of time. But if the receiver adds an input without bumping the fee of the transaction, the payjoin transaction fee rate will be lower, and thus, longer to confirm. Our recommendation for <code>maxadditionalfeecontribution=</code> is <code>originalPSBTFeeRate * vsize(sender_input_type)</code>. @@ -244,8 +244,8 @@ The receiver needs to do some check on the original PSBT before proceeding: * If the sender included inputs in the original PSBT owned by the receiver, the receiver must either return error <code>original-psbt-rejected</code> or make sure they do not sign those inputs in the payjoin proposal. * If the sender's inputs are all from the same scriptPubKey type, the receiver must match the same type. If the receiver can't match the type, they must return error <code>unavailable</code>. * Make sure that the inputs included in the original transaction have never been seen before. -** This prevent [[#probing-attack|probing attacks]]. -** This prevent reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin. +** This prevents [[#probing-attack|probing attacks]]. +** This prevents reentrant payjoin, where a sender attempts to use payjoin transaction as a new original transaction for a new payjoin. <code>*</code>: Interactive receivers are not required to validate the original PSBT because they are not exposed to [[#probing-attack|probing attacks]]. @@ -257,26 +257,26 @@ The sender should check the payjoin proposal before signing it to prevent a mali * If the receiver's BIP21 signalled <code>pjos=0</code>, disable payment output substitution. * Verify that the transaction version, and the nLockTime are unchanged. * Check that the sender's inputs' sequence numbers are unchanged. -* For each inputs in the proposal: -** Verify that no keypaths is in the PSBT input +* For each input in the proposal: +** Verify that no keypaths are in the PSBT input ** Verify that no partial signature has been filled -** If it is one of the sender's input +** If it is one of the sender's inputs: *** Verify that input's sequence is unchanged. *** Verify the PSBT input is not finalized *** Verify that <code>non_witness_utxo</code> and <code>witness_utxo</code> are not specified. -** If it is one of the receiver's input +** If it is one of the receiver's inputs: *** Verify the PSBT input is finalized *** Verify that <code>non_witness_utxo</code> or <code>witness_utxo</code> are filled in. -** Verify that the payjoin proposal did not introduced mixed input's sequence. -** Verify that the payjoin proposal did not introduced mixed input's type. +** Verify that the payjoin proposal inputs all specify the same sequence value. +** Verify that the payjoin proposal did not introduce mixed input's type. ** Verify that all of sender's inputs from the original PSBT are in the proposal. -* For each outputs in the proposal: -** Verify that no keypaths is in the PSBT output +* For each output in the proposal: +** Verify that no keypaths are in the PSBT output ** If the output is the [[#fee-output|fee output]]: *** The amount that was subtracted from the output's value is less than or equal to <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>. -*** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT. -*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section) -** If the output is the payment output and payment output substitution is allowed. +*** Make sure the actual contribution is only going towards fees: The <code>actual contribution</code> is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT. +*** Make sure the actual contribution is only paying for fees incurred by additional inputs: <code>actual contribution</code> is less than or equal to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (see [[#fee-output|Fee output]] section) +** If the output is the payment output and payment output substitution is allowed, *** Do not make any check ** Else *** Make sure the output's value did not decrease. @@ -287,8 +287,8 @@ The sender must be careful to only sign the inputs that were present in the orig Note: * The sender must allow the receiver to add/remove or modify the receiver's own outputs. (if payment output substitution is disabled, the receiver's outputs must not be removed or decreased in value) -* The sender should allow the receiver to not add any inputs. This is useful for the receiver to change the paymout output scriptPubKey type. -* If no input have been added, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface. +* The sender should allow the receiver to not add any inputs. This is useful for the receiver to change the payment output scriptPubKey type. +* If the receiver added no inputs, the sender's wallet implementation should accept the payjoin proposal, but not mark the transaction as an actual payjoin in the user interface. Our method of checking the fee allows the receiver and the sender to batch payments in the payjoin transaction. It also allows the receiver to pay the fee for batching adding his own outputs. @@ -344,7 +344,7 @@ On top of this the receiver can poison analysis by randomly faking a round amoun ===<span id="output-substitution"></span>Payment output substitution=== -Unless disallowed by sender explicitly via `disableoutputsubstitution=true` or by the BIP21 url via query parameter the `pjos=0`, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself. +Unless disallowed by the sender explicitly via <code>disableoutputsubstitution=true</code> or by the BIP21 URL via the query parameter <code>pjos=0</code>, the receiver is free to decrease the amount, remove, or change the scriptPubKey output paying to himself. Note that if payment output substitution is disallowed, the reveiver can still increase the amount of the output. (See [[#reference-impl|the reference implementation]]) For example, if the sender's scriptPubKey type is P2WPKH while the receiver's payment output in the original PSBT is P2SH, then the receiver can substitute the payment output to be P2WPKH to match the sender's scriptPubKey type. @@ -358,7 +358,7 @@ A compromised payjoin server could steal the hot wallet outputs of the receiver, ===Impacted heuristics=== -Our proposal of payjoin is breaking the following blockchain heuristics: +Our proposal of payjoin breaks the following blockchain heuristics: * Common inputs heuristics. @@ -408,7 +408,7 @@ With payjoin, the maximum amount of money that can be lost is equal to two payme ==<span id="reference-impl"></span>Reference sender's implementation== Here is pseudo code of a sender implementation. -<code>RequestPayjoin</code> takes the bip21 URI of the payment, the wallet and the <code>signedPSBT</code>. +<code>RequestPayjoin</code> takes the BIP21 URI of the payment, the wallet and the <code>signedPSBT</code>. The <code>signedPSBT</code> represents a PSBT which has been fully signed, but not yet finalized. We then prepare <code>originalPSBT</code> from the <code>signedPSBT</code> via the <code>CreateOriginalPSBT</code> function and get back the <code>proposal</code>. @@ -674,7 +674,7 @@ A successful exchange with: ==Backward compatibility== -The receivers are advertising payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]]. +The receivers advertise payjoin capabilities through [[bip-0021.mediawiki|BIP21's URI Scheme]]. Senders not supporting payjoin will just ignore the <code>pj</code> variable and thus, will proceed to normal payment. diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index 797c8f1..0c31c1c 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -84,7 +84,7 @@ After adding inputs to the transaction, the receiver generally will want to adju === Returning the partial transaction === -The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header "Access-Control-Allow-Origin: *" +The receiver must sign all contributed inputs in the partial transaction. The partial transaction should also remove all witnesses from the original template transaction as they are no longer valid, and need to be recalculated by the sender. The receiver returns the partial transaction as a binary-encoded HTTP response with a status code of 200. To ensure compatibility with web-wallets and browser-based-tools, all responses (including errors) must contain the HTTP header "Access-Control-Allow-Origin: *" === Sender Validation === diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki index c669001..8c6f444 100644 --- a/bip-0083.mediawiki +++ b/bip-0083.mediawiki @@ -83,7 +83,7 @@ We can continue creating subaccounts indefinitely using this scheme. In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain. -By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. +By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children. ==References== diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki index 7311d8a..633210c 100644 --- a/bip-0085.mediawiki +++ b/bip-0085.mediawiki @@ -364,7 +364,7 @@ This specification relies on BIP32 but is agnostic to how the BIP32 root key is ==Discussion== -The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. +The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur. ==Acknowledgements== diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki index 529f094..7bcaf14 100644 --- a/bip-0086.mediawiki +++ b/bip-0086.mediawiki @@ -5,7 +5,7 @@ Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086 - Status: Draft + Status: Final Type: Standards Track Created: 2021-06-22 License: BSD-2-Clause diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki index 308e852..920bd3c 100644 --- a/bip-0087.mediawiki +++ b/bip-0087.mediawiki @@ -48,7 +48,7 @@ The second multisignature "standard" in use is m/48', which specifies: m / purpose' / coin_type' / account' / script_type' / change / address_index </pre> -Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, <code>script_type</code> list. +Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintenance work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, <code>script_type</code> list. The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type <ref>'''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually). Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84). With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring. Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only.</ref>. diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki index 49be7db..c4c02e7 100644 --- a/bip-0088.mediawiki +++ b/bip-0088.mediawiki @@ -41,7 +41,7 @@ addresses differently than the one they used before. The problem is common enough to warrant the creation of a dedicated website ([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets. -At the time of writing, this website has used their own format to succintly describe multiple +At the time of writing, this website has used their own format to succinctly describe multiple derivation paths. As far as author knows, it was the only publicitly used format to describe path templates before introduction of this BIP. The format was not specified anywhere beside the main page of the website. It used <code>|</code> to denote alternative derivation indexes @@ -52,7 +52,7 @@ an ad-hoc format only intended for illustration. In contrast to this ad-hoc form described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use of <code>|</code> in the template could allow. Wider range of paths can be defined in a single template more -succintly and unambiguously. +succinctly and unambiguously. ===Intended use and advantages=== @@ -71,7 +71,7 @@ into using well-known paths, or convince other vendors to support their custom p scales poorly. A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates" -that succintly describes the constraints to impose on the derivation path. +that succinctly describes the constraints to impose on the derivation path. Wide support for these path templates will increase interoperability and flexibility of solutions, and will allow vendors and individual developers to easily define their own custom restrictions. @@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though. ==Specification== -The format for the template was chosen to make it easy to read, convenient and visually unambigous. +The format for the template was chosen to make it easy to read, convenient and visually unambiguous. Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>). diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki index 4c96698..48d4151 100644 --- a/bip-0090.mediawiki +++ b/bip-0090.mediawiki @@ -82,7 +82,7 @@ https://github.com/bitcoin/bitcoin/pull/8391. ==References== -[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase] +[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase] [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures] diff --git a/bip-0093.mediawiki b/bip-0093.mediawiki index da349fd..22a7ba3 100644 --- a/bip-0093.mediawiki +++ b/bip-0093.mediawiki @@ -354,7 +354,7 @@ Instead every different language has it own word list (or word lists) and each c We would need to encode the choice of word list in our share's meta-data, which takes up even more room, and is difficult to specify due to the ever-evolving choice of word lists. Alternatively we could standardize on the choice of the English word list, something that is nearly a de facto standard, and simply be incompatible with BIP-0039 wallets of other languages. -Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list. +Such a choice also risks users of BIP-0039 recovering their entropy from their language, encoding it in Codex32 and then failing to recover their wallet because the English word lists has replaced their language's word list. The main advantage of this alternative approach would be that wallets could give users an option switch between backing up their entropy as a BIP-0039 mnemonic and in Codex32 format, but again, only if their language choice happens to be the English word list. In practice, we do not expect users in switch back and forth between backup formats, and instead just generate a fresh master seed using Codex32. diff --git a/bip-0098.mediawiki b/bip-0098.mediawiki index 8540d1a..a296fdc 100644 --- a/bip-0098.mediawiki +++ b/bip-0098.mediawiki @@ -241,16 +241,16 @@ Disallowing a node with two SKIP branches eliminates what would otherwise be a s The number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined), and is exactly equal to the number of inner nodes serialized as the beginning of the proof as N. -The variable-length integer encoding has the property that serialized integers, sorted lexigraphically, will also be sorted numerically. -Since the first serialized item is the number of inner nodes, sorting proofs lexigraphically has the effect of sorting the proofs by the amount of work required to verify. +The variable-length integer encoding has the property that serialized integers, sorted lexicographically, will also be sorted numerically. +Since the first serialized item is the number of inner nodes, sorting proofs lexicographically has the effect of sorting the proofs by the amount of work required to verify. The number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes, and can be quickly calculated without parsing the tree structure. -The coding and packing rules for the serialized tree structure were also chosen to make lexigraphical comparison useful (or at least not meaningless). +The coding and packing rules for the serialized tree structure were also chosen to make lexicographical comparison useful (or at least not meaningless). If we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right, then we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes. -Lexigraphically comparing the resulting serialized tree structures is the same as lexigraphically comparing lists of indices from the original list verified by the derived proof. +Lexicographically comparing the resulting serialized tree structures is the same as lexicographically comparing lists of indices from the original list verified by the derived proof. Because the number of inner nodes and the number of SKIP hashes is extractible from the tree structure, both variable-length integers in the proof are redundant and could have been omitted. diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 156eec0..5368b53 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -23,7 +23,7 @@ not always well-understood, and the best upgrade mechanisms to the consensus validation rules may vary depending on the type of change being deployed. Discussing such changes without a uniform view on the deployment paths often leads to misunderstandings and unnecessarily delays the -deployment of changes. +deployment of changes. ==Definitions== @@ -43,7 +43,7 @@ deployment of changes. : a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest). ;Libbitcoinconsensus -: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line +: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line ==Taxonomy of consensus forks== @@ -76,14 +76,14 @@ without burdening them with specific design choices made by Bitcoin Core. It is to be noted that sharing the same code for consensus validation doesn't prevent alternative implementations from independently changing their consensus rules: they can always fork -the libbitcoinconsensus project (once it is in a separate repository). +the libbitcoinconsensus project (once it is in a separate repository). Hopefully libbitcoinconsensus will remove this type of consensus fork which - being accidental - obviously doesn't need a deployment plan. ====11/12 March 2013 Chain Fork==== -There is a precedent of an accidental consensus fork at height 225430. +There is a precedent of an accidental consensus fork at height 225430. Without entering into much detail (see [2]), the situation was different from what's being described from the alternative implementation risks (today alternative implementation still usually rely in different degrees on Bitcoin Core trusted proxies, which @@ -104,7 +104,7 @@ rapidly by the whole worldwide community and nobody is unhappy about the solution. But there's some philosophical disagreements on the terms of what the -solution was: we can add a pedantic note on that. +solution was: we can add a pedantic note on that. If "the implementation is the specification", then those levelDB-specific limitations were part of the consensus rules. Then additional rules were necessary and any alternative @@ -126,7 +126,7 @@ another consensus fork to remove them. Two theoretical consensus forks instead of one but the first one deployed practically for free. The practical result would have been identical and only the definitions change. This means discussing something that went uncontroversially -well further is "philosophical bike-shed" (TM). +well further is "philosophical bike-shed" (TM). ===Unilateral softforks=== @@ -157,17 +157,17 @@ that this must always be the case. While 2 chains cohexist, they can be considered two different currencies. We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market -capitalization are completely unpredictable, +capitalization are completely unpredictable, -maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), +maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), -maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), +maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin), maybe mc(bitcoinA) + mc(bitcoinB) = 0, -... +... Schism hardforks have been compared to one type of altcoins called "spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to @@ -224,7 +224,7 @@ Let's imagine BIP66 had a crypto backdoor that nobody noticed and allows an evil developer cabal to steal everyone's coins. The users and non-evil developers could join, fork libconsensus and use the forked version in their respective bitcoin -implementations. +implementations. Should miner's "vote" be required to express their consent? What if some miners are part of the cabal? In the unlikely event that most miners are part of such an evil cabal, changing the pow function may be @@ -268,7 +268,7 @@ that's why the voting mechanism and first used for BIP30 and BIP66. The current voting threshold for softfork enforcement is 95%. There's also a 75% threshold for miners to activate it as a policy rule, but it should be safe for miners to activate such a policy from the start -or later than 75%, as long as they enforce it as consensus rule after 95%. +or later than 75%, as long as they enforce it as consensus rule after 95%. The current miners' voting mechanism can be modified to allow for changes to be deployed in parallel, the rejection of a concrete @@ -355,12 +355,12 @@ worth of blocks). [5] Original references: https://bitcointalk.org/index.php?topic=114751.0 https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 -Rebased patch: +Rebased patch: https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14 ==Attribution== -Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, +Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke. ==Copyright== diff --git a/bip-0104.mediawiki b/bip-0104.mediawiki index 1244b3e..4d81110 100644 --- a/bip-0104.mediawiki +++ b/bip-0104.mediawiki @@ -65,7 +65,7 @@ A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because: Allow miners to vote for max block size, rejected because: * overly complex and political * human involvement makes this slow to respond to changing transaction volumes -* focuses power over max block size to a relatively small group of people +* focuses power over max block size to a relatively small group of people * unpredictable transaction fees caused by this would create uncertainty in the ecosystem ==Backward Compatibility== diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki index 3643562..af41691 100644 --- a/bip-0105.mediawiki +++ b/bip-0105.mediawiki @@ -13,21 +13,21 @@ ==Abstract== -A method of altering the maximum allowed block size of the Bitcoin protocol +A method of altering the maximum allowed block size of the Bitcoin protocol using a consensus based approach. ==Motivation== -There is a belief that Bitcoin cannot easily respond to raising the -blocksize limit if popularity was to suddenly increase due to a mass adoption -curve, because co-ordinating a hard fork takes considerable time, and being -unable to respond in a timely manner would irreparably harm the credibility of +There is a belief that Bitcoin cannot easily respond to raising the +blocksize limit if popularity was to suddenly increase due to a mass adoption +curve, because co-ordinating a hard fork takes considerable time, and being +unable to respond in a timely manner would irreparably harm the credibility of bitcoin. Additionally, predetermined block size increases are problematic because they -attempt to predict the future, and if too large could have unintended -consequences like damaging the possibility for a fee market to develop -as block subsidy decreases substantially over the next 9 years; introducing +attempt to predict the future, and if too large could have unintended +consequences like damaging the possibility for a fee market to develop +as block subsidy decreases substantially over the next 9 years; introducing or exacerbating mining attack vectors; or somehow affect the network in unknown or unpredicted ways. Since fixed changes are hard to deploy, the damage could be extensive. @@ -36,14 +36,14 @@ Dynamic block size adjustments also suffer from the potential to be gamed by the larger hash power. Free voting as suggested by BIP100 allows miners to sell their votes out of band -at no risk, and enable the sponsor the ability to manipulate the blocksize. +at no risk, and enable the sponsor the ability to manipulate the blocksize. It also provides a cost free method or the larger pools to vote in ways to manipulate the blocksize such to disadvantage or attack smaller pools. ==Rationale== -By introducing a cost to increase the block size ensures the mining community +By introducing a cost to increase the block size ensures the mining community will collude to increase it only when there is a clear necessity, and reduce it when it is unnecessary. Larger miners cannot force their wishes so easily because not only will they have to pay extra a difficulty target, then can be @@ -63,7 +63,7 @@ honest. The initial block size limit shall be 1MB. Each time a miner creates a block, they may vote to increase or decrease the -blocksize by a maximum of 10% of the current block size limit. These votes will +blocksize by a maximum of 10% of the current block size limit. These votes will be used to recalculate the new block size limit every 2016 blocks. Votes are cast using the block's coinbase transaction scriptSig. @@ -77,7 +77,7 @@ If a miner votes for an increase, the block hash must meet a difficulty target which is proportionally larger than the standard difficulty target based on the percentage increase they voted for. -Votes proposing decreasing the block size limit do not need to meet a higher +Votes proposing decreasing the block size limit do not need to meet a higher difficulty target. Miners can vote for no change by voting for the current block size. diff --git a/bip-0106.mediawiki b/bip-0106.mediawiki index 193d4cd..84b0498 100644 --- a/bip-0106.mediawiki +++ b/bip-0106.mediawiki @@ -36,13 +36,13 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false& Keep the same MaxBlockSize ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== - + TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) - + TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) - + If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) ) diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki index b82db61..915657a 100644 --- a/bip-0107.mediawiki +++ b/bip-0107.mediawiki @@ -24,7 +24,7 @@ Over the next few years, large infrastructure investments will be made into: # Layer 2 services and networks for off-chain transactions # General efficiency improvements to transactions and the blockchain -* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. +* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. * In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'. * These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network. @@ -40,7 +40,7 @@ Over the next few years, large infrastructure investments will be made into: * '''Phase 2''' ** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume ** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur -*** This calculates to a theoretical maximum of 13 increases per year +*** This calculates to a theoretical maximum of 13 increases per year ** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10% ** The maximum block size can only ever be increased, not decreased * The default <code>limitfreerelay</code> will also be raised in proportion to maximum block size increases @@ -49,8 +49,8 @@ Over the next few years, large infrastructure investments will be made into: For example: * When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB -* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. -* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. +* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. +* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. ==Rationale== @@ -63,19 +63,19 @@ For example: *** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place *** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size **** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered -*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. +*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. ** Why 3025 blocks? *** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 *** Increases in the maximum block size should only occur after a sustained trend can be observed in order to: ***# Demonstrate a market-driven secular elevation in the transaction volume -***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions +***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions *** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand ** Why 10% increase in the block size? *** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities to increase the block size per year -*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community +*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community ==Deployment== -Similar deployment model to BIP101: +Similar deployment model to BIP101: <blockquote>Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.</blockquote> ==Acknowledgements== diff --git a/bip-0109.mediawiki b/bip-0109.mediawiki index 4822d4a..ec1d7e5 100644 --- a/bip-0109.mediawiki +++ b/bip-0109.mediawiki @@ -65,7 +65,7 @@ SPV (simple payment validation) wallets are compatible with this change. ==Rationale== -In the short term, an increase is needed to handle increasing transaction volume. +In the short term, an increase is needed to handle increasing transaction volume. The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software. diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki index d6ed546..f38fa15 100644 --- a/bip-0112.mediawiki +++ b/bip-0112.mediawiki @@ -69,13 +69,13 @@ address with the following redeemscript. <Alice's pubkey> CHECKSIG ENDIF -At any time funds can be spent using signatures from any two of Alice, +At any time funds can be spent using signatures from any two of Alice, Bob or the Escrow. After 30 days Alice can sign alone. The clock does not start ticking until the payment to the escrow address -confirms. +confirms. ===Retroactive Invalidation=== @@ -230,7 +230,7 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics ==Specification== -Refer to the reference implementation, reproduced below, for the precise +Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics. <pre> @@ -247,7 +247,7 @@ static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22); /* If CTxIn::nSequence encodes a relative lock-time, this mask is * applied to extract that lock-time from the sequence field. */ static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; - + case OP_NOP3: { if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { @@ -290,7 +290,7 @@ case OP_NOP3: break; } - + bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const { // Relative lock times are supported by comparing the passed diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki index 3686777..d736280 100644 --- a/bip-0113.mediawiki +++ b/bip-0113.mediawiki @@ -45,13 +45,13 @@ BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY). ==Specification== -The values for transaction locktime remain unchanged. The difference is only in -the calculation determining whether a transaction can be included. Instead of -an unreliable timestamp, the following function is used to determine the current +The values for transaction locktime remain unchanged. The difference is only in +the calculation determining whether a transaction can be included. Instead of +an unreliable timestamp, the following function is used to determine the current block time for the purpose of checking lock-time constraints: enum { nMedianTimeSpan=11 }; - + int64_t GetMedianTimePast(const CBlockIndex* pindex) { int64_t pmedian[nMedianTimeSpan]; diff --git a/bip-0115.mediawiki b/bip-0115.mediawiki index 8bc90f6..042d057 100644 --- a/bip-0115.mediawiki +++ b/bip-0115.mediawiki @@ -98,7 +98,7 @@ What if ParamBlockHash has leading zeros? Should this be prevented? * If leading zeros are included, they should be compared to the actual block hash. (If they were truncated, fewer bytes would be compared.) * It is unlikely that the leading zeros will ever be necessary for sufficient precision, so the additional space is not a concern. -* Since all block hashes are in principle shorter than than 29 bytes, ParamBlockHash may not be larger than 28 bytes. +* Since all block hashes are in principle shorter than 29 bytes, ParamBlockHash may not be larger than 28 bytes. Why is it safe to allow checking blocks as recently as the immediate previous block? diff --git a/bip-0116.mediawiki b/bip-0116.mediawiki index 86b0f9a..70b340f 100644 --- a/bip-0116.mediawiki +++ b/bip-0116.mediawiki @@ -59,7 +59,7 @@ This includes execution pathways or policy conditions which end up not being nee Not only is it inefficient to require this unnecessary information to be present on the blockchain, albeit in the witness, it also impacts privacy and fungibility as some unused script policies may be identifying. Using a Merkle hash tree to commit to the policy options, and then only forcing revelation of the policy used at redemption minimizes this information leakage. -Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would would otherwise be possible, due to various built-in script size and runtime limitations. +Using Merkle hash trees to commit to policy allows for considerably more complex contracts than would otherwise be possible, due to various built-in script size and runtime limitations. With Merkle commitments to policy these size and runtime limitations constrain the complexity of any one policy that can be used rather than the sum of all possible policies. ==Rationale== diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index d661f4c..be1f70c 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -193,7 +193,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial. The Bitcoin Core reference implementation includes the below parameters, configured to match Speedy Trial, as that is the current activation mechanism implemented in Bitcoin Core. Should another method become favored by the wider -Bitcoin comminity, that might be used instead. +Bitcoin community, that might be used instead. The start time and bit in the implementation are currently set to bit 5 and NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft. @@ -314,7 +314,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that the max inputs in a block is further restricted by the block size to around 25,000, which would fit -into a `uint16_t`, but that is an uneccessary abstraction leak. +into a `uint16_t`, but that is an unnecessary abstraction leak. =====Committing to the Sequences Hash===== @@ -362,7 +362,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe This makes it safer to design wallet vault contracts without half-spend vulnerabilities. Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can -be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped +be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are added to Bitcoin, the index may simply be passed in by the witness before hashing. @@ -476,7 +476,7 @@ An example of a script that could experience an DoS issue without caching is: <H> CTV CTV CTV... CTV -Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data. +Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data. If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N) times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations over all variable length fields in a transaction. @@ -616,7 +616,7 @@ sponsors might be considered. An opcode which verifies the exact amount that is being spent in the transaction, the amount paid as fees, or made available in a given output could -be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the +be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1 satoshis would result in a frozen UTXO and sending S+n satoshis would result in n satoshis being paid to fee. A range check could restrict the program to only diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki index b951e93..c9c11e5 100644 --- a/bip-0120.mediawiki +++ b/bip-0120.mediawiki @@ -52,7 +52,7 @@ A proof of payment for a transaction T, here called PoP(T), is used to prove tha OP_RETURN <version> <txid> <nonce> -{| +{| ! Field !! Size [B] !! Description |- | <version> || 2 || Version, little endian, currently 0x01 0x00 @@ -77,7 +77,7 @@ An illustration of the PoP data structure and its original payment is shown belo |input2 4,ffffffff | 1,pay to B | | | 4,pay to C | +------------------------------------------------+ - + PoP(T) +-------------------------------------------------------------+ | inputs | outputs | diff --git a/bip-0122.mediawiki b/bip-0122.mediawiki index 3fb5df8..6243c64 100644 --- a/bip-0122.mediawiki +++ b/bip-0122.mediawiki @@ -43,7 +43,7 @@ Where: | rowspan="3" | type | tx | for transactions. -| rowspan="3" | required +| rowspan="3" | required |- | block | for blocks (supports both hash or height). @@ -75,9 +75,9 @@ The '''chain ID''' of a chain is the block hash of the corresponding genesis blo So, for example: <pre> -Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f +Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f Bitcoin test : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 -Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 +Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 </pre> An example of forked chain (Feathercoin, that forked Litecoin): @@ -87,7 +87,7 @@ An example of forked chain (Feathercoin, that forked Litecoin): <pre> Litecoin : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2 Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb -</pre> +</pre> ==Examples== diff --git a/bip-0123.mediawiki b/bip-0123.mediawiki index 2404937..a0dfd2c 100644 --- a/bip-0123.mediawiki +++ b/bip-0123.mediawiki @@ -72,7 +72,7 @@ There's room at this layer to allow for competing standards without breaking bas ===4. Applications Layer=== -The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. +The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. ==Classification of existing BIPs== diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki index b5dfae8..1eaf55d 100644 --- a/bip-0129.mediawiki +++ b/bip-0129.mediawiki @@ -95,7 +95,7 @@ The Signer is any software or hardware that controls the private keys and can si * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>. * If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record. * The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a descriptor or a descriptor template. The third line must be a comma-separated list of derivation path restrictions. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction. -* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. +* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>. * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>. * The Coordinator sends the encrypted descriptor record to all participating Signers. @@ -110,7 +110,7 @@ The Signer is any software or hardware that controls the private keys and can si * The Signer checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof. * The Signer verifies that it is compatible with the derivation path restrictions. * The Signer verifies that the wallet's first address is valid. -* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request. +* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request. * Parties must check with each other that all Signers have the same confirmation (except for the <tt>KEY</tt> positions). * If all checks pass, the Signer must persist the descriptor record in its storage. @@ -126,8 +126,8 @@ We define three modes of encryption. # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce. The <tt>TOKEN</tt> can be converted to one of these formats: -* A decimal number (recommended). The number must not exceed the maximum value of the nonce. -* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics. +* A decimal number (recommended). The number must not exceed the maximum value of the nonce. +* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics. * A QR code. * Other formats. diff --git a/bip-0130.mediawiki b/bip-0130.mediawiki index 8d96c0c..d88329f 100644 --- a/bip-0130.mediawiki +++ b/bip-0130.mediawiki @@ -5,7 +5,7 @@ Author: Suhas Daftuar <sdaftuar@chaincode.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130 - Status: Proposed + Status: Final Type: Standards Track Created: 2015-05-08 License: PD diff --git a/bip-0132.mediawiki b/bip-0132.mediawiki index 173c919..2b2b26c 100644 --- a/bip-0132.mediawiki +++ b/bip-0132.mediawiki @@ -83,7 +83,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c ** User communities * A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment. -'''Committee Declarations.''' +'''Committee Declarations.''' * At any point, a Committee Declaration can be posted. * This Declaration must contain details about: ** The segment the Committee is representing diff --git a/bip-0134.mediawiki b/bip-0134.mediawiki index b7c33cf..4af4844 100644 --- a/bip-0134.mediawiki +++ b/bip-0134.mediawiki @@ -58,7 +58,7 @@ various decades ago with the XML format. The idea is that we give each field a name and this means that new fields can be added or optional fields can be omitted from individual transactions. Some other ideas are the standardization of data-formats (like integer and string encoding) so -we create a more consistent system. +we create a more consistent system. One thing we shall not inherit from XML is its text-based format. Instead we use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format] (CMF) which is optimized to keep the size small and fast to parse. diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki index 1324746..a4c0647 100644 --- a/bip-0135.mediawiki +++ b/bip-0135.mediawiki @@ -170,7 +170,7 @@ A given deployment SHALL remain in the DEFINED state until it either passes the starttime (and becomes STARTED) or the timeout time (and becomes FAILED). Once a deployment has STARTED, the signal for that deployment SHALL be tallied -over the the past windowsize blocks whenever a new block is received on that +over the past windowsize blocks whenever a new block is received on that chain. A transition from the STARTED state to the LOCKED_IN state SHALL only occur @@ -183,7 +183,7 @@ when all of these are true: A similar height synchronization precondition SHALL exist for the transition from LOCKED_IN to ACTIVE. These synchronization conditions are expressed by the "mod(height, windowsize) = 0" -clauses in the diagram, and have been been added so that backward compatibility +clauses in the diagram, and have been added so that backward compatibility with BIP9's use of the 2016-block re-targeting periods can be configured for existing deployments (see above 'Optional full backward compatibility' section). @@ -261,7 +261,7 @@ proposal, although a conventional fallow period of 3 months is RECOMMENDED. Due to the constraints set by BIP 34, BIP 66 and BIP 65, there are only 0x7FFFFFFB possible nVersion values available. This limits to at most 30 independent deployments. -By restricting the top 3 bits to 001 we we are left with 29 out of those for +By restricting the top 3 bits to 001 we are left with 29 out of those for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). diff --git a/bip-0137.mediawiki b/bip-0137.mediawiki index 575440b..ccba17f 100644 --- a/bip-0137.mediawiki +++ b/bip-0137.mediawiki @@ -15,7 +15,7 @@ This document describes a signature format for signing messages with Bitcoin private keys. -The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. +The specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme. One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures. diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index 88131f4..c8f22f7 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -62,7 +62,7 @@ This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bi The existing <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> have a bug<ref>[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]]</ref> that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary. The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed. -The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. +The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transaction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures. === Tracking Normalized Transaction IDs === diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 117ca59..4ba6798 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -43,13 +43,13 @@ By removing this data from the transaction structure committed to the transactio A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs. Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format: - + [nVersion][txins][txouts][nLockTime] - + A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data: - + [nVersion][marker][flag][txins][txouts][witness][nLockTime] - + Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization. The <code>marker</code> MUST be a 1-byte zero value: <code>0x00</code>. @@ -67,14 +67,14 @@ A new block rule is added which requires a commitment to the <code>wtxid</code>. A <code>witness root hash</code> is calculated with all those <code>wtxid</code> as leaves, in a way similar to the <code>hashMerkleRoot</code> in the block header. The commitment is recorded in a <code>scriptPubKey</code> of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is: - + 1-byte - OP_RETURN (0x6a) 1-byte - Push the following 36 bytes (0x24) 4-byte - Commitment header (0xaa21a9ed) 32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value) - + 39th byte onwards: Optional data with no consensus meaning - + and the coinbase's input's witness must consist of a single 32-byte array for the <code>witness reserved value</code>. If there are more than one <code>scriptPubKey</code> matching the pattern, the one with highest output index is assumed to be the commitment. diff --git a/bip-0142.mediawiki b/bip-0142.mediawiki index b11095b..49ed8dc 100644 --- a/bip-0142.mediawiki +++ b/bip-0142.mediawiki @@ -24,14 +24,14 @@ To define standard payment address for native segregated witness (segwit) transa The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH). The new address is encoded in a way similar to existing address formats: - + base58-encode: [1-byte address version] [1-byte witness program version] [0x00] [20/32-byte-hash] [4-byte checksum] - + For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address. For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address. @@ -123,25 +123,25 @@ This proposal is forward-compatible with future versions of witness programs of == Example == The following public key, - + 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 - + when encoded as a P2PKH template, would become: - + DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG With the corresponding version 1 Bitcoin address being: - + 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM - -When the same public key is encoded as P2WPKH, the scriptPubKey becomes: - + +When the same public key is encoded as P2WPKH, the scriptPubKey becomes: + OP_0 <010966776006953D5567439E5E39F86A0D273BEE> Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is: - + p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm - + == Reference implementation == https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80 diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 9935eaa..3146b5f 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -31,7 +31,7 @@ A new transaction digest algorithm is defined, but only applicable to sigops in 1. nVersion of the transaction (4-byte little endian) 2. hashPrevouts (32-byte hash) 3. hashSequence (32-byte hash) - 4. outpoint (32-byte hash + 4-byte little endian) + 4. outpoint (32-byte hash + 4-byte little endian) 5. scriptCode of the input (serialized as scripts inside CTxOuts) 6. value of the output spent by this input (8-byte little endian) 7. nSequence of the input (4-byte little endian) @@ -77,7 +77,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit uint256 hashPrevouts; uint256 hashSequence; uint256 hashOutputs; - + if (!(nHashType & SIGHASH_ANYONECANPAY)) { CHashWriter ss(SER_GETHASH, 0); for (unsigned int n = 0; n < txTo.vin.size(); n++) { @@ -85,7 +85,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit } hashPrevouts = ss.GetHash(); } - + if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { CHashWriter ss(SER_GETHASH, 0); for (unsigned int n = 0; n < txTo.vin.size(); n++) { @@ -93,7 +93,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit } hashSequence = ss.GetHash(); } - + if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { CHashWriter ss(SER_GETHASH, 0); for (unsigned int n = 0; n < txTo.vout.size(); n++) { @@ -105,7 +105,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit ss << txTo.vout[nIn]; hashOutputs = ss.GetHash(); } - + CHashWriter ss(SER_GETHASH, 0); // Version ss << txTo.nVersion; @@ -114,7 +114,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit ss << hashSequence; // The input being signed (replacing the scriptSig with scriptCode + amount) // The prevout may already be contained in hashPrevout, and the nSequence - // may already be contain in hashSequence. + // may already be contained in hashSequence. ss << txTo.vin[nIn].prevout; ss << static_cast<const CScriptBase&>(scriptCode); ss << amount; @@ -125,7 +125,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit ss << txTo.nLockTime; // Sighash type ss << nHashType; - + return ss.GetHash(); </source> @@ -139,42 +139,42 @@ Since this policy is preparation for a future softfork proposal, to avoid potent To ensure consistency in consensus-critical behaviour, developers should test their implementations against all the tests below. More tests related to this proposal could be found under https://github.com/bitcoin/bitcoin/tree/master/src/test/data . === Native P2WPKH === - + The following is an unsigned transaction: 0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000 - + nVersion: 01000000 txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac nLockTime: 11000000 - + The first input comes from an ordinary P2PK: scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 private key : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866 - + The second input comes from a P2WPKH witness program: scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6 private key : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9 public key : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357 - + To sign it with a nHashType of 1 (SIGHASH_ALL): - + hashPrevouts: dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000) = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 - + hashSequence: dSHA256(eeffffffffffffff) = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b - + hashOutputs: dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac) = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 - + hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000 - + nVersion: 01000000 hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b @@ -185,12 +185,12 @@ To ensure consistency in consensus-critical behaviour, developers should test th hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 nLockTime: 11000000 nHashType: 01000000 - + sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 - + The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 - + nVersion: 01000000 marker: 00 flag: 01 @@ -203,38 +203,38 @@ To ensure consistency in consensus-critical behaviour, developers should test th nLockTime: 11000000 === P2SH-P2WPKH === - - + + The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000 - + nVersion: 01000000 txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac 0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac nLockTime: 92040000 - + The input comes from a P2SH-P2WPKH witness program: scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10 redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089 private key : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf public key : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873 - + To sign it with a nHashType of 1 (SIGHASH_ALL): - + hashPrevouts: dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000) = b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a - + hashSequence: dSHA256(feffffff) = 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198 - + hashOutputs: dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac) = de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83 - + hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000 - + nVersion: 01000000 hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198 @@ -245,10 +245,10 @@ To ensure consistency in consensus-critical behaviour, developers should test th hashOutputs: de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83 nLockTime: 92040000 nHashType: 01000000 - + sigHash: 64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6 signature: 3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01 - + The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000 nVersion: 01000000 marker: 00 @@ -263,33 +263,33 @@ To ensure consistency in consensus-critical behaviour, developers should test th This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> are processed: - - + + The following is an unsigned transaction: 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000 - + nVersion: 01000000 txin: 02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff 0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff txout: 01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac nLockTime: 00000000 - + The first input comes from an ordinary P2PK: scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625 private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL) - + The second input comes from a native P2WSH witness program: scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49 witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG - + To sign it with a nHashType of 3 (SIGHASH_SINGLE): - + hashPrevouts: dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000) = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41 - + nVersion: 01000000 hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41 hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 @@ -300,7 +300,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output) nLockTime: 00000000 nHashType: 03000000 - + scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac ^^ (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode) @@ -309,7 +309,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703 - + scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 @@ -317,36 +317,36 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465 private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503 - + The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000 This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, and <code>SINGLE|ANYONECANPAY</code> does not commit to the input index: - - + + The following is an unsigned transaction: 0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000 - + nVersion: 01000000 txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac nLockTime: 00000000 - + The first input comes from a native P2WSH witness program: scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215 witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac 0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG - + The second input comes from a native P2WSH witness program: scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215 witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac 1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG - + To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY): - + nVersion: 01000000 hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 @@ -357,7 +357,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an hashOutputs: (see below) nLockTime: 00000000 nHashType: 83000000 - + outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000 scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac (since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode) @@ -367,7 +367,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98 private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d signature: 3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 - + outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000 scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) @@ -377,7 +377,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98 private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d signature: 30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 - + The serialized signed transaction is: 01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 nVersion: 01000000 @@ -390,7 +390,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an witness 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac nLockTime: 00000000 - + Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped: 0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 nVersion: 01000000 @@ -408,37 +408,37 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different <code>SIGHASH</code> types. - - + + The following is an unsigned transaction: 010000000136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000000ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac00000000 - + nVersion: 01000000 txin: 01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff txout: 02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac nLockTime: 00000000 - + The input comes from a P2SH-P2WSH 6-of-6 multisig witness program: scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321 redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54 witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae - + hashPrevouts: dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000) = 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 - + hashSequence: dSHA256(ffffffff) = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 - + hashOutputs for ALL: dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac) = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc - + hashOutputs for SINGLE: dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac) = 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708 - + hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000 nVersion: 01000000 hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 @@ -454,7 +454,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe public key: 0307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba3 private key: 730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6 signature: 304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01 - + hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000 nVersion: 01000000 hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 @@ -470,7 +470,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe public key: 03b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b private key: 11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3 signature: 3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502 - + hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000 nVersion: 01000000 hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 @@ -486,7 +486,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe public key: 034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a private key: 77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661 signature: 3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403 - + hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000 nVersion: 01000000 hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 @@ -502,7 +502,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe public key: 033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f4 private key: 14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49 signature: 3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381 - + hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000 nVersion: 01000000 hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 @@ -518,7 +518,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe public key: 03a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac16 private key: fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323 signature: 3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882 - + hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000 nVersion: 01000000 hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 @@ -534,7 +534,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe public key: 02d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b private key: 428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890 signature: 30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783 - + The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000 @@ -542,35 +542,35 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe These examples show that <code>FindAndDelete</code> for the signature is not applied. The transactions are generated in an unconventional way. Instead of signing using a private key, the signatures are pre-determined as part of <code>witnessScript</code>. The public keys are generated with key recovery, using the fixed signatures and the <code>sighash</code> defined in this proposal. Therefore, the private keys are unknown. - + The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000 - + nVersion: 01000000 txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff txout: 01 0100000000000000 00 nLockTime: 00000000 - + The input comes from a P2WSH witness program: scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000 redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 - + To sign it with a nHashType of 1 (SIGHASH_ALL): - + hashPrevouts: dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000) = b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f - + hashSequence: dSHA256(ffffffff) = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 - + hashOutputs: dSHA256(010000000000000000) = e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228 - + hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000 - + nVersion: 01000000 hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 @@ -581,11 +581,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app hashOutputs: e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228 nLockTime: 00000000 nHashType: 01000000 - + sigHash: 71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23 signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01 pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c - + The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000 nVersion: 01000000 @@ -597,11 +597,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app 2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c 4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 nLockTime: 00000000 - - + + The following transaction is a <code>OP_CHECKMULTISIGVERIFY</code> version of the <code>FindAndDelete</code> examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000 - + redeemScript: OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601> hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000 sighash: c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72 @@ -618,7 +618,7 @@ The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BI == Deployment == -This proposal is deployed with Segregated Witness softfork (BIP 141) +This proposal is deployed with Segregated Witness softfork (BIP 141) == Backward compatibility == diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 8ec2191..56e075a 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -79,7 +79,7 @@ The serialization has the following structure: Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output. -If the witness is empty, the old serialization format must be used. +If the witness is empty, the old serialization format must be used. Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. diff --git a/bip-0150.mediawiki b/bip-0150.mediawiki index 277341d..bddc2e1 100644 --- a/bip-0150.mediawiki +++ b/bip-0150.mediawiki @@ -5,7 +5,7 @@ Author: Jonas Schnelli <dev@jonasschnelli.ch> Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0150 - Status: Draft + Status: Deferred Type: Standards Track Created: 2016-03-23 License: PD diff --git a/bip-0154.mediawiki b/bip-0154.mediawiki index c1e4cdb..cf8f956 100644 --- a/bip-0154.mediawiki +++ b/bip-0154.mediawiki @@ -71,7 +71,7 @@ solve the challenge and reconnect, or discard it and find a different peer (or w There are two POW identifiers currently. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should -retain its place in the list indefinitely. +retain its place in the list indefinitely. {|class="wikitable" ! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status @@ -173,7 +173,7 @@ Additional notes: There is only one Purpose Identifier currently. In the future, more Purpose Identifiers could be added for at-DoS-risk operations, such as bloom filters. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should retain its place in -the list indefinitely. +the list indefinitely. {|class="wikitable" ! ID !! Purpose Name !! Description !! Status @@ -236,7 +236,7 @@ Normally mid-layer (all but the last) POW algorithms have a zero-length input. E |- | 1..4 || pow-id || 1 || sha256 |- -| 5 || pow-params (config_length) || 9 || +| 5 || pow-params (config_length) || 9 || |- | 6..9 || pow-params (target) || 0x207fffff || Resulting hash must be <= the compact hash 0x207fffff* |- @@ -248,7 +248,7 @@ Normally mid-layer (all but the last) POW algorithms have a zero-length input. E |- | 19..22 || pow-id || 2 || cuckoo-cycle |- -| 23 || pow-params (config_length) || 8 || +| 23 || pow-params (config_length) || 8 || |- | 24 || pow-params (sizeshift) || 28 |- diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki index 0ec6801..bef289a 100644 --- a/bip-0155.mediawiki +++ b/bip-0155.mediawiki @@ -44,7 +44,7 @@ interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RF The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>. It is serialized in the standard encoding for P2P messages. -Its format is similar to the current <code>addr</code> message format, with the difference that the +Its format is similar to the current <code>addr</code> message format, with the difference that the fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. This means that the message contains a serialized <code>std::vector</code> of the following structure: diff --git a/bip-0156.mediawiki b/bip-0156.mediawiki index dcfed1f..3fa486a 100644 --- a/bip-0156.mediawiki +++ b/bip-0156.mediawiki @@ -109,7 +109,7 @@ Figure 3 To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is assigned a particular Dandelion destination. Each Dandelion transaction that -arrives via this peer is forwarded to the same Dandelion destination. +arrives via this peer is forwarded to the same Dandelion destination. Per-inbound-edge routing breaks the described attack by blocking an adversary's ability to construct useful fingerprints. Fingerprints arise when routing decisions are made independently per transaction at each node. In this case, two diff --git a/bip-0158/gentestvectors.go b/bip-0158/gentestvectors.go index e51b984..2d11b14 100644 --- a/bip-0158/gentestvectors.go +++ b/bip-0158/gentestvectors.go @@ -37,7 +37,7 @@ var ( {49291, "Tx pays to empty output script"}, {180480, "Tx spends from empty output script"}, {926485, "Duplicate pushdata 913bcc2be49cb534c20474c4dee1e9c4c317e7eb"}, - {987876, "Coinbase tx has unparseable output script"}, + {987876, "Coinbase tx has unparsable output script"}, {1263442, "Includes witness data"}, {1414221, "Empty data"}, } diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index 0226692..a659e72 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -5,7 +5,7 @@ Author: Jonas Schnelli <dev@jonasschnelli.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159 - Status: Draft + Status: Final Type: Standards Track Created: 2017-05-11 License: BSD-2-Clause @@ -50,7 +50,7 @@ Pruned peers following this BIP may consume more outbound bandwidth. Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option. -== Compatibility == +== Compatibility == This proposal is backward compatible. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 95a5573..8509f97 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -483,6 +483,52 @@ The currently defined per-input types are defined as follows: | 0, 2 | [[bip-0371.mediawiki|371]] |- +| MuSig2 Participant Public Keys +| <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt> +| <33 byte plain aggregate pubkey> +| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not +be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the +script were derived. +| <tt><33 byte compressed pubkey>*</tt> +| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order +required for aggregation. If sorting was done, then the keys must be in the sorted order. +| +| +| 0, 2 +| [[bip-0373.mediawiki|373]] +|- +| MuSig2 Public Nonce +| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt> +| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt> +| The compressed public key of the participant providing this nonce, followed by the plain public +key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of +the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the +taproot output key, then the tapleaf hash must be omitted. The plain public key must be +the key found in the script and not the aggregate public key that it was derived from, if it was +derived from an aggregate key. +| <tt><66 byte public nonce></tt> +| The public nonce produced by the <tt>NonceGen</tt> algorithm. +| +| +| 0, 2 +| [[bip-0373.mediawiki|373]] +|- +| MuSig2 Participant Partial Signature +| <tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt> +| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt> +| The compressed public key of the participant providing this partial signature, followed by the +plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash +of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or +the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must +be the key found in the script and not the aggregate public key that it was derived from, if it was +derived from an aggregate key. +| <tt><32 byte partial signature></tt> +| The partial signature produced by the <tt>Sign</tt> algorithm. +| +| +| 0, 2 +| [[bip-0373.mediawiki|373]] +|- | Proprietary Use Type | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> | <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> @@ -599,6 +645,20 @@ determine which outputs are change outputs and verify that the change is returni | 0, 2 | [[bip-0371.mediawiki|371]] |- +| MuSig2 Participant Public Keys +| <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt> +| <33 byte plain aggregate pubkey> +| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not +be in the script directly. It may instead be a parent public key from which the public keys in the +script were derived. +| <tt><33 byte compressed pubkey>*</tt> +| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order +required for aggregation. If sorting was done, then the keys must be in the sorted order. +| +| +| 0, 2 +| [[bip-0373.mediawiki|373]] +|- | Proprietary Use Type | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> | <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt> @@ -821,7 +881,7 @@ If a field requires significant description as to its usage, it should be accomp The field must be added to the field listing tables in the Specification section. Although some PSBT version 0 implementations encode types as uint8_t rather than compact size, it is still safe to add >0xFD fields to PSBT 0, because these old parsers ignore -unknown fields, and <keytype> is prefixed by its length. +unknown fields, and <keytype> is prefixed by its length. ===Procedure For New Versions=== diff --git a/bip-0176.mediawiki b/bip-0176.mediawiki index 2f5ee9f..bfce9a2 100644 --- a/bip-0176.mediawiki +++ b/bip-0176.mediawiki @@ -48,7 +48,7 @@ The term "bit" has many different definitions, but the ones of particular note a * bit meaning some amount of data (e.g., the first bit of the version field is 0) * bit meaning strength of a cryptographic algorithm (e.g., 256-bit ECDSA is used in Bitcoin) -The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means. +The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means. == Copyright == This BIP is licensed under the BSD 2-clause license. diff --git a/bip-0199.mediawiki b/bip-0199.mediawiki index e463c7f..04a1d0a 100644 --- a/bip-0199.mediawiki +++ b/bip-0199.mediawiki @@ -19,13 +19,13 @@ This BIP describes a script for generalized off-chain contract negotiation. ==Summary== -A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits +A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation. The script takes the following form: OP_IF - [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> + [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> OP_ELSE <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> OP_ENDIF @@ -44,28 +44,28 @@ The script takes the following form: ** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR ** Victor recovers the funds after the timeout threshold. -Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is -interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does +Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is +interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does not enter the blockchain before Victor's but does reveal the preimage to Victor anyway. ==Motivation== -In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are -a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the +In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are +a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the opportunity that the possessor of a secret has to receive the funds before such a refund can occur. ===Lightning network=== In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. -Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and -amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If +Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and +amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If at any point some parties become uncooperative, the process can be aborted via the refund conditions. ===Zero-knowledge contingent payments=== -Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a -zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See +Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a +zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See [https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.) HTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions. diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki index e5048e7..fb2070a 100644 --- a/bip-0300.mediawiki +++ b/bip-0300.mediawiki @@ -213,7 +213,7 @@ M2 is invalid if: * An M2 is already in this block. * It tries to ACK two different M1s for the same slot. -Otherwise: +Otherwise: * The sidechain is "ACK"ed and does NOT get a "fail" for this block. (As it otherwise would.) @@ -242,7 +242,7 @@ Sidechain withdrawals take the form of "Bundles" -- named because they "bundle u Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle. -This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course). +This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course). A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out). @@ -283,7 +283,7 @@ M4 is a coinbase OP Return output containing the following: 1-byte - Version n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain. -The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted". +The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted". For example: if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003]. @@ -313,7 +313,7 @@ Important: Within a sidechain-group, upvoting one Bundle ("+1") automatically do For example: -{| class="wikitable" +{| class="wikitable" |- ! SC# ! Bundle Hash @@ -350,7 +350,7 @@ For example: ...in block 900,000 could become... -{| class="wikitable" +{| class="wikitable" |- ! SC# ! Bundle Hash @@ -414,7 +414,7 @@ M6 is invalid if: * The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point. * There are additional OP_DRIVECHAIN outputs after the first one. -Else, M6 is valid. +Else, M6 is valid. (The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.) @@ -485,7 +485,7 @@ As a soft fork, older software will continue to operate without modification. No ==Deployment== -This BIP will be deployed via UASF-style block height activation. Block height TBD. +This BIP will be deployed via UASF-style block height activation. Block height TBD. ==Reference Implementation== diff --git a/bip-0301.mediawiki b/bip-0301.mediawiki index e1522f8..dc3eb15 100644 --- a/bip-0301.mediawiki +++ b/bip-0301.mediawiki @@ -78,7 +78,7 @@ Bip301 makes this specialization-of-labor trustless on layer1. If Mary takes Sim ==Specification== -Bip300 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*". +Bip301 consists of two messages: "BMM Accept" and "BMM Request". These govern something called "h*". So we will discuss: @@ -89,7 +89,7 @@ So we will discuss: === h* === -h* ("h star") is the sidechain's Merkle Root hash. +h* ("h star") is the sidechain's Merkle Root hash. In Bip301, a sidechain's coinbase txn acts as a header (it contains the hash of the previous side:block, and previous main:block). Thus, the MerkleRoot contains everything important. diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 911d3c8..81ef896 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -174,8 +174,8 @@ Given below parameters: Produce signatures: -* Message = "" (empty string): <code>AkcwRAIgM2gBAQqvZX15ZiysmKmQpDrG83avLIT492QBzLnQIxYCIBaTpOaD20qRlEylyxFSeEA2ba9YOixpX8z46TSDtS40ASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code> -* Message = "Hello World": <code>AkcwRAIgZRfIY3p7/DoVTty6YZbWS71bc5Vct9p9Fia83eRmw2QCICK/ENGfwLtptFluMGs2KsqoNSk89pO7F29zJLUx9a/sASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code> +* Message = "" (empty string): <code>AkcwRAIgM2gBAQqvZX15ZiysmKmQpDrG83avLIT492QBzLnQIxYCIBaTpOaD20qRlEylyxFSeEA2ba9YOixpX8z46TSDtS40ASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code> or <code>AkgwRQIhAPkJ1Q4oYS0htvyuSFHLxRQpFAY56b70UvE7Dxazen0ZAiAtZfFz1S6T6I23MWI2lK/pcNTWncuyL8UL+oMdydVgzAEhAsfxIAMZZEKUPYWI4BruhAQjzFT8FSFSajuFwrDL1Yhy</code> +* Message = "Hello World": <code>AkcwRAIgZRfIY3p7/DoVTty6YZbWS71bc5Vct9p9Fia83eRmw2QCICK/ENGfwLtptFluMGs2KsqoNSk89pO7F29zJLUx9a/sASECx/EgAxlkQpQ9hYjgGu6EBCPMVPwVIVJqO4XCsMvViHI=</code> or <code>AkgwRQIhAOzyynlqt93lOKJr+wmmxIens//zPzl9tqIOua93wO6MAiBi5n5EyAcPScOjf1lAqIUIQtr3zKNeavYabHyR8eGhowEhAsfxIAMZZEKUPYWI4BruhAQjzFT8FSFSajuFwrDL1Yhy</code> === Transaction Hashes === diff --git a/bip-0324.mediawiki b/bip-0324.mediawiki index 8050b15..941d96e 100644 --- a/bip-0324.mediawiki +++ b/bip-0324.mediawiki @@ -7,7 +7,7 @@ Jonas Schnelli <dev@jonasschnelli.ch> Pieter Wuille <bitcoin-dev@wuille.net> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0324 - Status: Draft + Status: Final Type: Standards Track Created: 2019-03-08 License: BSD-3-Clause @@ -384,7 +384,7 @@ def complete_handshake(peer, initiating, decoy_content_lengths=[]): if received_garbage[-16:] == peer.recv_garbage_terminator: # Receive, decode, and ignore version packet. # This includes skipping decoys and authenticating the received garbage. - v2_receive_packet(peer, aad=received_garbage) + v2_receive_packet(peer, aad=received_garbage[:-16]) return else: received_garbage += recv(peer, 1) diff --git a/bip-0327.mediawiki b/bip-0327.mediawiki index 4815f40..c9e88ab 100644 --- a/bip-0327.mediawiki +++ b/bip-0327.mediawiki @@ -190,9 +190,6 @@ The aggregate public key can be ''tweaked'', which modifies the key as defined i In order to apply a tweak, the KeyAgg Context output by ''KeyAgg'' is provided to the ''ApplyTweak'' algorithm with the ''is_xonly_t'' argument set to false for plain tweaking and true for X-only tweaking. The resulting KeyAgg Context can be used to apply another tweak with ''ApplyTweak'' or obtain the aggregate public key with ''GetXonlyPubkey'' or ''GetPlainPubkey''. -In addition to individual public keys, the ''KeyAgg'' algorithm accepts tweaks, which modify the aggregate public key as defined in the [[#tweaking-definition|Tweaking Definition]] subsection. -For example, if ''KeyAgg'' is run with ''v = 2'', ''is_xonly_t<sub>1</sub> = false'', ''is_xonly_t<sub>2</sub> = true'', then the aggregate key is first plain tweaked with ''tweak<sub>1</sub>'' and then X-only tweaked with ''tweak<sub>2</sub>''. - The purpose of supporting tweaking is to ensure compatibility with existing uses of tweaking, i.e., that the result of signing is a valid signature for the tweaked public key. The MuSig2 algorithms take arbitrary tweaks as input but accepting arbitrary tweaks may negatively affect the security of the scheme.<ref>It is an open question whether allowing arbitrary tweaks from an adversary affects the unforgeability of MuSig2.</ref> Instead, signers should obtain the tweaks according to other specifications. @@ -554,7 +551,7 @@ influence whether ''sk<sub>1</sub>'' or ''sk<sub>2</sub>'' is provided to ''Sign This degree of freedom may allow the adversary to perform a generalized birthday attack and thereby forge a signature (see [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021000.html bitcoin-dev mailing list post] and [https://github.com/jonasnick/musig2-tweaking writeup] for details). -Checking ''pk'' against ''InvidualPubkey(sk)'' is a simple way to ensure +Checking ''pk'' against ''IndividualPubkey(sk)'' is a simple way to ensure that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked. This removes the adversary's ability to influence the secret key after having seen the ''pubnonce'' and thus rules out the attack.<ref>Ensuring that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked is a simple policy to rule out the attack, @@ -622,7 +619,7 @@ Algorithm ''DeterministicSign(sk, aggothernonce, pk<sub>1..u</sub>, tweak<sub>1. * Let ''keyagg_ctx<sub>0</sub> = KeyAgg(pk<sub>1..u</sub>)''; fail if that fails * For ''i = 1 .. v'': ** Let ''keyagg_ctx<sub>i</sub> = ApplyTweak(keyagg_ctx<sub>i-1</sub>, tweak<sub>i</sub>, is_xonly_t<sub>i</sub>)''; fail if that fails -* Let ''aggpk = GetPubkey(keyagg_ctx<sub>v</sub>)'' +* Let ''aggpk = GetXonlyPubkey(keyagg_ctx<sub>v</sub>)'' * Let ''k<sub>i</sub> = int(hash<sub>MuSig/deterministic/nonce</sub>(sk' || aggothernonce || aggpk || bytes(8, len(m)) || m || bytes(1, i - 1))) mod n'' for ''i = 1,2'' * Fail if ''k<sub>1</sub> = 0'' or ''k<sub>2</sub> = 0'' * Let ''R<sub>⁎,1</sub> = k<sub>1</sub>⋅G, R<sub>⁎,2</sub> = k<sub>2</sub>⋅G'' @@ -785,6 +782,8 @@ An exception to this rule is <code>MAJOR</code> version zero (0.y.z) which is fo The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added. The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.). +* '''1.0.2''' (2024-07-22): +** Fix minor bug in the specification of ''DeterministicSign'' and add small improvement to a ''PartialSigAgg'' test vector. * '''1.0.1''' (2024-05-14): ** Fix minor issue in ''PartialSigVerify'' vectors. * '''1.0.0''' (2023-03-26): @@ -828,4 +827,4 @@ The <code>PATCH</code> version is incremented for other changes that are notewor == Acknowledgements == -We thank Brandon Black, Riccardo Casatta, Lloyd Fournier, Russell O'Connor, and Pieter Wuille for their contributions to this document. +We thank Brandon Black, Riccardo Casatta, Sivaram Dhakshinamoorthy, Lloyd Fournier, Russell O'Connor, and Pieter Wuille for their contributions to this document. diff --git a/bip-0327/gen_vectors_helper.py b/bip-0327/gen_vectors_helper.py index a70bb6f..03c2dbb 100644 --- a/bip-0327/gen_vectors_helper.py +++ b/bip-0327/gen_vectors_helper.py @@ -153,7 +153,8 @@ def sig_agg_vectors(): "psig_indices": [7, 8], "error": { "type": "invalid_contribution", - "signer": 1 + "signer": 1, + "contrib": "psig", }, "comment": "Partial signature is invalid because it exceeds group size" } diff --git a/bip-0327/reference.py b/bip-0327/reference.py index edf6e76..17831c5 100644 --- a/bip-0327/reference.py +++ b/bip-0327/reference.py @@ -317,7 +317,7 @@ SessionContext = NamedTuple('SessionContext', [('aggnonce', bytes), ('is_xonly', List[bool]), ('msg', bytes)]) -def key_agg_and_tweak(pubkeys: List[PlainPk], tweaks: List[bytes], is_xonly: List[bool]): +def key_agg_and_tweak(pubkeys: List[PlainPk], tweaks: List[bytes], is_xonly: List[bool]) -> KeyAggContext: if len(tweaks) != len(is_xonly): raise ValueError('The `tweaks` and `is_xonly` arrays must have the same length.') keyagg_ctx = key_agg(pubkeys) @@ -440,8 +440,6 @@ def partial_sig_verify_internal(psig: bytes, pubnonce: bytes, pk: bytes, session Re_s_ = point_add(R_s1, point_mul(R_s2, b)) Re_s = Re_s_ if has_even_y(R) else point_negate(Re_s_) P = cpoint(pk) - if P is None: - return False a = get_session_key_agg_coeff(session_ctx, P) g = 1 if has_even_y(Q) else n - 1 g_ = g * gacc % n @@ -523,7 +521,7 @@ def test_key_agg_vectors() -> None: assert get_xonly_pk(key_agg(pubkeys)) == expected - for i, test_case in enumerate(error_test_cases): + for test_case in error_test_cases: exception, except_fn = get_error_details(test_case) pubkeys = [X[i] for i in test_case["key_indices"]] @@ -572,7 +570,7 @@ def test_nonce_agg_vectors() -> None: expected = bytes.fromhex(test_case["expected"]) assert nonce_agg(pubnonces) == expected - for i, test_case in enumerate(error_test_cases): + for test_case in error_test_cases: exception, except_fn = get_error_details(test_case) pubnonces = [pnonce[i] for i in test_case["pnonce_indices"]] assert_raises(exception, lambda: nonce_agg(pubnonces), except_fn) @@ -598,7 +596,10 @@ def test_sign_verify_vectors() -> None: aggnonces = fromhex_all(test_data["aggnonces"]) # The aggregate of the first three elements of pnonce is at index 0 - assert(aggnonces[0] == nonce_agg([pnonce[0], pnonce[1], pnonce[2]])) + assert (aggnonces[0] == nonce_agg([pnonce[0], pnonce[1], pnonce[2]])) + # The aggregate of the first and fourth elements of pnonce is at index 1, + # which is the infinity point encoded as a zeroed 33-byte array + assert (aggnonces[1] == nonce_agg([pnonce[0], pnonce[3]])) msgs = fromhex_all(test_data["msgs"]) @@ -626,7 +627,7 @@ def test_sign_verify_vectors() -> None: assert sign(secnonce_tmp, sk, session_ctx) == expected assert partial_sig_verify(expected, pubnonces, pubkeys, [], [], msg, signer_index) - for i, test_case in enumerate(sign_error_test_cases): + for test_case in sign_error_test_cases: exception, except_fn = get_error_details(test_case) pubkeys = [X[i] for i in test_case["key_indices"]] @@ -646,7 +647,7 @@ def test_sign_verify_vectors() -> None: assert not partial_sig_verify(sig, pubnonces, pubkeys, [], [], msg, signer_index) - for i, test_case in enumerate(verify_error_test_cases): + for test_case in verify_error_test_cases: exception, except_fn = get_error_details(test_case) sig = bytes.fromhex(test_case["sig"]) @@ -702,7 +703,7 @@ def test_tweak_vectors() -> None: assert sign(secnonce_tmp, sk, session_ctx) == expected assert partial_sig_verify(expected, pubnonces, pubkeys, tweaks, is_xonly, msg, signer_index) - for i, test_case in enumerate(error_test_cases): + for test_case in error_test_cases: exception, except_fn = get_error_details(test_case) pubkeys = [X[i] for i in test_case["key_indices"]] @@ -747,7 +748,7 @@ def test_det_sign_vectors() -> None: session_ctx = SessionContext(aggnonce, pubkeys, tweaks, is_xonly, msg) assert partial_sig_verify_internal(psig, pubnonce, pubkeys[signer_index], session_ctx) - for i, test_case in enumerate(error_test_cases): + for test_case in error_test_cases: exception, except_fn = get_error_details(test_case) pubkeys = [X[i] for i in test_case["key_indices"]] @@ -796,7 +797,7 @@ def test_sig_agg_vectors() -> None: aggpk = get_xonly_pk(key_agg_and_tweak(pubkeys, tweaks, is_xonly)) assert schnorr_verify(msg, aggpk, sig) - for i, test_case in enumerate(error_test_cases): + for test_case in error_test_cases: exception, except_fn = get_error_details(test_case) pubnonces = [pnonce[i] for i in test_case["nonce_indices"]] diff --git a/bip-0327/vectors/sig_agg_vectors.json b/bip-0327/vectors/sig_agg_vectors.json index 04a7bc6..519562c 100644 --- a/bip-0327/vectors/sig_agg_vectors.json +++ b/bip-0327/vectors/sig_agg_vectors.json @@ -143,7 +143,8 @@ ], "error": { "type": "invalid_contribution", - "signer": 1 + "signer": 1, + "contrib": "psig" }, "comment": "Partial signature is invalid because it exceeds group size" } diff --git a/bip-0328.mediawiki b/bip-0328.mediawiki new file mode 100644 index 0000000..3c07dab --- /dev/null +++ b/bip-0328.mediawiki @@ -0,0 +1,80 @@ +<pre> + BIP: 328 + Layer: Applications + Title: Derivation Scheme for MuSig2 Aggregate Keys + Author: Ava Chow <me@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0328 + Status: Draft + Type: Informational + Created: 2024-01-15 + License: CC0-1.0 +</pre> + +==Abstract== + +This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2 +aggregate public key and how such keys should be used for key derivation. + +==Copyright== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +==Motivation== + +Multiple signers can create a single aggregate public key with MuSig2 that is indistinguishable +from a random public key. The cosigners need a method for generating additional aggregate pubkeys +to follow the best practice of using a new address for every payment. + +The obvious method is for the cosigners to generate multiple public keys and produce a +new aggregate pubkey every time one is needed. This is similar to how multisig using Bitcoin script +works where all of the cosigners share their extended public keys and do derivation to produce +the multisig script. The same could be done with MuSig2 and instead of producing a multisig script, +the result would be a MuSig2 aggregate pubkey. + +However, it is much simpler to be able to derive from a single extended public key instead of having +to derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking +public key, the aggregate public can be used in this way. This reduces the storage and computation +requirements for generating new aggregate pubkeys. + +==Specification== + +A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting +the depth to 0, the child number to 0, and attaching a chaincode with the byte string +<tt>868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965</tt><ref>'''Where does this +constant chaincode come from?''' It is the SHA256 of the text <tt>MuSig2MuSig2MuSig2</tt></ref>. +This fixed chaincode should be used by all such synthetic xpubs following this specification. +Unhardened child public keys can be derived from the synthetic xpub as with any other xpub. Since +the aggregate public key is all that is necessary to produce the synthetic xpub, any aggregate +public key that will be used in this way shares the same privacy concerns as typical xpubs. + +Furthermore, as there is no aggregate private key, only unhardened derivation from the aggregate +public key is possible. + +When signing, all signers must compute the tweaks used in the BIP 32 derivation for the child key +being signed for. The I<sub>L</sub> value computed in ''CKDpub'' is the tweak used at each +derivation step. These are provided in the session context, each with a tweak mode of plain +(''is_xonly_t = false''). When the ''Sign'' algorithm is used, the tweaks will be applied to the +partial signatures. + +==Test Vectors== + +TBD + +==Backwards Compatibility== + +Once a synthetic xpub is created, it is fully backwards compatible with BIP 32 - only unhardened +derivation can be done, and the signers will be able to produce a signature for any derived children. + +==Rationale== + +<references/> + +==Reference Implementation== + +TBD + +==Acknowledgements== + +Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who +participated in discussions on this topic. diff --git a/bip-0329.mediawiki b/bip-0329.mediawiki index fc5da42..13b332b 100644 --- a/bip-0329.mediawiki +++ b/bip-0329.mediawiki @@ -39,8 +39,8 @@ The Electrum wallet imports and exports address and transaction labels in a JSON ==Specification== -In order to be lightweight, human readable and well structured, this BIP uses a JSON format. -Further, the JSON Lines format is used (also called newline-delimited JSON)<ref>[https://jsonlines.org/ jsonlines.org]</ref>. +In order to be lightweight, human readable and well structured, this BIP uses a JSON format. +Further, the JSON Lines format is used (also called newline-delimited JSON)<ref>[https://jsonlines.org/ jsonlines.org]</ref>. This allows a document to be split, streamed, or incrementally added to, and limits the potential for formatting errors to invalidate an entire import. It is also a convenient format for command-line processing, which is often line-oriented. @@ -48,7 +48,7 @@ Further to the JSON Lines specification, an export of labels from a wallet must Lines are separated by <tt>\n</tt>. Multiline values are not permitted. Each JSON object must contain 3 or 4 key/value pairs, defined as follows: -{| class="wikitable" +{| class="wikitable" |- ! Key ! Description @@ -71,7 +71,7 @@ Each JSON object must contain 3 or 4 key/value pairs, defined as follows: The reference is defined for each <tt>type</tt> as follows: -{| class="wikitable" +{| class="wikitable" |- ! Type ! Description @@ -107,7 +107,7 @@ Each JSON object must contain both <tt>type</tt> and <tt>ref</tt> properties. Th If present, the optional <tt>origin</tt> property must contain an abbreviated output descriptor (as defined by BIP380<ref>[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]</ref>) describing a BIP32 compatible originating wallet, including all key origin information but excluding any actual keys, any child path elements, or a checksum. This property should be used to disambiguate transaction labels from different wallets contained in the same export, particularly when exporting multiple accounts derived from the same seed. -Care should be taken when exporting due to the privacy sensitive nature of the data. +Care should be taken when exporting due to the privacy sensitive nature of the data. Encryption in transit over untrusted networks is highly recommended, and encryption at rest should also be considered. Unencrypted exports should be deleted as soon as possible. For security reasons no private key types are defined. @@ -120,7 +120,7 @@ For security reasons no private key types are defined. ==Backwards Compatibility== -The nature of this format makes it naturally extensible to handle other record types. +The nature of this format makes it naturally extensible to handle other record types. However, importing wallets complying to this specification may ignore types not defined here. ==Test Vectors== diff --git a/bip-0337.mediawiki b/bip-0337.mediawiki new file mode 100644 index 0000000..e87c5bc --- /dev/null +++ b/bip-0337.mediawiki @@ -0,0 +1,301 @@ +<pre> + BIP: 337 + Layer: API/RPC + Title: Compressed Transactions + Author: Tom Briar <tombriar11@protonmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0337 + Status: Draft + Type: Standards Track + Created: 2024-02-01 + License: BSD-3-Clause + Post-History: https://github.com/bitcoin/bitcoin/pull/29134 + https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html +</pre> + +== Introduction == + +=== Abstract === +This document proposes a serialization scheme for compressing Bitcoin transactions. The compressed Bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One method for compressing involves reducing the transaction outpoints in a potentially lossy way. Therefore, it is an optional path for compression. Compressing the outpoints is necessary for compressed transactions to reach less than 70% of the original size. + +=== Motivation === +Typical Bitcoin transactions usually contain a large amount of white space and padding due to specific fields that are often one of a minimal number of possibilities. We can use this fact and a few similar methods to create an encoding for 90% of Bitcoin transactions that are roughly 25-50% smaller. + +There exists a working-in-progress app that allows the use of steganography to encode data in images to be passed around via various social media groups. When used in conjunction with this compression scheme and an elligator squared encryption, this would allow for a very secure and private form of broadcasting bitcoin transactions. + +=== Rationale === + +The four main methods to achieve a lower transaction size are: + +1. Packing transaction metadata before it and each of its inputs and outputs to determine the following data structure. + +2. Replacing 32-bit numeric values with either variable-length integers (VarInts) or compact integers (CompactSizes). + +3. Using compressed signatures and public key recovery upon decompression. + +4. Replacing the 36-byte Outpoint txid/vout pair with a block height and index. + + +=== Backwards Compatibility === + +There are no concerns with backwards compatibility. + +=== Specification === + +==== Primitives ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| CompactSize || 1-5 Bytes || For 0-253, encode the value directly in one byte. For 254-65535, encode 254 followed by two little-endian bytes. For 65536-(2^32-1), encode 255 followed by four little-endian bytes. +|- +| CompactSize Flag || 2 Bits || 1, 2, or 3 indicate literal values. 0 indicates that a CompactSize encoding of the value will follow. +|- +| VarInt || 1+ Bytes || 7-bit little-endian encoding, with each 7-bit word encoded in a byte. The highest bit of each byte is one if more bytes follow, and 0 for the last byte. +|- +| VLP-Bytestream || 2+ Bytes || A VarInt Length Prefixed Bytestream. It uses the prefixed VarInt to determine the length of the following byte stream. +|} + +==== General Schema ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Transaction metadata || 1 Bytes || Information on the structure of the transaction. See [[#transaction-metadata|Transaction Metadata]] +|- +| Version || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction version. +|- +| Input Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction input count. +|- +| Output Count || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction output count. +|- +| LockTime || 0-5 Bytes || If present according to the metadata field, a CompactSize encoding of the transaction LockTime. +|- +| Minimum Blockheight || 1-5 Bytes || If present according to the metadata field, a VarInt encoding of the minimum block height for transaction compressed inputs and LockTime. +|- +| Input Metadata+Output Metadata || 1+ Bytes || An encoding containing the metadata for all the inputs followed by all the outputs of the transaction. For each input, see [[#input-metadata|Input Metadata]], and for each output, see [[#output-metadata|Output Metadata]]. +|- +| Input Data || 66+ Bytes || See [[#input-data|Input Data]]. +|- +| Output Data || 3+ Bytes || See [[#output-data|Output Data]]. +|} + +<span id="transaction-metadata"></span> +==== Transaction Metadata ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Version || 2 Bits || A CompactSize flag for the transaction version. +|- +| Input Count || 2 Bits || A CompactSize flag for the transaction input count. +|- +| Output Count || 2 Bits || A CompactSize flag for the transaction output count. +|- +| LockTime || 1 Bit || A boolean to indicate if the transaction has a LockTime. +|- +| Minimum Blockheight || 1 Bit || A boolean to indicate if the transaction minimum block height is greater than zero. +|} + +<span id="input-metadata"></span> +==== Input Metadata ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Compressed Signature || 1 Bit || A Boolean do determine if this input's signature is compressed. The signature is only compressed for P2TR on a key spend and for P2SH when it is a wrapped P2SH-WPKH. +|- +| Standard Hash || 1 Bit || A Boolean to determine if this input's signature hash type is standard (0x00 for Taproot, 0x01 for Legacy/Segwit). +|- +| Standard Sequence || 2 Bits || A CompactSize flag for this input's sequence. Encode literal values as follows: 1 = 0x00000000, 2 = 0xFFFFFFFE, 3 = 0xFFFFFFFF. +|- +| Compressed OutPoint || 1 bit || A Boolean to determine if the input's outpoint is compressed. +|} + +<span id="output-metadata"></span> +==== Output Metadata ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Encoded Script Type || 3 Bits || [[#script-type-encoding|Encoded Script Type]]. +|} + +<span id="script-type-encoding"></span> +==== Script Type Encoding ==== + +{| class="wikitable" style="margin:auto" +|- +! Script Type !! Value +|- +| Uncompressed Custom Script || 0b000 +|- +| Uncompressed P2PK || 0b001 +|- +| Compressed P2PK || 0b010 +|- +| P2PKH || 0b011 +|- +| P2SH || 0b100 +|- +| P2WPKH || 0b101 +|- +| P2WSH || 0b110 +|- +| P2TR || 0b111 +|} + +<span id="input-data"></span> +==== Input Data ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Outpoint || 2-37 Bytes || The Outpoint Txid/Vout are determined to be compressed or otherwise by the "Compressed Outpoint" Boolean in the input metadata. For each compressed outpoint see [[#compressed-outpoint|Compressed Outpoint]]. For each uncompressed signature see [[#uncompressed-outpoint|Uncompressed Outpoint]]. +|- +| Signature || 64+ Bytes || The Signature is determined to be compressed or otherwise by the output script of the previous transaction. For each compressed signature see [[#compressed-signature|Compressed Signature]]. For each uncompressed signature see [[#uncompressed-signature|Uncompressed Signature]]. +|- +| Sequence || 0-5 Bytes || If present due to a non-standard sequence, a VarInt encoding of the sequence. +|} + +<span id="compressed-outpoint"></span> +==== Compressed Outpoint ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Txid Block Height || 1-5 Bytes || A VarInt containing the offset from Minimum Blockheight for this Txid. +|- +| Txid Block Index || 1-5 Bytes || A VarInt containing the flattened index from the Txid block height for the Vout. +|} + +<span id="uncompressed-outpoint"></span> +==== Uncompressed Outpoint ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Txid || 32 Bytes || Contains the 32 Byte Txid. +|- +| Vout || 1-5 Bytes || A CompactSize Containing the Vout of the Txid. +|} + + +<span id="compressed-signature"></span> +==== Compressed Signature ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Signature || 64 Bytes || Contains the 64 Byte signature. +|- +| Pubkey Hash || 0-20 Bytes || If input is P2SH-P2WPKH contains the 20 byte hash of the public key. +|- +| Hash Type || 0-1 Bytes || An Optional Byte containing the Hash Type if it was non-standard. +|} + +<span id="uncompressed-signature"></span> +==== Uncompressed Signature ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Signature || 2+ Bytes || A VLP-Bytestream containing the signature. +|} + +<span id="output-data"></span> +==== Output Data ==== + +{| class="wikitable" style="margin:auto" +|- +! Name !! Width !! Description +|- +| Output Script || 2+ Bytes || A VLP-Bytestream containing the output script. +|- +| Amount || 1-9 Bytes || A VarInt containing the output amount. +|} + +==== Ideal Transaction ==== + +The compression scheme was designed to be optimal for a "typical" transaction, spending a few close-in-age inputs and having one or two outputs. Here are size +values for such a transaction, which demonstrate the effectiveness of the compression. + +{| class="wikitable" style="margin:auto" +|- +! Field !! Requirements !! Savings Up To +|- +| Version || Less than four || 30 Bits +|- +| Input Count || Less than four || 30 Bits +|- +| Output Count || Less than four || 30 Bits +|- +| LockTime || 0 || 30 Bits +|- +| Input Sequence || 0x00, 0xFFFFFFFE, or 0xFFFFFFFF || 62 Bits For Each Input +|- +| Input Txid || Compressed Outpoint || 23 - 31 Bytes For Each Input +|- +| Input Vout || Compressed Outpoint || (-1) - 3 Bytes For Each Input +|- +| Input Signature || Non-custom Script Signing || 40 - 72 Bytes For Each Legacy Input +|- +| Input Hash Type || 0x00 for Taproot, 0x01 for Legacy || 7 Bits For Each Input +|- +| Output Script || Non-custom Scripts || 2 - 5 Bytes For Each Output +|- +| Output Amount || No Restrictions || (-1) - 7 Bytes For Each Output +|} + +=== Reference Implementation === + +This reference implementation adds two new RPC endpoints, compressrawtransaction and decompressrawtransaction. The first accepts a raw hex-encoded transaction and returns a compact hex-encoded transaction; also included in the output is a list of warnings to help ensure there are no unexpected uncompressed values. The second accepts a compact hex transaction and returns the uncompressed raw hex-encoded transaction. + +https://github.com/bitcoin/bitcoin/pull/29134 + +=== Test Vectors === + +==== Taproot ==== + +===== Uncompressed ===== +<code>020000000001017ad1d0cc314504ec06f1b5c786c50cf3cda30bd5be88cf08ead571b0ce7481fb0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226201408ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e500000000</code> + +===== Compressed ===== +<code>96b1ec7f968001b0218ce65b3170d3fbc68e3b6980650514dc53565f915d14351f83050ff50c8609495b7aa96271c3c99cdac1a92b1b45e77a4a870251fc1673596793adf2494565e58efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + +==== P2WPKH ==== + +===== Uncompressed ===== +<code>0200000000010144bcf05ab48b8789268a7ca07133241ad654c0739ac7165015b2d669eadb10ea0000000000fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022043ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa85022001c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe0121030072484c24705512bfb1f7f866d95f808d81d343e552bc418113e1b9a1da0eb400000000</code> + +===== Compressed ===== +<code>96b1ec71968001932643ab639a98dfbc704f16a35bf25b8b72acb4cb928fd772285f1fcf63725caa8501c9ff354504e7024708bce61f30370c8db13da8170cef4e8e4c4cdad0f71bfe8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + +==== P2SH-P2WPKH ==== + +===== Uncompressed ===== +<code>0200000000010192fb2e4332b43dc9a73febba67f3b7d97ba890673cb08efde2911330f77bbdfc00000000171600147a1979232206857167b401fdac1ffbf33f8204fffdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226202473044022041eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da90402205644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e8012103c483f1b1bd24dd23b3255a68d87ef9281f9d080fd707032ccb81c1cc56c5b00200000000</code> + +===== Compressed ===== +<code>96b1ec7c9e8001981641eb682e63c25b85a5a400b11d41cf4b9c25f309090a5f3e0b69dc15426da9045644ddc3d5179bab49cce4bf69ebfaeab1afa34331c1a0a70be2927d2836b0e87a1979232206857167b401fdac1ffbf33f8204ff8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + +==== P2PKH ==== + +===== Uncompressed ===== +<code>02000000015f5be26862482fe2fcc900f06ef26ee256fb205bc4773e5a402d0c1b88b82043000000006a473044022031a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d770220635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c0121027977f1b6357cead2df0a0a19570088a1eb9115468b2dfa01439493807d8f1294fdffffff0188130000000000001600142da377ed4978fefa043a58489912f8e28e16226200000000</code> + +===== Compressed ===== +<code>96b1ec7c968001981431a20f5d9212023b510599c9d53d082f8e07faaa2d51482e078f8e398cb50d77635abd99220ad713a081c4f20b83cb3f491ed8bd032cb151a3521ed144164d9c8efefefe7d2da377ed4978fefa043a58489912f8e28e162262a608</code> + + +== Acknowledgements == +Thank you to Andrew Poelstra, who helped invent and develop the ideas in the proposal and the code for reference implementation. diff --git a/bip-0338.mediawiki b/bip-0338.mediawiki index 65ab616..908aef6 100644 --- a/bip-0338.mediawiki +++ b/bip-0338.mediawiki @@ -5,7 +5,7 @@ Author: Suhas Daftuar <sdaftuar@chaincode.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2020-09-03 License: BSD-2-Clause diff --git a/bip-0339.mediawiki b/bip-0339.mediawiki index 806ba1c..7fb6bc4 100644 --- a/bip-0339.mediawiki +++ b/bip-0339.mediawiki @@ -5,7 +5,7 @@ Author: Suhas Daftuar <sdaftuar@chaincode.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339 - Status: Draft + Status: Final Type: Standards Track Created: 2020-02-03 License: BSD-2-Clause diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index 85b7bac..d26f8b4 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -58,7 +58,7 @@ encodings and operations. # Signatures are pairs ''(e, s)'' that satisfy ''e = hash(s⋅G - e⋅P || m)''. This variant avoids minor complexity introduced by the encoding of the point ''R'' in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing ''e'' instead of ''R'' allows for potentially shorter signatures: Whereas an encoding of ''R'' inherently needs about 32 bytes, the hash ''e'' can be tuned to be shorter than 32 bytes, and [http://www.neven.org/papers/schnorr.pdf a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits]. However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intend to sign. # Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.<ref>The speedup that results from batch verification can be demonstrated with the cryptography library [https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md libsecp256k1].</ref> -Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification. +Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification. '''Key prefixing''' Using the verification rule above directly makes Schnorr signatures vulnerable to "related-key attacks" in which a third party can convert a signature ''(R, s)'' for public key ''P'' into a signature ''(R, s + a⋅hash(R || m))'' for public key ''P + a⋅G'' and the same message ''m'', for any given additive tweak ''a'' to the signing key. This would render signatures insecure when keys are generated using [[bip-0032.mediawiki#public-parent-key--public-child-key|BIP32's unhardened derivation]] and other methods that rely on additive tweaks to existing keys such as Taproot. diff --git a/bip-0340/test-vectors.py b/bip-0340/test-vectors.py index 317f2ec..5a131c4 100644 --- a/bip-0340/test-vectors.py +++ b/bip-0340/test-vectors.py @@ -24,14 +24,14 @@ def vector0(): assert(y(P) % 2 == 0) # For historical reasons (pubkey tiebreaker was squareness and not evenness) - # we should have at least one test vector where the the point reconstructed + # we should have at least one test vector where the point reconstructed # from the public key has a square and one where it has a non-square Y # coordinate. In this one Y is non-square. pubkey_point = lift_x(pubkey) assert(not has_square_y(pubkey_point)) # For historical reasons (R tiebreaker was squareness and not evenness) - # we should have at least one test vector where the the point reconstructed + # we should have at least one test vector where the point reconstructed # from the R.x coordinate has a square and one where it has a non-square Y # coordinate. In this one Y is non-square. R = lift_x(sig[0:32]) @@ -99,7 +99,7 @@ def insecure_schnorr_sign_fixed_nonce(msg, seckey0, k): e = int_from_bytes(tagged_hash("BIP0340/challenge", bytes_from_point(R) + bytes_from_point(P) + msg)) % n return bytes_from_point(R) + bytes_from_int((k + e * seckey) % n) -# Creates a singature with a small x(R) by using k = -1/2 +# Creates a signature with a small x(R) by using k = -1/2 def vector4(): one_half = n - 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0 seckey = bytes_from_int(0x763758E5CBEEDEE4F7D3FC86F531C36578933228998226672F13C4F0EBE855EB) diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 639cec6..bd45f3d 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -41,7 +41,7 @@ As a result we choose this combination of technologies: * '''Taproot''' on top of that lets us merge the traditionally separate pay-to-pubkey and pay-to-scripthash policies, making all outputs spendable by either a key or (optionally) a script, and indistinguishable from each other. As long as the key-based spending path is used for spending, it is not revealed whether a script path was permitted as well, resulting in space savings and an increase in scripting privacy at spending time. * Taproot's advantages become apparent under the assumption that most applications involve outputs that could be spent by all parties agreeing. That's where '''Schnorr''' signatures come in, as they permit [https://eprint.iacr.org/2018/068 key aggregation]: a public key can be constructed from multiple participant public keys, and which requires cooperation between all participants to sign for. Such multi-party public keys and signatures are indistinguishable from their single-party equivalents. This means that with taproot most applications can use the key-based spending path, which is both efficient and private. This can be generalized to arbitrary M-of-N policies, as Schnorr signatures support threshold signing, at the cost of more complex setup protocols. * As Schnorr signatures also permit '''batch validation''', allowing multiple signatures to be validated together more efficiently than validating each one independently, we make sure all parts of the design are compatible with this. -* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#Rationale|BIP341]]). +* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#rationale|Rationale]]). * While the core semantics of the '''signature hashing algorithm''' are not changed, a number of improvements are included in this proposal. The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the signature message, avoids unnecessary hashing, uses '''tagged hashes''' and defines a default sighash byte. * The '''public key is directly included in the output''' in contrast to typical earlier constructions which store a hash of the public key or script in the output. This has the same cost for senders and is more space efficient overall if the key-based spending path is taken. <ref>'''Why is the public key directly included in the output?''' While typical earlier constructions store a hash of a script or a public key in the output, this is rather wasteful when a public key is always involved. To guarantee batch verifiability, the public key must be known to every verifier, and thus only revealing its hash as an output would imply adding an additional 32 bytes to the witness. Furthermore, to maintain [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html 128-bit collision security] for outputs, a 256-bit hash would be required anyway, which is comparable in size (and thus in cost for senders) to revealing the public key directly. While the usage of public key hashes is often said to protect against ECDLP breaks or quantum computers, this protection is very weak at best: transactions are not protected while being confirmed, and a very [https://twitter.com/pwuille/status/1108097835365339136 large portion] of the currency's supply is not under such protection regardless. Actual resistance to such systems can be introduced by relying on different cryptographic assumptions, but this proposal focuses on improvements that do not change the security model.</ref> diff --git a/bip-0343.mediawiki b/bip-0343.mediawiki index a47edc0..cab5cb7 100644 --- a/bip-0343.mediawiki +++ b/bip-0343.mediawiki @@ -19,7 +19,7 @@ This document specifies a BIP8 (LOT=true) deployment to activate taproot. ==Motivation== -The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. +The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. ==Specification== diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki index a6ead31..12980c4 100644 --- a/bip-0345.mediawiki +++ b/bip-0345.mediawiki @@ -10,7 +10,7 @@ Type: Standards Track Created: 2023-02-03 License: BSD-3-Clause - Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcment + Post-History: 2023-01-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html [bitcoin-dev] OP_VAULT announcement 2023-03-01: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html [bitcoin-dev] BIP for OP_VAULT </pre> @@ -52,23 +52,23 @@ A common configuration for an individual custodying Bitcoin is "single signature and passphrase" using a hardware wallet. A user with such a configuration might be concerned about the risk associated with relying on a single manufacturer for key management, as well as physical access to the -hardware. +hardware. This individual can use <code>OP_VAULT</code> to make use of a highly secure key as the unlikely recovery path, while using their existing signing procedure -as the withdrawal trigger key with a configured spend delay of e.g. 1 day. +as the withdrawal trigger key with a configured spend delay of e.g. 1 day. The recovery path key can be of a highly secure nature that might otherwise make it impractical for daily use. For example, the key could be generated in some analog fashion, or on an old computer that is then destroyed, with the private key replicated only in paper form. Or the key could be a 2-of-3 multisig using devices from different manufacturers. Perhaps the key is -geographically or socially distributed. +geographically or socially distributed. Since it can be any Bitcoin script policy, the recovery key can include a number of spending conditions, e.g. a time-delayed fallback to an "easier" recovery method, in case the highly secure key winds up being ''too'' highly -secure. +secure. The user can run software on their mobile device that monitors the blockchain for spends of the vault outpoints. If the vaulted coins move in an unexpected @@ -80,7 +80,7 @@ Institutional custodians of Bitcoin may use vaults in similar fashion. ===== Provable timelocks ===== -This proposal provides a mitigation to the +This proposal provides a mitigation to the [https://web.archive.org/web/20230210123933/https://xkcd.com/538/ "$5 wrench attack."] By setting the spend delay to, say, a week, and using as the recovery path a script that enforces a longer relative timelock, the owner of the vault can @@ -95,7 +95,7 @@ timelocked coins for perpetuity or relying on a trusted third party. Vaults in Bitcoin have been discussed formally since 2016 ([http://fc16.ifca.ai/bitcoin/papers/MES16.pdf MES16]) and informally since [https://web.archive.org/web/20160220215151/https://bitcointalk.org/index.php?topic=511881.0 2014]. The value of having a configurable delay period with recovery capability in light of an -unexpected spend has been widely recognized. +unexpected spend has been widely recognized. The only way to implement vaults given the existing consensus rules, aside from [https://github.com/revault emulating vaults with large multisig @@ -114,7 +114,7 @@ Unfortunately, this approach has a number of practical shortcomings: The deployment of a "precomputed" covenant mechanism like [https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki OP_CHECKTEMPLATEVERIFY] or -[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT] +[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT] would both remove the necessity to use an ephemeral key, since the covenant is enforced on-chain, and lessen the burden of sensitive data storage, since the necessary transactions can be generated from a set of compact @@ -141,7 +141,7 @@ operational overhead using a specialized covenant. The design goals of the proposal are: -* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits. +* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits. * '''batched operations''' for recovery and withdrawal to allow managing multiple vault coins efficiently. @@ -163,7 +163,7 @@ In typical usage, a vault is created by encumbering coins under a taptree [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki (BIP-341)] containing at least two leaves: one with an <code>OP_VAULT</code>-containing script that facilitates the expected withdrawal process, and another leaf with -<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered +<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered at any time prior to withdrawal finalization. The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible @@ -172,7 +172,7 @@ withdrawal by allowing a spending transaction to replace the some parameters to be set at spend (trigger) time. All other leaves in the taptree must be unchanged in the destination output, which preserves the recovery path as well as any other spending conditions originally included in the vault. This is similar to -the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed +the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021]. These tapleaf replacement rules, described more precisely below, ensure a @@ -205,14 +205,14 @@ The vault has a number of stages, some of them optional: === Fee management === A primary consideration of this proposal is how fee management is handled. -Providing dynamic fee management is critical to the operation of a vault, since +Providing dynamic fee management is critical to the operation of a vault, since * precalculated fees are prone to making transactions unconfirmable in high fee environments, and * a fee wallet that is prespecified might be compromised or lost before use. But dynamic fee management can introduce [https://bitcoinops.org/en/topics/transaction-pinning/ pinning vectors]. Care -has been taken to avoid unnecessarily introducing these vectors when using the new +has been taken to avoid unnecessarily introducing these vectors when using the new destination-based spending policies that this proposal introduces. Originally, this proposal had a hard dependency on reformed transaction @@ -237,7 +237,7 @@ When evaluating <code>OP_VAULT</code> (<code>OP_SUCCESS187</code>, <leaf-update-script-body> <push-count> [ <push-count> leaf-update script data items ... ] -<trigger-vout-idx> +<trigger-vout-idx> <revault-vout-idx> <revault-amount> </source> @@ -413,10 +413,10 @@ that contains a taptree of the form <source> tr(<internal-pubkey>, leaves = { - recover: + recover: <recovery-sPK-hash> OP_VAULT_RECOVER, - trigger: + trigger: <trigger-auth-pubkey> OP_CHECKSIGVERIFY (i) <spend-delay> 2 $leaf-update-script-body OP_VAULT, (ii) @@ -434,7 +434,7 @@ Typically, the internal key for the vault taproot output will be specified so that it is controlled by the same descriptor as the recovery path, which facilitates another (though probably unused) means of recovering the vault output to the recovery path. This has the potential advantage of recovering the -coin without ever revealing it was a vault. +coin without ever revealing it was a vault. Otherwise, the internal key can be chosen to be an unspendable NUMS point to force execution of the taptree contents. @@ -442,7 +442,7 @@ force execution of the taptree contents. === Triggering a withdrawal === To make use of the vault, and spend it towards some output, we construct a spend -of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the +of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the full leaf-update script (in this case, a timelocked CTV script): <source> @@ -461,17 +461,17 @@ Output scripts: [ tr(<internal-pubkey>, leaves = { - recover: + recover: <recovery-sPK-hash> OP_VAULT_RECOVER, <-- unchanged trigger: - <target-CTV-hash> <spend-delay> - OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the + <target-CTV-hash> <spend-delay> + OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the leaf-update rules of OP_VAULT ... [ possibly other leaves ] } - ), + ), [ optional revault output with the same sPK as the original vault output ], @@ -499,7 +499,7 @@ entails trade-offs. ==== Unauthorized recovery ==== -Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>. +Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>. But because this reveal is the only authorization necessary to spend the vault coins to recovery, the user must expect to recover all such vaults at once, since an observer can replay this recovery (provided they know the outpoints). @@ -513,7 +513,7 @@ These limitations are to avoid pinning attacks. ==== Authorized recovery ==== -With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required. +With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required. If this key is lost, the user will be unable to initiate the recovery process for their coins. If an attacker obtains the recovery key, they may grief the user during the recovery process by constructing a low fee rate recovery transaction and broadcasting it (though they will not be able to pin because of the replaceability requirement on recovery transactions). @@ -521,7 +521,7 @@ However, authorized recovery configurations have significant benefits. Batched r ==== Recommendation: use a simple, offline recovery authorization key seed ==== -The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated. +The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated. Note that the recovery authorization key '''is not''' the recovery path key, and this is '''much different''' than any recommendation on how to generate the @@ -542,7 +542,7 @@ the trigger authorization pubkeys. Note that when using unauthorized recovery, the reveal of the recovery scriptPubKey will allow any observer to initiate the recovery process for any vault with matching recovery params, provided they are able to locate -the vault outpoints. As a result, it is recommended to expect that +the vault outpoints. As a result, it is recommended to expect that '''all outputs sharing an identical unauthorized <code><recovery-sPK-hash></code> should be recovered together'''. This situation can be avoided with a comparable key management model by varying @@ -589,7 +589,7 @@ are essentially dependent on v3 transaction relay policy being deployed. <code>OP_VAULT</code> outputs with the same taptree, aside from slightly different trigger leaves, can be batched together in the same withdrawal -process. Two "trigger" leaves are compatible if they have the same +process. Two "trigger" leaves are compatible if they have the same <code>OP_VAULT</code> arguments. Note that this allows the trigger authorization -- the script prefixing the @@ -617,7 +617,7 @@ can be recovered into the same output. Recovery-incompatible vaults which have authorized recovery can be recovered in the same transaction, so long as each set (grouped by -<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows +<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows unrelated recoveries to share common fee management. === Watchtowers === diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki index 981af81..930fce7 100644 --- a/bip-0347.mediawiki +++ b/bip-0347.mediawiki @@ -44,7 +44,7 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu * Vaults <ref>M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf</ref> which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in <ref>A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html</ref> OP_CAT is sufficient to build vaults in Bitcoin. * Replicating CheckSigFromStack <ref>A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298</ref> which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures <ref>R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md</ref>. -OP_CAT was available in early versions of Bitcoin. +OP_CAT was available in early versions of Bitcoin. In 2010, a single commit disabled OP_CAT, along with another 15 opcodes. Folklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script. For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes. @@ -109,5 +109,5 @@ An alternative implementation of OP_CAT can be found in Elements <ref>Roose S., ==Acknowledgements== -We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill, +We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill, Tim Ruffing and Johan T. Halseth for their feedback, review and helpful comments. diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki index 439b2a2..4c30b8f 100644 --- a/bip-0350.mediawiki +++ b/bip-0350.mediawiki @@ -217,7 +217,7 @@ their invalidity. Checksums are used to detect errors introduced into data during transfer. A hash function-based checksum such as Base58Check detects any type of error uniformly, but not all classes of errors are equally likely to occur in practice. Bech32 prioritizes detection of substitution errors, but improving detection of one error class inevitably worsens detection of other error classes. During the design of Bech32, it was assumed that other simple error patterns beside substitutions would have a similar detection rate as in a hash function-based design, and detection would only be worse for complex, impractical errors. The discovered insertion weakness shows that this is not the case. -For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but make sure that other common errors don't perform worse than a hash function-based checksum would. To make sure the new standard is easy to implement, we restrict the design space to only amending the final constant that is xored in, as it was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017521.html observed] that that is sufficient to mitigate the 'q' insertion issue while retaining the intended substitution error detection. In what follows, we explain how the new constant ''0x2bc830a3'' was chosen. +For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but make sure that other common errors don't perform worse than a hash function-based checksum would. To make sure the new standard is easy to implement, we restrict the design space to only amending the final constant that is xored in, as it was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017521.html observed] that is sufficient to mitigate the 'q' insertion issue while retaining the intended substitution error detection. In what follows, we explain how the new constant ''0x2bc830a3'' was chosen. ===Error patterns & detection probability=== diff --git a/bip-0351.mediawiki b/bip-0351.mediawiki index 0a31ca8..a782b0c 100644 --- a/bip-0351.mediawiki +++ b/bip-0351.mediawiki @@ -31,7 +31,7 @@ A recipient that wishes to receive funds privately has several options. Each has * The BIP uses a notification mechanism that relies on publicly known per-recipient notification addresses. If Alice wants to send funds to Bob, she has to use the same notification address that everyone else uses to notify Bob. If Alice is not careful with coin selection, i.e. ensuring that her notification UTXO is not linked to her, she will publicly expose herself as someone who is trying to send funds to Bob and their relationship becomes permanently visible on the blockchain. -* The BIP does not say anything about address types. Receiving wallets therefore have to watch all address types that can be created from a single public key. Even then, a sender could send to a script that a receipient cannot spend from. +* The BIP does not say anything about address types. Receiving wallets therefore have to watch all address types that can be created from a single public key. Even then, a sender could send to a script that a recipient cannot spend from. ==Method== @@ -113,7 +113,7 @@ Notifications are performed by publishing transactions that contain a 40-byte <c * ''search_key'' equals "PP" and is a static ASCII-encoded string (2 bytes) * ''notification_code'' is ''H(n<sub>x</sub> * P)[0..4]'' (4 bytes) * ''N<sub>x</sub>'' is the unique public key a sender is using for a particular recipient (33 bytes) -* ''address_type'' is the '''ordinal''' value of a single address type that a sender wants to send to (1 byte). This must be selected from the recepient's accepted address types. +* ''address_type'' is the '''ordinal''' value of a single address type that a sender wants to send to (1 byte). This must be selected from the recipient's accepted address types. When Alice wants to notify Bob that he will receive future payments from her, she performs the following procedure: diff --git a/bip-0352.mediawiki b/bip-0352.mediawiki index 0eff355..634e179 100644 --- a/bip-0352.mediawiki +++ b/bip-0352.mediawiki @@ -98,9 +98,8 @@ In our simplified example we have been referring to Alice's transactions as havi Alice performs the tweak with the sum of her input private keys in the following manner: -* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'' -* Let ''input_hash = hash(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisifes this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref> * Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'' +* Let ''input_hash = hash(outpoint<sub>L</sub> || (a·G))'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically<ref name="why_smallest_outpoint">'''Why use the lexicographically smallest outpoint for the hash?''' Recall that the purpose of including the input hash is so that the sender and receiver can both come up with a deterministic nonce that ensures that a unique address is generated each time, even when reusing the same scriptPubKey as an input. Choosing the smallest outpoint lexicographically satisifes this requirement, while also ensuring that the generated output is not dependent on the final ordering of inputs in the transaction. Using a single outpoint also works well with memory constrained devices (such as hardware signing devices) as it does not require the device to have the entire transaction in memory in order to generate the silent payment output.</ref> * Let ''P<sub>0</sub> = B + hash(input_hash·a·B || 0)·G'' ''' Spend and Scan Key ''' @@ -280,13 +279,6 @@ The sender performs the tweak using the private key for the nested ''P2WPKH'' ou The receiver obtains the public key from the ''scriptSig''. The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' does not match the template specified (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs'']. -=== Input hash === - -The sender and receiver MUST calculate an input hash for the transaction in the following manner: - -* Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list<ref name="why_include_A"></ref> -* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest outpoint lexicographically by txid and vout used in the transaction<ref name="why_smallest_outpoint"></ref> - === Sender === ==== Selecting inputs ==== @@ -301,10 +293,11 @@ The sending wallet performs coin selection as usual with the following restricti After the inputs have been selected, the sender can create one or more outputs for one or more silent payment addresses in the following manner: -* Generate the ''input_hash'' with the smallest outpoint lexicographically, using the method described above * Collect the private keys for each input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list * For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even Y coordinate and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] that each X-only public key has two corresponding private keys, ''d'' and ''n - d''. To maintain parity between sender and receiver, it is necessary to use the private key corresponding to the even Y coordinate when performing the ECDH step since the receiver will assume the even Y coordinate when summing the taproot X-only public keys.</ref> * Let ''a = a<sub>1</sub> + a<sub>2</sub> + ... + a<sub>n</sub>'', where each ''a<sub>i</sub>'' has been negated if necessary +** If ''a = 0'', fail +* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest ''outpoint'' lexicographically used in the transaction<ref name="why_smallest_outpoint"></ref> and ''A = a·G'' * Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'') * For each group: ** Let ''ecdh_shared_secret = input_hash·a·B<sub>scan</sub>'' @@ -335,8 +328,9 @@ A scan and spend key pair using BIP32 derivation are defined (taking inspiration If each of the checks in ''[[#scanning-silent-payment-eligible-transactions|Scanning silent payment eligible transactions]]'' passes, the receiving wallet must: -* Generate the ''input_hash'' with the smallest outpoint lexicographically, using the method described above * Let ''A = A<sub>1</sub> + A<sub>2</sub> + ... + A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list +** If ''A'' is the point at infinity, skip the transaction +* Let ''input_hash = hash<sub>BIP0352/Inputs</sub>(outpoint<sub>L</sub> || A)'', where ''outpoint<sub>L</sub>'' is the smallest ''outpoint'' lexicographically used in the transaction<ref name="why_smallest_outpoint"></ref> * Let ''ecdh_shared_secret = input_hash·b<sub>scan</sub>·A'' * Check for outputs: ** Let ''outputs_to_check'' be the taproot output keys from all taproot outputs in the transaction (spent and unspent). @@ -451,11 +445,11 @@ This distinction makes the problem for light clients more clear: light clients n Recall that a silent payment eligible transaction follows [[#scanning-silent-payment-eligible-transactions|certain conditions]] and should have at least one unspent taproot output. Full nodes (or any index server backed by a full node, such as electrum server) can build an index which collects all of the eligible public keys for a silent payments eligible transaction, sums them up, multiplies the sum by the ''input_hash'', and serves them to clients. This would be 33 bytes per silent payment eligible transaction. -For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all outputs remain unspent for > 1 month. As of today, these numbers are closer to 2–10 kB per block (10–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until June 2023 (the last 6 months of data at time time of writing). See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>. +For a typical bitcoin block of ~3500 txs, lets assume every transaction is a silent payments eligible transaction. This means a client would need to request ''33 bytes * 3500'' of data per block (roughly 100 kB per block). If a client were to request data for every block, this would amount to ~450 MB per month, assuming 100% taproot usage and all non-dust outputs remain unspent for > 1 month. As of today, these numbers are closer to 7–12 kB per block (30–50 MB per month)<ref name="appendix_data">''' Data for Appendix A ''' These numbers are based on data from January 2023 until July 2024. See [https://github.com/josibake/bitcoin-data-analysis/blob/main/notebooks/silent-payments-light-client-data.ipynb Silent payments light client data] for the full analysis.</ref>. === Transaction cut-through === -It is unlikely a light client would need to scan every block and as such can take advantage of transaction cut-through, depending on how often they choose to scan for new blocks. Empirically, ~75% of transactions with at least one unspent taproot output will have spent all taproot UTXOs in 326 blocks or less<ref name="appendix_data"></ref>. This means a client which only scans once every 3 days could ''significantly'' cut down on the number of blocks and the number of transactions per block that they need to request by only asking for data on transactions that were created since their last scan and that still have at least one unspent taproot output as of the current block height. Assuming 100% taproot usage, a client that scans once a month would likely only need around 50 MB worth of data. Based on current taproot adoption, a light client scanning once every 3 days would use roughly 15 MB per month and a client scanning once per month would use less than 5 MB per month. +It is unlikely a light client would need to scan every block and as such can take advantage of transaction cut-through, depending on how often they choose to scan for new blocks. Empirically, ~75% of transactions with at least one non-dust unspent taproot output will have spent all non-dust taproot UTXOs in 150 blocks or less<ref name="appendix_data"></ref>. This means a client that only scans once per day could ''significantly'' cut down on the number of blocks and the number of transactions per block that they need to request by only asking for data on transactions that were created since their last scan and that still have at least one non-dust unspent taproot output as of the current block height. Based on taproot adoption as of July 2024, a light client scanning once every 3 days would use roughly 30 MB per month<ref name="appendix_data">. [[File:bip-0352/scan_data_downloader_per_month.png]] @@ -483,6 +477,17 @@ A malicious notification could potentially cause the following issues: Wallet designers can choose which tradeoffs they find appropriate. For example, a wallet could check the block filter to at least probabilistically confirm the likely existence of the UTXO, thus efficiently cutting down on spam. The payment could then be marked as unconfirmed until a scan is performed and the existence of the UTXO in accordance to the silent payment specification is verified. +== Change Log == + +To help implementers understand updates to this document, we attach a version number that resembles ''semantic versioning'' (<code>MAJOR.MINOR.PATCH</code>). +The <code>MAJOR</code> version is incremented if changes to the BIP are introduced that are incompatible with prior versions. +The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added. +The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.). + +* '''1.0.1''' (2024-06-22): +** Add steps to fail if private key sum is zero (for sender) or public key sum is point at infinity (for receiver), add corresponding test vectors. +* '''1.0.0''' (2024-05-08): +** Initial version, merged as BIP-352. == Acknowledgements == diff --git a/bip-0352/bitcoin_utils.py b/bip-0352/bitcoin_utils.py index 443c096..ee55f2d 100644 --- a/bip-0352/bitcoin_utils.py +++ b/bip-0352/bitcoin_utils.py @@ -1,6 +1,7 @@ import hashlib import struct from io import BytesIO +from ripemd160 import ripemd160 from secp256k1 import ECKey from typing import Union @@ -127,7 +128,7 @@ class CTxInWitness: def hash160(s: Union[bytes, bytearray]) -> bytes: - return hashlib.new("ripemd160", hashlib.sha256(s).digest()).digest() + return ripemd160(hashlib.sha256(s).digest()) def is_p2tr(spk: bytes) -> bool: diff --git a/bip-0352/reference.py b/bip-0352/reference.py index c98dac8..b4eaf94 100755 --- a/bip-0352/reference.py +++ b/bip-0352/reference.py @@ -117,7 +117,7 @@ def decode_silent_payment_address(address: str, hrp: str = "tsp") -> Tuple[ECPub return B_scan, B_spend -def create_outputs(input_priv_keys: List[Tuple[ECKey, bool]], input_hash: bytes, recipients: List[str], hrp="tsp") -> List[str]: +def create_outputs(input_priv_keys: List[Tuple[ECKey, bool]], outpoints: List[COutPoint], recipients: List[str], hrp="tsp") -> List[str]: G = ECKey().set(1).get_pubkey() negated_keys = [] for key, is_xonly in input_priv_keys: @@ -127,6 +127,10 @@ def create_outputs(input_priv_keys: List[Tuple[ECKey, bool]], input_hash: bytes, negated_keys.append(k) a_sum = sum(negated_keys) + if not a_sum.valid: + # Input privkeys sum is zero -> fail + return [] + input_hash = get_input_hash(outpoints, a_sum * G) silent_payment_groups: Dict[ECPubKey, List[ECPubKey]] = {} for recipient in recipients: B_scan, B_m = decode_silent_payment_address(recipient, hrp=hrp) @@ -221,7 +225,7 @@ if __name__ == "__main__": ) for input in given["vin"] ] - # Conver the tuples to lists so they can be easily compared to the json list of lists from the given test vectors + # Convert the tuples to lists so they can be easily compared to the json list of lists from the given test vectors input_priv_keys = [] input_pub_keys = [] for vin in vins: @@ -236,9 +240,8 @@ if __name__ == "__main__": sending_outputs = [] if (len(input_pub_keys) > 0): - A_sum = reduce(lambda x, y: x + y, input_pub_keys) - input_hash = get_input_hash([vin.outpoint for vin in vins], A_sum) - sending_outputs = create_outputs(input_priv_keys, input_hash, given["recipients"], hrp="sp") + outpoints = [vin.outpoint for vin in vins] + sending_outputs = create_outputs(input_priv_keys, outpoints, given["recipients"], hrp="sp") # Note: order doesn't matter for creating/finding the outputs. However, different orderings of the recipient addresses # will produce different generated outputs if sending to multiple silent payment addresses belonging to the @@ -297,6 +300,10 @@ if __name__ == "__main__": add_to_wallet = [] if (len(input_pub_keys) > 0): A_sum = reduce(lambda x, y: x + y, input_pub_keys) + if A_sum.get_bytes() is None: + # Input pubkeys sum is point at infinity -> skip tx + assert expected["outputs"] == [] + continue input_hash = get_input_hash([vin.outpoint for vin in vins], A_sum) pre_computed_labels = { (generate_label(b_scan, label) * G).get_bytes(False).hex(): generate_label(b_scan, label).hex() diff --git a/bip-0352/ripemd160.py b/bip-0352/ripemd160.py new file mode 100644 index 0000000..1280136 --- /dev/null +++ b/bip-0352/ripemd160.py @@ -0,0 +1,130 @@ +# Copyright (c) 2021 Pieter Wuille +# Distributed under the MIT software license, see the accompanying +# file COPYING or http://www.opensource.org/licenses/mit-license.php. +"""Test-only pure Python RIPEMD160 implementation.""" + +import unittest + +# Message schedule indexes for the left path. +ML = [ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, + 7, 4, 13, 1, 10, 6, 15, 3, 12, 0, 9, 5, 2, 14, 11, 8, + 3, 10, 14, 4, 9, 15, 8, 1, 2, 7, 0, 6, 13, 11, 5, 12, + 1, 9, 11, 10, 0, 8, 12, 4, 13, 3, 7, 15, 14, 5, 6, 2, + 4, 0, 5, 9, 7, 12, 2, 10, 14, 1, 3, 8, 11, 6, 15, 13 +] + +# Message schedule indexes for the right path. +MR = [ + 5, 14, 7, 0, 9, 2, 11, 4, 13, 6, 15, 8, 1, 10, 3, 12, + 6, 11, 3, 7, 0, 13, 5, 10, 14, 15, 8, 12, 4, 9, 1, 2, + 15, 5, 1, 3, 7, 14, 6, 9, 11, 8, 12, 2, 10, 0, 4, 13, + 8, 6, 4, 1, 3, 11, 15, 0, 5, 12, 2, 13, 9, 7, 10, 14, + 12, 15, 10, 4, 1, 5, 8, 7, 6, 2, 13, 14, 0, 3, 9, 11 +] + +# Rotation counts for the left path. +RL = [ + 11, 14, 15, 12, 5, 8, 7, 9, 11, 13, 14, 15, 6, 7, 9, 8, + 7, 6, 8, 13, 11, 9, 7, 15, 7, 12, 15, 9, 11, 7, 13, 12, + 11, 13, 6, 7, 14, 9, 13, 15, 14, 8, 13, 6, 5, 12, 7, 5, + 11, 12, 14, 15, 14, 15, 9, 8, 9, 14, 5, 6, 8, 6, 5, 12, + 9, 15, 5, 11, 6, 8, 13, 12, 5, 12, 13, 14, 11, 8, 5, 6 +] + +# Rotation counts for the right path. +RR = [ + 8, 9, 9, 11, 13, 15, 15, 5, 7, 7, 8, 11, 14, 14, 12, 6, + 9, 13, 15, 7, 12, 8, 9, 11, 7, 7, 12, 7, 6, 15, 13, 11, + 9, 7, 15, 11, 8, 6, 6, 14, 12, 13, 5, 14, 13, 13, 7, 5, + 15, 5, 8, 11, 14, 14, 6, 14, 6, 9, 12, 9, 12, 5, 15, 8, + 8, 5, 12, 9, 12, 5, 14, 6, 8, 13, 6, 5, 15, 13, 11, 11 +] + +# K constants for the left path. +KL = [0, 0x5a827999, 0x6ed9eba1, 0x8f1bbcdc, 0xa953fd4e] + +# K constants for the right path. +KR = [0x50a28be6, 0x5c4dd124, 0x6d703ef3, 0x7a6d76e9, 0] + + +def fi(x, y, z, i): + """The f1, f2, f3, f4, and f5 functions from the specification.""" + if i == 0: + return x ^ y ^ z + elif i == 1: + return (x & y) | (~x & z) + elif i == 2: + return (x | ~y) ^ z + elif i == 3: + return (x & z) | (y & ~z) + elif i == 4: + return x ^ (y | ~z) + else: + assert False + + +def rol(x, i): + """Rotate the bottom 32 bits of x left by i bits.""" + return ((x << i) | ((x & 0xffffffff) >> (32 - i))) & 0xffffffff + + +def compress(h0, h1, h2, h3, h4, block): + """Compress state (h0, h1, h2, h3, h4) with block.""" + # Left path variables. + al, bl, cl, dl, el = h0, h1, h2, h3, h4 + # Right path variables. + ar, br, cr, dr, er = h0, h1, h2, h3, h4 + # Message variables. + x = [int.from_bytes(block[4*i:4*(i+1)], 'little') for i in range(16)] + + # Iterate over the 80 rounds of the compression. + for j in range(80): + rnd = j >> 4 + # Perform left side of the transformation. + al = rol(al + fi(bl, cl, dl, rnd) + x[ML[j]] + KL[rnd], RL[j]) + el + al, bl, cl, dl, el = el, al, bl, rol(cl, 10), dl + # Perform right side of the transformation. + ar = rol(ar + fi(br, cr, dr, 4 - rnd) + x[MR[j]] + KR[rnd], RR[j]) + er + ar, br, cr, dr, er = er, ar, br, rol(cr, 10), dr + + # Compose old state, left transform, and right transform into new state. + return h1 + cl + dr, h2 + dl + er, h3 + el + ar, h4 + al + br, h0 + bl + cr + + +def ripemd160(data): + """Compute the RIPEMD-160 hash of data.""" + # Initialize state. + state = (0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0) + # Process full 64-byte blocks in the input. + for b in range(len(data) >> 6): + state = compress(*state, data[64*b:64*(b+1)]) + # Construct final blocks (with padding and size). + pad = b"\x80" + b"\x00" * ((119 - len(data)) & 63) + fin = data[len(data) & ~63:] + pad + (8 * len(data)).to_bytes(8, 'little') + # Process final blocks. + for b in range(len(fin) >> 6): + state = compress(*state, fin[64*b:64*(b+1)]) + # Produce output. + return b"".join((h & 0xffffffff).to_bytes(4, 'little') for h in state) + + +class TestFrameworkKey(unittest.TestCase): + def test_ripemd160(self): + """RIPEMD-160 test vectors.""" + # See https://homes.esat.kuleuven.be/~bosselae/ripemd160.html + for msg, hexout in [ + (b"", "9c1185a5c5e9fc54612808977ee8f548b2258d31"), + (b"a", "0bdc9d2d256b3ee9daae347be6f4dc835a467ffe"), + (b"abc", "8eb208f7e05d987a9b044a8e98c6b087f15a0bfc"), + (b"message digest", "5d0689ef49d2fae572b881b123a85ffa21595f36"), + (b"abcdefghijklmnopqrstuvwxyz", + "f71c27109c692c1b56bbdceb5b9d2865b3708dbc"), + (b"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", + "12a053384a9c0c88e405a06c27dcf49ada62eb2b"), + (b"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789", + "b0e20b6e3116640286ed3a87a5713079b21f5189"), + (b"1234567890" * 8, "9b752e45573d4b39f4dbd3323cab82bf63326bfb"), + (b"a" * 1000000, "52783243c1697bdbe16d37f97f68f08325dc1528") + ]: + self.assertEqual(ripemd160(msg).hex(), hexout) diff --git a/bip-0352/scan_data_downloader_per_month.png b/bip-0352/scan_data_downloader_per_month.png Binary files differindex ffcd0dd..a672a91 100644 --- a/bip-0352/scan_data_downloader_per_month.png +++ b/bip-0352/scan_data_downloader_per_month.png diff --git a/bip-0352/send_and_receive_test_vectors.json b/bip-0352/send_and_receive_test_vectors.json index f9b205b..264f7be 100644 --- a/bip-0352/send_and_receive_test_vectors.json +++ b/bip-0352/send_and_receive_test_vectors.json @@ -2669,5 +2669,92 @@ } } ] + }, + { + "comment": "Input keys sum up to zero / point at infinity: sending fails, receiver skips tx", + "sending": [ + { + "given": { + "vin": [ + { + "txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e", + "vout": 0, + "scriptSig": "", + "txinwitness": "024730440220085003179ce1a3a88ce0069aa6ea045e140761ab88c22a26ae2a8cfe983a6e4602204a8a39940f0735c8a4424270ac8da65240c261ab3fda9272f6d6efbf9cfea366012102557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975", + "prevout": { + "scriptPubKey": { + "hex": "00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792" + } + }, + "private_key": "a6df6a0bb448992a301df4258e06a89fe7cf7146f59ac3bd5ff26083acb22ceb" + }, + { + "txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e", + "vout": 1, + "scriptSig": "", + "txinwitness": "0247304402204586a68e1d97dd3c6928e3622799859f8c3b20c3c670cf654cc905c9be29fdb7022043fbcde1689f3f4045e8816caf6163624bd19e62e4565bc99f95c533e599782c012103557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975", + "prevout": { + "scriptPubKey": { + "hex": "00149860538b5575962776ed0814ae222c7d60c72d7b" + } + }, + "private_key": "592095f44bb766d5cfe20bda71f9575ed2df6b9fb9addc7e5fdffe0923841456" + } + ], + "recipients": [ + "sp1qqtrqglu5g8kh6mfsg4qxa9wq0nv9cauwfwxw70984wkqnw2uwz0w2qnehen8a7wuhwk9tgrzjh8gwzc8q2dlekedec5djk0js9d3d7qhnq6lqj3s" + ] + }, + "expected": { + "outputs": [ + [] + ] + } + } + ], + "receiving": [ + { + "given": { + "vin": [ + { + "txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e", + "vout": 0, + "scriptSig": "", + "txinwitness": "024730440220085003179ce1a3a88ce0069aa6ea045e140761ab88c22a26ae2a8cfe983a6e4602204a8a39940f0735c8a4424270ac8da65240c261ab3fda9272f6d6efbf9cfea366012102557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975", + "prevout": { + "scriptPubKey": { + "hex": "00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792" + } + } + }, + { + "txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e", + "vout": 1, + "scriptSig": "", + "txinwitness": "0247304402204586a68e1d97dd3c6928e3622799859f8c3b20c3c670cf654cc905c9be29fdb7022043fbcde1689f3f4045e8816caf6163624bd19e62e4565bc99f95c533e599782c012103557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975", + "prevout": { + "scriptPubKey": { + "hex": "00149860538b5575962776ed0814ae222c7d60c72d7b" + } + } + } + ], + "outputs": [ + "0000000000000000000000000000000000000000000000000000000000000000" + ], + "key_material": { + "spend_priv_key": "0000000000000000000000000000000000000000000000000000000000000001", + "scan_priv_key": "0000000000000000000000000000000000000000000000000000000000000002" + }, + "labels": [] + }, + "expected": { + "addresses": [ + "sp1qqtrqglu5g8kh6mfsg4qxa9wq0nv9cauwfwxw70984wkqnw2uwz0w2qnehen8a7wuhwk9tgrzjh8gwzc8q2dlekedec5djk0js9d3d7qhnq6lqj3s" + ], + "outputs": [] + } + } + ] } -]
\ No newline at end of file +] diff --git a/bip-0353.mediawiki b/bip-0353.mediawiki new file mode 100644 index 0000000..9deba50 --- /dev/null +++ b/bip-0353.mediawiki @@ -0,0 +1,147 @@ +<pre> + BIP: 353 + Layer: Applications + Title: DNS Payment Instructions + Author: Matt Corallo <bip353@bluematt.me> + Bastien Teinturier <bastien@acinq.fr> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0353 + Status: Draft + Type: Standards Track + Created: 2024-02-10 + License: CC0-1.0 + Post-History: 2024-02-13: https://groups.google.com/g/bitcoindev/c/uATaflkYglQ [bitcoin-dev] Mapping Human-Readable Names to Payment Instructions +</pre> + + +==Copyright== + +This BIP is licensed under the CC0-1.0 license. + +==Abstract== +This BIP proposes a standard format for encoding [[bip-0021.mediawiki|BIP 21]] URI schemes in DNS TXT records. + +==Motivation== +Various Bitcoin and other cryptocurrency applications have developed human-readable names for payment instructions over time, with marketplace adoption signaling strong demand for it from users. + +The DNS provides a standard, global, hierarchical namespace mapping human-readable labels to records of various forms. Using DNSSEC, the DNS provides cryptographic guarantees using a straightforward PKI which follows the hierarchical nature of the DNS, allowing for stateless and even offline validation of DNS records from a single trusted root. + +Further, because DNS queries are generally proxied through ISP-provided or other resolvers, DNS queries usually do not directly expose the queryer's IP address. Further, because of the prevalence of open resolvers, the simplicity of the protocol, and broad availability of DNS recursive resolver implementations, finding a proxy for DNS records is trivial. + +Thus, using TXT records to store Bitcoin payment instructions allows for human-readable Bitcoin payment destinations which can be trivially verified on hardware wallets and which can be resolved relatively privately. + +==Specification== + +=== General rules for handling === +Bitcoin wallets MUST NOT prefer to use DNS-based resolving when methods with explicit public keys or addresses are available. In other words, if a standard Bitcoin address or direct BIP 21 URI is available or would suffice, Bitcoin wallets MUST prefer to use that instead. + +=== Records === +Payment instructions are indexed by both a user and a domain. Instructions for a given `user` and `domain` are stored at `user`.user._bitcoin-payment.`domain` in a single TXT record. + +All payment instructions MUST be DNSSEC-signed. + +Payment instructions MAY resolve through CNAME or DNAME records as long as all such records and the ultimate records pointed to by them are DNSSEC signed. + +User and domain names which are not expressible using standard printable ASCII MUST be encoded using the punycode IDN encoding defined in [[https://datatracker.ietf.org/doc/html/rfc3492|RFC 3492]] and [[https://datatracker.ietf.org/doc/html/rfc5891|RFC 5891]]. + +Note that because resolvers are not required to support resolving non-ASCII identifiers, wallets SHOULD avoid using non-ASCII identifiers. + +=== Resolution === + +Clients resolving Bitcoin payment instructions MUST ignore any TXT records at the same label which do not begin with (ignoring case) "bitcoin:". Resolvers encountering multiple "bitcoin:"-matching TXT records at the same label MUST treat the records as invalid and refuse to use any payment instructions therein. + +Clients resolving Bitcoin payment instructions MUST concatenate all strings in the TXT record before processing the complete URI.<ref>TXT records are defined as "one or more character-strings" in [[https://www.rfc-editor.org/rfc/rfc1035#section-3.3.14|RFC 1035]], and a "character-string" is a single byte (with a max value of 255) followed by that many characters.</ref> + +Clients resolving Bitcoin payment instructions MUST fully validate DNSSEC signatures leading to the DNS root (including any relevant CNAME or DNAME records) and MUST NOT accept DNSSEC signatures which use SHA-1 or RSA with keys shorter than 1024 bits. Resolvers MAY accept SHA-1 DS records. + +Clients resolving Bitcoin payment instructions MUST NOT trust a remote resolver to validate DNSSEC records on their behalf. + +Clients resolving Bitcoin payment instructions MUST support resolving through CNAME or DNAME records. + +Resolvers MAY support resolving non-ASCII user and domain identifiers. Resolvers which do support non-ASCII user and domain identifiers MUST take precautions to prevent homograph attacks and SHOULD consider denying paste functionality when entering non-ASCII identifiers. Wallets which do not take any such precautions MUST instead display non-ASCII user and domain identifiers using their raw punycode. As such, wallets SHOULD NOT create identifiers which are not entirely printable ASCII. + +While clients MAY cache the payment instructions they receive from the DNS, clients MUST NOT cache the payment instructions received from the DNS for longer than the TTL provided by their DNS resolver, and further MUST NOT cache the payment instructions for longer than the lowest initial TTL (which is signed as a part of DNSSEC signatures) received in the full DNSSEC chain leading from the DNS root to the resolved TXT record. + +=== Address Reuse === + +Payment instructions with on-chain addresses which will be re-used SHOULD be rotated as regularly as possible to reduce address reuse. Such payment instructions SHOULD also use a relatively short DNS TTL to ensure regular rotation takes effect quickly. In cases where this is not practical, payment instructions SHOULD NOT contain on-chain addresses (i.e. the URI path SHOULD be empty). + +Payment instructions which do contain on-chain addresses which will be re-used SHOULD be rotated after any transaction to such an address is confirmed on-chain. + +=== Display === + +When displaying a verified human-readable address, wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved. + +Wallets providing the ability for users to "copy" their address information SHOULD copy the underlying URI directly, rather than the human-readable address. This avoids an additional DNS lookup by the application in which it is pasted. Wallets that nevertheless provide users the ability to copy their human-readable address, MUST include the ₿ prefix (i.e. copy it in the form ₿`user`@`domain`). + +Wallets accepting payment information from external devices (e.g. hardware wallets) SHOULD accept RFC 9102-formatted proofs (as a series of unsorted `AuthenticationChain` records) and, if verification succeeds, SHOULD display the recipient in the form ₿`user`@`domain`. + +== Rationale == + +=== Display === + +There are several ways in which human-readable payment instructions could be displayed in wallets. In order to ensure compatibility with existing human-readable names schemes, @ is used as the separator between the `user` and `domain` parts. However, simply using the @ separator can lead to confusion between email addresses on a given domain and payment instructions on a domain. In order to somewhat reduce the incidence of such confusion, a ₿ prefix is used. + +=== Rotation === + +On-chain addresses which are re-used (i.e. not including schemes like [[bip-0352.mediawiki|Silent Payments]]) need to be rotated to avoid contributing substantially to address reuse. However, rotating them on a timer or any time a transaction enters the mempool could lead to substantial overhead from excess address generation. Instead, rotating addresses any time a transaction is confirmed on-chain ensures address rotation happens often while bounding the maximum number of addresses needed to one per block, which grows very slowly and will not generate an address set too large to handle while scanning the chain going forward. + +=== Alternatives === +There are many existing schemes to resolve human-readable names to cryptocurrency payment instructions. Sadly, these current schemes suffer from a myriad of drawbacks, including (a) lacking succinct proofs of namespace to public key mappings, (b) revealing sender IP addresses to recipients or other intermediaries as a side-effect of payment, (c) relying on the bloated TLS Certificate Authority infrastructure, or (d) lacking open access, not allowing anyone to create a namespace mapping. + +==== DNS Rather than blockchain-based solutions ==== +There are many blockchain-based alternatives to the DNS which feature better censorship-resistance and, in many cases, security. However, here we chose to use the standard ICANN-managed DNS namespace as many blockchain-based schemes suffer from (a), above (though in some cases this could be addressed with cryptographic SNARK schemes). Further, because they do not have simple client-side querying ability, many of these schemes use trusted intermediaries which resolve names on behalf of clients. This reintroduces drawbacks (b) and often (c) as well. + +Finally, it is worth noting that none of the blockchain-based alternatives to the DNS have had material adoption outside of their specific silos, and committing Bitcoin wallets to rely on a separate system which doesn't see broad adoption may not be sustainable. + +==== DNS Rather than HTTP-based solutions ==== +HTTP(s)-based payment instruction resolution protocols suffer from drawbacks (a), (b), and (c), above, and generally shouldn't be considered a serious alternative for payment instruction resolution. + +==== Private DNS Querying ==== +While public recursive DNS resolvers are very common (e.g. 1.1.1.1, 8.8.8.8, and 9.9.9.9), using such resolvers directly (even after validating DNSSEC signatures) introduces drawback (b), at least in regard to a centralized intermediary. Resolving payment instructions recursively locally using a resolver on the same local network or in the paying application would instead introduce drawback (b) directly to the recipient, which may well be worse. + +For payers not using VPN or other proxying technologies, they generally trust their ISP to not snoop on their DNS requests anyway, so using ISP-provided recursive DNS resolvers is likely the best option. + +However, for the best privacy, payers are encouraged to perform DNS resolution over Tor or another VPN technology. + +Lightning payers should consider utilizing DNS resolution over native onion messages, using the protocol described in [[https://github.com/lightning/blips/blob/master/blip-0032.md|BLIP 32]] + +=== DNS Enumeration === + +In most cases where payments are accepted from any third-party, user enumeration is practical by simply attempting to send small value payments to a list of possible user names. However, storing all valid users in the DNS directly may make such enumeration marginally more practical. Thus, those wishing to avoid such enumeration should carefully ensure all DNS names return valid payment instructions. Note when doing so that wildcard records are identified as such by the DNSSEC RRSIG labels counter and are differentiable from non-wildcard records. + +== Backwards Compatibility == + +This work is intended to extend and subsume the existing "Lightning Address" scheme, which maps similar names (without the ₿ prefix) using HTTPS servers to Lightning BOLT 11 payment instructions. Wallets implementing this scheme MAY fall back to existing "Lightning Address" logic if DNS resolution fails but SHOULD NOT do so after this scheme is sufficiently broadly deployed to avoid leaking sender IP address information. + +== Examples == + +<code>matt@mattcorallo.com</code> resolves to + +<pre>matt.user._bitcoin-payment.mattcorallo.com. 1800 IN TXT "bitcoin:?lno=lno1qsgr30k45jhvkfqxjqheaetac +u4guyxvqttftvqu0f5sneckep3lkwdut7mmhhpcyjmlmnjn4hze8ed7pq88xqkxt2dcw5mlxhz644fms82f7k4ymfxs2ehhpjtxw +xly0w5k8xdtlvpqyd8xzdq4tq8lgupnueshgydr330lc3j5kdcqh54gt7jdg9n68j4eqqeu7ts8uh0qxamee6ndj37tc6mzgejth +vvjqj96p8dz2h" "rsh5z5n27qfk6svjz5pmkh0smq26k0j2j4q36xgq3r5qzet9kuhq4lydpen5mskxgjdvs5faqgv8pmj7cfd7 +ny84djksqpqk9ky6juc7fpezecxvg7sjx05dckyypnv9tmvfp6tkpehmtaqmvuupetxuzqf4t0azddjdcpasgw6hxuz9g" +</pre> + +* Note that `lno` indicates a value containing a lightning BOLT12 offer. +* Note that the complete URI is broken into two strings with maximum 255 characters each + +== Reference Implementations == +* A DNSSEC proof generation and validation implementation can be found at https://git.bitcoin.ninja/index.cgi?p=dnssec-prover;a=summary +* A lightning-specific name to payment instruction resolver can be found at https://git.bitcoin.ninja/index.cgi?p=lightning-resolver;a=summary +* Reference implementations for parsing the URI contents can be found in [[bip-0021.mediawiki|BIP 21]]. + + +== Footnotes == + +<references /> + +== Acknowledgements == + +Thanks to Rusty Russell for the concrete address rotation suggestion. + +Thanks to the Bitcoin Design Community, and especially Christoph Ono for lots of discussion, analysis, and UX mockups in how human-readable payment instructions should be displayed. + +Thanks to Andrew Kaizer for the suggestion to explicitly restrict cache lifetime to the relevant DNS TTLs. diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki index 98f1800..885dfc8 100644 --- a/bip-0370.mediawiki +++ b/bip-0370.mediawiki @@ -5,7 +5,7 @@ Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0370 - Status: Draft + Status: Final Type: Standards Track Created: 2021-01-14 License: BSD-2-Clause @@ -497,4 +497,4 @@ The timelock for the following PSBTs cannot be computed: ==Reference implementation== -The reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt2. +The reference implementation of the PSBT format is available in [https://github.com/bitcoin/bitcoin/pull/21283 Bitcoin Core PR 21283]. diff --git a/bip-0371.mediawiki b/bip-0371.mediawiki index 45b69f8..9227569 100644 --- a/bip-0371.mediawiki +++ b/bip-0371.mediawiki @@ -5,7 +5,7 @@ Author: Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0371 - Status: Draft + Status: Final Type: Standards Track Created: 2021-06-21 License: BSD-2-Clause diff --git a/bip-0372.mediawiki b/bip-0372.mediawiki index bf98b7c..ee40dd0 100644 --- a/bip-0372.mediawiki +++ b/bip-0372.mediawiki @@ -17,7 +17,7 @@ ===Abstract=== This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 -that allow for pay-to-contract key tweaking data data to be included in a PSBT +that allow for pay-to-contract key tweaking data to be included in a PSBT of any version. These will represent an extra-transaction information required for the signer to produce valid signatures spending previous outputs. diff --git a/bip-0373.mediawiki b/bip-0373.mediawiki new file mode 100644 index 0000000..d9dec45 --- /dev/null +++ b/bip-0373.mediawiki @@ -0,0 +1,216 @@ +<pre> + BIP: 373 + Layer: Applications + Title: MuSig2 PSBT Fields + Author: Ava Chow <me@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0373 + Status: Draft + Type: Standards Track + Created: 2024-01-15 + License: CC0-1.0 +</pre> + +==Introduction== + +===Abstract=== + +This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP +327 MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for +the participants' keys, the public nonces, and the partial signatures produced with MuSig2. + +===Copyright=== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +===Motivation=== + +BIP 327 specifies a way to create BIP 340 compatible public keys and signatures using the MuSig2 +Multi-Signature scheme. The existing PSBT fields are unable to support MuSig2 as it introduces new +concepts and additional rounds of communication. Therefore new fields must be defined to allow PSBTs +to carry the information necessary to produce a valid signature with MuSig2. + +==Specification== + +The new per-input types are defined as follows: + +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><valuedata></tt> +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| rowspan="2"|MuSig2 Participant Public Keys +| rowspan="2"|<tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt> +| <tt><33 byte plain aggregate pubkey></tt> +| <tt><33 byte compressed pubkey>*</tt> +| rowspan="2"| +| rowspan="2"| +| rowspan="2"| 0, 2 +|- +| The MuSig2 aggregate plain public key<ref>'''Why the plain aggregate public key instead of x-only?''' +BIP 32 requires public keys to include their evenness byte. Aggregate public keys are expected to be +derived from, following [[bip-0328.mediawiki|BIP 328]], and therefore will +need to include the evenness. Furthermore, PSBT_IN_TAP_BIP32_DERIVATION fields include fingerprints +to identify master keys, and these fingerprints require full compressed public keys. By including +the aggregate key as a full public key, signers that are unaware of the MuSig2 outside of the PSBT +will still be able to identify which keys are derived from the aggregate key by computing and then +comparing the fingerprints. This is necessary for the signer to apply the correct tweaks to their +partial signature.</ref> from the <tt>KeyAgg</tt> algorithm. This key may or may not +be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the +script were derived. +| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order +required for aggregation. If sorting was done, then the keys must be in the sorted order. +|- +| rowspan="2"|MuSig2 Public Nonce +| rowspan="2"|<tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt> +| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt> +| <tt><66 byte public nonce></tt> +| rowspan="2"| +| rowspan="2"| +| rowspan="2"| 0, 2 +|- +| The compressed public key of the participant providing this nonce, followed by the plain public +key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of +the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the +taproot output key, then the tapleaf hash must be omitted. The plain public key must be +the key found in the script and not the aggregate public key that it was derived from, if it was +derived from an aggregate key. +| The public nonce produced by the <tt>NonceGen</tt> algorithm. +|- +| rowspan="2"|MuSig2 Participant Partial Signature +| rowspan="2"|<tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt> +| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt> +| <tt><32 byte partial signature></tt> +| rowspan="2"| +| rowspan="2"| +| rowspan="2"| 0, 2 +|- +| The compressed public key of the participant providing this partial signature, followed by the +plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash +of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or +the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must +be the key found in the script and not the aggregate public key that it was derived from, if it was +derived from an aggregate key. +| The partial signature produced by the <tt>Sign</tt> algorithm. +|} + +The new per-output types are defined as follows: + +{| +! Name +! <tt><keytype></tt> +! <tt><keydata></tt> +! <tt><valuedata></tt> +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| rowspan="2"|MuSig2 Participant Public Keys +| rowspan="2"|<tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt> +| <tt><33 byte compressed pubkey></tt> +| <tt><33 byte compressed pubkey>*</tt> +| rowspan="2"| +| rowspan="2"| +| rowspan="2"|0, 2 +|- +| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not +be in the script directly. It may instead be a parent public key from which the public keys in the +script were derived. +| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order +required for aggregation. If sorting was done, then the keys must be in the sorted order. +|} + +==Roles== + +===Updater=== + +When an updater observes a Taproot output which involves a MuSig2 aggregate public key that it is +aware if, it can add a <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> field containing the public keys +of the participants. This aggregate public key may be directly in the script, the Taproot internal +key, the Taproot output key, or a public key from which the key in the script was derived from. + +An aggregate public key that appears directly in the script or internal key may be from the result +of deriving child pubkeys from participant xpubs. If the updater has this derivation information, it +should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> for each participant public key. + +If the public key found was derived from an aggregate public key, then all MuSig2 PSBT fields for +that public key should contain the aggregate public key rather than the found pubkey itself. The +updater should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> that contains the derivation path used +to derive the found pubkey from the aggregate pubkey. +Derivation from the aggregate pubkey can be assumed to follow [[bip-0328.mediawiki|BIP 328]] +if there is no <tt>PSBT_IN_GLOBAL_XPUB</tt> that specifies the synthetic xpub for the aggregate +public key. + +Updaters should add <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS</tt> and +<tt>PSBT_OUT_TAP_BIP32_DERIVATION</tt> similarly to inputs to aid in change detection. + +===Signer=== + +To determine whether a signer is a participant in the MuSig2 aggregate key, the signer should first +look at all <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> and see if any key which it knows the +private key for appears as a participant in any aggregate pubkey. Signers should also check whether +any of the keys in <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> belong to it, and if any of those keys +appear in as a participant in <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt>. + +For each aggregate public key that the signer is a participant of that it wants +to produce a signature for, if the signer does not find an existing +<tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field for its key, then it should add one using +the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public +nonce that is added in a <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field. However +signers must keep in mind that '''improper nonce usage can compromise private +keys.''' Please see BIP 327 for best practices on nonce generation and usage. + +Once all signers have added their <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> fields, each signer will perform +the <tt>NonceAgg</tt> algorithm followed by the <tt>Sign</tt> algorithm in order to produce the +partial signature for their key. The result will be added to the PSBT in a +<tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt> field. + +Signers must remember to apply any relevant tweaks such as a tweak that is the result of performing +BIP 32 unhardened dervation with the aggregate public key as the parent key. + +If all other signers have provided a <tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt>, then the final signer may +perform the <tt>PartialSigAgg</tt> algorithm and produce a BIP 340 compatible signature that can be +placed into a <tt>PSBT_IN_TAP_KEY_SIG</tt> or a <tt>PSBT_IN_TAP_SCRIPT_SIG</tt>. + +===Finalizer=== + +A finalizer may perform the same <tt>PartialSigAgg</tt> step as the final signer if it has not +already been done. + +Otherwise, the resulting signature is a BIP 340 compatible signature and finalizers should treat it +as such. + +==Backwards Compatibility== + +These are simply new fields added to the existing PSBT format. Because PSBT is designed to be +extensible, old software will ignore the new fields. + +Reusing <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> to provide derivation paths for participant public +keys may cause software unaware of MuSig2 to produce a signature for that public key. This is still +safe. If that public key does not directly appear in the leaf script that was signed, then the +signature produced will not be useful and so cannot be replayed. If the public key does directly +appear in the leaf script, then the signer will have validated the script as if it did not involve a +MuSig2 and will have found it acceptable in order for it to have produced a signature. In either +case, producing a signature does not give rise to the possibility of losing funds. + +==Test Vectors== + +TBD + +==Rationale== + +<references/> + +==Reference implementation== + +The reference implementation of the PSBT format is available at TBD. + +==Acknowledgements== + +Thanks to Sanket Kanjalkar whose notes on this topic formed the initial basis of this BIP. Also +thanks to Pieter Wuille, Jonas Nick, Tim Ruffing, Marko Bencun, Salvatore Ingala, and all others who +have participated in discussions about these fields. diff --git a/bip-0379.md b/bip-0379.md new file mode 100644 index 0000000..10755d4 --- /dev/null +++ b/bip-0379.md @@ -0,0 +1,423 @@ +<pre> + BIP: 379 + Layer: Applications + Title: Miniscript + Author: Pieter Wuille <pieter@wuille.net> + Andrew Poelstra <andrew.poelstra@gmail.com> + Sanket Kanjalkar <sanket1729@gmail.com> + Antoine Poinsot <darosior@protonmail.com> + Ava Chow <me@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0379 + Status: Draft + Type: Informational + Created: 2023-10-10 + License: CC0-1.0 +</pre> + +## Abstract + +This document specifies Miniscript, a language for writing (a subset of) Bitcoin Scripts in a +structured way, enabling analysis, composition, generic signing and more. + +## Copyright + +This document is licensed under the Creative Commons CC0 1.0 Universal license. + +## Motivation + +Bitcoin Script is an unusual stack-based language with many edge cases, designed for implementing +spending conditions consisting of various combinations of signatures, hash locks, and time locks. +Yet, despite being limited in functionality, it is still highly nontrivial to: + +* Given a combination of spending conditions, finding the most economical script to implement it. +* Given two scripts, construct a script that implements a composition of their spending conditions (e.g. a multisig where one of the "keys" is another multisig). +* Given a script, find out what spending conditions it permits. +* Given a script and access to a sufficient set of private keys, construct a general satisfying witness for it. +* Given a script, be able to predict the cost of spending an output. +* Given a script, know whether particular resource limitations like the ops limit might be hit when spending. + +Miniscript functions as a representation for scripts that makes this sort of operations possible. +It has a structure that allows composition. It is very easy to statically analyze for various +properties (spending conditions, correctness, security properties, malleability, ...). It can be +targeted by spending policy compilers. Finally, compatible scripts can easily be converted to +Miniscript form - avoiding the need for additional metadata for e.g. signing devices that support +it. + +## Specification + +These specifications apply to P2WSH ([BIP 141](bip-0141.mediawiki)) and Tapscript ([BIP 342](bip-0342.mediawiki)) scripts, with only minor +variations between the two. Differences are noted inline. Unless explicitly stated otherwise, +specifications apply to both. P2SH and bare scripts are excluded from this specification. + +### Translation Table + +Miniscript consists of a set of script *fragments* which are designed to be safely and correctly composabe. + +This table shows all Miniscript *fragments* and their associated semantics and Bitcoin Script. +Fragments that do not change the semantics of their subexpressions are called *wrappers*. Normal +fragments use a `fragment(arg1,arg2,...)` notation, while wrappers are written using +prefixes separated from other fragments by a colon. The colon is dropped between subsequent +wrappers; e.g. `dv:older(144)` is the `d:` wrapper applied to the +`v:` wrapper applied to the `older` fragment for 144 blocks. + +The `pk`, `pkh`, and `and_n` fragments and `t:`, +`l:`, and `u:` wrappers are syntactic sugar for other Miniscripts, as listed +in the table below. Note that `<20>` are in hex representation in this document. + +Miniscript fragments are expected to be used in [BIP 382](bip-0382.mediawiki) `wsh()` descriptors +and [BIP 386](bip-0386.mediawiki) `tr()` descriptors. Key expressions are specified in +[BIP 380](bip-0380.mediawiki#user-content-Key_Expressions). Additionally, BIPs 382 and 386 specify +restrictions on key expressions and what they resolve to - these apply to key expressions in +Miniscript. BIP 382's key expression restrictions apply to Miniscript in P2WSH contexts, and BIP +386's key expression restrictions apply to Miniscript in P2TR contexts. From a user's perspective, +Miniscript is not a separate language, but rather a significant expansion of the descriptor language. + +| Semantics | Miniscript Fragment | Bitcoin Script +|----------------------------------------------------------|-------------------------------|--------------- +| false | `0` | `0` +| true | `1` | `1` +| check(key) | `pk_k(key)` | `<key>` +| | `pk_h(key)` | `DUP HASH160 <HASH160(key)> EQUALVERIFY ` +| | `pk(key)` = `c:pk_k(key)` | `<key> CHECKSIG` +| | `pkh(key)` = `c:pk_h(key)` | `DUP HASH160 <HASH160(key)> EQUALVERIFY CHECKSIG` +| nSequence ≥ n (and compatible) | `older(n)` | `<n> CHECKSEQUENCEVERIFY` +| nLockTime ≥ n (and compatible) | `after(n)` | `<n> CHECKLOCKTIMEVERIFY` +| len(x) = 32 and SHA256(x) = h | `sha256(h)` | `SIZE <20> EQUALVERIFY SHA256 <h> EQUAL` +| len(x) = 32 and HASH256(x) = h | `hash256(h)` | `SIZE <20> EQUALVERIFY HASH256 <h> EQUAL` +| len(x) = 32 and RIPEMD160(x) = h | `ripemd160(h)` | `SIZE <20> EQUALVERIFY RIPEMD160 <h> EQUAL` +| len(x) = 32 and HASH160(x) = h | `hash160(h)` | `SIZE <20> EQUALVERIFY HASH160 <h> EQUAL` +| (X and Y) or Z | `andor(X,Y,Z)` | `[X] NOTIF [Z] ELSE [Y] ENDIF` +| X and Y | `and_v(X,Y)` | `[X] [Y]` +| | `and_b(X,Y)` | `[X] [Y] BOOLAND` +| | `and_n(X,Y)` = `andor(X,Y,0)` | `[X] NOTIF 0 ELSE [Y] ENDIF` +| X or Z | `or_b(X,Z)` | `[X] [Z] BOOLOR` +| | `or_c(X,Z)` | `[X] NOTIF [Z] ENDIF` +| | `or_d(X,Z)` | `[X] IFDUP NOTIF [Z] ENDIF` +| | `or_i(X,Z)` | `IF [X] ELSE [Z] ENDIF` +| X_1 + ... + X_n = k | `thresh(k,X_1,...,X_n)` | `[X_1] [X_2] ADD ... [X_n] ADD ... <k> EQUAL` +| check(key_1) + ... + check(key_n) = k *(P2WSH only)* | `multi(k,key_1,...,key_n)` | `<k> <key_1> ... <key_n> <n> CHECKMULTISIG` +| check(key_1) + ... + check(key_n) = k *(Tapscript only)* | `multi_a(k,key_1,...,key_n)` | `<key_1> CHECKSIG <key_2> CHECKSIGADD ... <key_n> CHECKSIGADD <k> NUMEQUAL` +| X (identities) | `a:X` | `TOALTSTACK [X] FROMALTSTACK` +| | `s:X` | `SWAP [X]` +| | `c:X` | `[X] CHECKSIG` +| | `t:X` = `and_v(X,1)` | `[X] 1` +| | `d:X` | `DUP IF [X] ENDIF` +| | `v:X` | `[X] VERIFY (or VERIFY version of last opcode in [X])` +| | `j:X` | `SIZE 0NOTEQUAL IF [X] ENDIF` +| | `n:X` | `[X] 0NOTEQUAL` +| | `l:X` = `or_i(0,X)` | `IF 0 ELSE [X] ENDIF` +| | `u:X` = `or_i(X,0)` | `IF [X] ELSE 0 ENDIF` + +### Type System + +Not every Miniscript expression can be composed with every other. Some return their result by +putting true or false on the stack; others can only abort or continue. Some require subexpressions +that consume an exactly known number of arguments, while others need a subexpression that has a +nonzero top stack element to satisfy. To model all these properties, we define a correctness type +system for Miniscript. + +#### Correctness + +Every miniscript expression has one of four basic types: "**B**" (base), "**V**" (verify), +"**K**" (key) and "**W**" (wrapped). Then there are 5 type modifiers that guarantee additional +properties: "**z**" (zero-arg), "**o**" (one-arg), "**n**" (nonzero), "**d**" +(dissatisfiable), and "**u**" (unit). + +The following table lists the correctness requirements for each of the Miniscript expressions, and +its type properties in function of those of their subexpressions. + +| Miniscript | Requires | Type | Properties +|------------------------------|-------------------------------------------------------|-------------|----------- +| `0` | | B | z; u; d +| `1` | | B | z; u +| `pk_k(key)` | | K | o; n; d; u +| `pk_h(key)` | | K | n; d; u +| `older(n)`, `after(n)` | 1 ≤ n < 2<sup>31</sup> | B | z +| `sha256(h)` | | B | o; n; d; u +| `ripemd160(h)` | | B | o; n; d; u +| `hash256(h)` | | B | o; n; d; u +| `hash160(h)` | | B | o; n; d; u +| `andor(X,Y,Z)` | X is Bdu; Y and Z are both B, K, or V | same as Y/Z | z=z<sub>X</sub>z<sub>Y</sub>z<sub>Z</sub>; o=z<sub>X</sub>o<sub>Y</sub>o<sub>Z</sub> or o<sub>X</sub>z<sub>Y</sub>z<sub>Z</sub>; u=u<sub>Y</sub>u<sub>Z</sub>; d=d<sub>Z</sub> +| `and_v(X,Y)` | X is V; Y is B, K, or V | same as Y | z=z<sub>X</sub>z<sub>Y</sub>; o=z<sub>X</sub>o<sub>Y</sub> or z<sub>Y</sub>o<sub>X</sub>; n=n<sub>X</sub> or z<sub>X</sub>n<sub>Y</sub>; u=u<sub>Y</sub> +| `and_b(X,Y)` | X is B; Y is W | B | z=z<sub>X</sub>z<sub>Y</sub>; o=z<sub>X</sub>o<sub>Y</sub> or z<sub>Y</sub>o<sub>X</sub>; n=n<sub>X</sub> or z<sub>X</sub>n<sub>Y</sub>; d=d<sub>X</sub>d<sub>Y</sub>; u +| `or_b(X,Z)` | X is Bd; Z is Wd | B | z=z<sub>X</sub>z<sub>Z</sub>; o=z<sub>X</sub>o<sub>Z</sub> or z<sub>Z</sub>o<sub>X</sub>; d; u +| `or_c(X,Z)` | X is Bdu; Z is V | V | z=z<sub>X</sub>z<sub>Z</sub>; o=o<sub>X</sub>z<sub>Z</sub> +| `or_d(X,Z)` | X is Bdu; Z is B | B | z=z<sub>X</sub>z<sub>Z</sub>; o=o<sub>X</sub>z<sub>Z</sub>; d=d<sub>Z</sub>; u=u<sub>Z</sub> +| `or_i(X,Z)` | both are B, K, or V | same as X/Z | o=z<sub>X</sub>z<sub>Z</sub>; u=u<sub>X</sub>u<sub>Z</sub>; d=d<sub>X</sub> or d<sub>Z</sub> +| `thresh(k,X_1,...,X_n)` | 1 ≤ k ≤ n; X<sub>1</sub> is Bdu; others are Wdu | B | z=all are z; o=all are z except one is o; d; u +| `multi(k,key_1,...,key_n)` | 1 ≤ k ≤ n ≤ 20 | B | n; d; u +| `multi_a(k,key_1,...,key_n)` | 1 ≤ k ≤ n | B | d; u +| `a:X` | X is B | W | d=d<sub>X</sub>; u=u<sub>X</sub> +| `s:X` | X is Bo | W | d=d<sub>X</sub>; u=u<sub>X</sub> +| `c:X` | X is K | B | o=o<sub>X</sub>; n=n<sub>X</sub>; d=d<sub>X</sub>; u +| `d:X` | X is Vz | B | o; n; d; *(Tapscript only)* u +| `v:X` | X is B | V | z=z<sub>X</sub>; o=o<sub>X</sub>; n=n<sub>X</sub> +| `j:X` | X is Bn | B | o=o<sub>X</sub>; n; d; u=u<sub>X</sub> +| `n:X` | X is B | B | z=z<sub>X</sub>; o=o<sub>X</sub>; n=n<sub>X</sub>; d=d<sub>X</sub>; u + +#### Timelock Type Mixing + +There is one additional correctness property that Miniscript expressions must satisfy: +the four timelock types (absolute time based, absolute height based, relative time based, and +relative height based) must not be mixed in an incompatible way. + +Within `and` combinators and the `thresh` combinator where k >= 2, it is illegal for both absolute +height based and time based timelocks to appear, or for both relative height based and time based +timelocks to appear. + +For all other combinators, it is legal to mix timelock types. It is also always legal to +mix absolute and relative timelocks (even if one is height based and the other is time based). + +#### Malleability + +Malleability is the ability for a third party (someone who does *not* hold a participating private +key) to modify an existing satisfaction into another valid satisfaction. To analyze the +malleability guarantees of a script we define three additional type properties: "**s**" (signed), +"**f**" (forced) and "**e**" (expressive). + +The following table lists the malleability properties and requirement of each fragment. + +| Miniscript | Requires | Properties +|------------------------------|---------------------------------------------------------------------|----------- +| `0` | | s, e +| `1` | | f +| `pk_k(key)` | | s, e +| `pk_h(key)` | | s, e +| `older(n)` | | f +| `after(n)` | | f +| `sha256(h)` | | +| `ripemd160(h)` | | +| `hash256(h)` | | +| `hash160(h)` | | +| `andor(X,Y,Z)` | e<sub>X</sub> and (s<sub>X</sub> or s<sub>Y</sub> or s<sub>Z</sub>) | s=s<sub>Z</sub> and (s<sub>X</sub> or s<sub>Y</sub>); f=f<sub>Z</sub> and (s<sub>X</sub> or f<sub>Y</sub>); e=e<sub>Z</sub> and (s<sub>X</sub> or f<sub>Y</sub>) +| `and_v(X,Y)` | | s=s<sub>X</sub> or s<sub>Y</sub>; f=s<sub>X</sub> or f<sub>Y</sub> +| `and_b(X,Y)` | | s=s<sub>X </sub>or s<sub>Y;</sub> f=f<sub>Xf</sub><sub>Y</sub> or s<sub>X</sub>f<sub>X</sub> or s<sub>Y</sub>f<sub>Y</sub>; e=e<sub>X</sub>e<sub>Y</sub>s<sub>X</sub>s<sub>Y</sub> +| `or_b(X,Z)` | e<sub>Xe</sub><sub>Z </sub>and (s<sub>X</sub> or s<sub>Z</sub>) | s=s<sub>X</sub>s<sub>Z</sub>; e +| `or_c(X,Z)` | e<sub>X</sub> and (s<sub>X</sub> or s<sub>Z</sub>) | s=s<sub>X</sub>s<sub>Z</sub>; f +| `or_d(X,Z)` | e<sub>X</sub> and (s<sub>X</sub> or s<sub>Z</sub>) | s=s<sub>X</sub>s<sub>Z</sub>; f=f<sub>Z</sub>; e=e<sub>Z</sub> +| `or_i(X,Z)` | s<sub>X</sub> or s<sub>Z</sub> | s=s<sub>X</sub>s<sub>Z</sub>; f=f<sub>X</sub>f<sub>Z</sub>; e=e<sub>X</sub>f<sub>Z</sub> or e<sub>Z</sub>f<sub>X</sub> +| `thresh(k,X_1,...,X_n)` | all are e; at most k are non-s | s=at most k-1 are non-s; e=all are s +| `multi(k,key_1,...,key_n)` | | s; e +| `multi_a(k,key_1,...,key_n)` | | s; e +| `a:X` | | s=s<sub>X</sub>; f=f<sub>X</sub>; e=e<sub>X</sub> +| `s:X` | | s=s<sub>X</sub>; f=f<sub>X</sub>; e=e<sub>X</sub> +| `c:X` | | s; f=f<sub>X</sub>; e=e<sub>X</sub> +| `d:X` | | s=s<sub>X</sub>; e +| `v:X` | | s=s<sub>X</sub>; f +| `j:X` | | s=s<sub>X</sub>; e=f<sub>X +| `n:X` | | s=s<sub>X</sub>; f=f<sub>X</sub>; e=e<sub>X</sub> + +### Satisfaction + +The following table shows all valid satisfactions and dissatisfactions for every Miniscript, using +satisfactions and dissatisfactions of its subexpressions. Multiple possibilities are separated by +semicolons. Some options are inefficient and provably unnecessary to the satisfaction algorithm +described below, but are valid according to script rules and could be used by a malleator or other +non-standard actor. These are called *non-canonical* options, and are listed for completeness, but +~~[struckthrough]~~. The fragments where a satisfaction or dissatisfaction does not exist will +contain *(none)*. The fragments where the satisfaction or dissatisfaction is to provide no data +will contain *(empty)*. + +| Miniscript | Dissatisfactions (dsat) | Satisfactions (sat) +|------------------------------|---------------------------------------------------------|-------------------- +| `0` | *(empty)* | *(none)* +| `1` | *(none)* | *(empty)* +| `pk_k(key)` | 0 | sig +| `pk_h(key)` | 0 key | sig key +| `older(n)` | *(none)* | *(empty)* +| `after(n)` | *(none)* | *(empty)* +| `sha256(h)` | any 32-byte vector except the preimage | preimage +| `ripemd160(h)` | any 32-byte vector except the preimage | preimage +| `hash256(h)` | any 32-byte vector except the preimage | preimage +| `hash160(h)` | any 32-byte vector except the preimage | preimage +| `andor(X,Y,Z)` | dsat(Z) dsat(X); ~~[dsat(Y) sat(X)]~~ | sat(Y) sat(X); sat(Z) dsat(X) +| `and_v(X,Y)` | *(none)*; ~~[dsat(Y) sat(X)]~~ | sat(Y) sat(X) +| `and_b(X,Y)` | dsat(Y) dsat(X); ~~[sat(Y) dsat(X)]; [dsat(Y) sat(X)]~~ | sat(Y) sat(X) +| `or_b(X,Z)` | dsat(Z) dsat(X) | dsat(Z) sat(X); sat(Z) dsat(X); ~~[sat(Z) sat(X)]~~ +| `or_c(X,Z)` | *(none)* | sat(X); sat(Z) dsat(X) +| `or_d(X,Z)` | dsat(Z) dsat(X) | sat(X); sat(Z) dsat(X) +| `or_i(X,Z)` | dsat(X) 1; dsat(Z) 0 | sat(X) 1; sat(Z) 0 +| `thresh(k,X_1,...,X_n)` | All dsats; ~~[Sats/dsats with 1 ≤ #(sats) ≠ k]~~ | Sats/dsats with #(sats) = k +| `multi(k,key_1,...,key_n)` | 0 0 ... 0 (k+1 times) | 0 sig ... sig +| `multi_a(k,key_1,...,key_n)` | 0 ... 0 (n times); ~~[sig/0 with #(sig) ≠ k]~~ | sig/0 with #(sig) = k and #(sigs/0) = n +| `a:X` | dsat(X) | sat(X) +| `s:X` | dsat(X) | sat(X) +| `c:X` | dsat(X) | sat(X) +| `d:X` | 0 | sat(X) 1 +| `v:X` | *(none)* | sat(X) +| `j:X` | 0; ~~[dsat(X) (if nonzero top stack)]~~ | sat(X) +| `n:X` | dsat(X) | sat(X) + +#### Non-malleable Satisfaction Algorithm + +In order to produce non-malleable satisfactions we make use of a function that returns the optimal +satisfaction and dissatisfaction for a given expression (if any exist), or a special DONTUSE ("don't use") value, +together with an optional HASSIG ("has signature") marker that tracks whether the solution contains at least one +signature. To implement the function: +* Invoke the function recursively for all subexpressions, obtaining all their satisfactions/dissatisfactions. +* Iterate over all the valid satisfactions/dissatisfactions in the table above (including the non-canonical ones), taking into account: + * The dissatisfactions for `sha256`, `ripemd160`, `hash256`, and `hash160` are always malleable, so instead use DONTUSE there. + * The non-canonical options for `and_b`, `or_b`, and `thresh` are always overcomplete, so instead use DONTUSE there as well (with HASSIG flag if the original non-canonical solution had one). + * The satisfactions for `pk_k`, `pk_h`, and `multi` can be marked HASSIG. + * When constructing solutions by combining results for subexpressions, the result is DONTUSE if any of the constituent results is DONTUSE. Furthermore, the result gets the HASSIG tag if any of the constituents does. +* If among all valid solutions (including DONTUSE ones) more than one does not have the HASSIG marker, return DONTUSE. +* If instead exactly one does not have the HASSIG marker, return that solution. +* If all valid solutions have the HASSIG marker, but all of them are DONTUSE, return DONTUSE-HASSIG. The HASSIG marker is important because while this represents a choice between multiple options that would cause malleability if used, they are not available to the attacker, and we may be able to avoid them entirely still. +* Otherwise, all not-DONTUSE options are valid, so return the smallest one (in terms of witness size). + +To produce an overall satisfaction, invoke the function on the toplevel expression. If no valid +satisfaction is returned, or it is DONTUSE, fail. Otherwise, if any timelocking is used in the +script but the result does not have the HASSIG flag, also fail. If the satisfaction is both not +DONTUSE and HASSIG, return it. + + +## Discussion + +## Security + +Miniscript primarily aims to provide guarantees on the correctness of a Bitcoin Script. That is, to +guarantee **consensus soundness** and **standardness completeness**. Consensus soundness means +it is not possible to construct a consensus-valid witness for a Bitcoin Script unless the Miniscript +spending conditions are met. Standardness completeness means a standardness-valid witness can be +created for all spending paths of a Miniscript, assuming the resource limits are respected and there +is no timelock mixing. + +Additionally, Miniscript can guarantee the non-malleability and maximum size of a witness. These can +assist in assessing the soundness of protocols where transaction fees (and therefore transaction +size) are security-critical parameters. + +Hash preimages are constrained to 32 bytes to disallow various forms of griefing, including making +non-standard (un-relayable) transactions, consensus-invalid swaps across blockchains, as well as +ensure that satisfaction cost can be accurately calculated. + +In order for these properties to not just apply to script, but to an entire transaction, it's +important that the witness commits to all data relevant for verification. In practice this means +that scripts whose conditions can be met without any digital signature are insecure. Besides being +trivially insecure, note how a transaction lacking a signature check allows an attacker to change +its nLockTime and nSequence fields to meet additional timelock conditions. + +### Type System + +To statically verify the correctness and malleability guarantees discussed in the previous section, +we define a type system. See the specifications above for a reference of each fragment's +requirements and properties. Here we give more information about each type. + +Every expression has one of four basic types: +* "**B**" Base expressions. These take their inputs from the top of the stack. When satisfied, they push a nonzero value of up to 4 bytes onto the stack. When dissatisfied, they push an exact 0 onto the stack (if dissatisfaction without aborting is possible at all). This type is used for most expressions, and required for the top level expression. An example is `older(n)` = `<n> CHECKSEQUENCEVERIFY`. +* "**V**" Verify expressions. Like "B", these take their inputs from the top of the stack. Upon satisfaction however, they continue without pushing anything. They cannot be dissatisfied (will abort instead). A "V" can be obtained using the `v:` wrapper on a "B" expression, or by combining other "V" expressions using `and_v`, `or_i`, `or_c`, or `andor`. An example is `v:pk(key)` = `<key> CHECKSIGVERIFY`. +* "**K**" Key expressions. They again take their inputs from the top of the stack, but instead of verifying a condition directly they always push a public key onto the stack, for which a signature is still required to satisfy the expression. A "K" can be converted into a "B" using the `c:` wrapper. An example is `pk_h(key)` = `DUP HASH160 <Hash160(key)> EQUALVERIFY`. +* "**W**" Wrapped expressions. They take their inputs from one below the top of the stack, and push a nonzero (in case of satisfaction) or zero (in case of dissatisfaction) either on top of the stack, or one below. So for example a 3-input "W" would take the stack "A B C D E F" and turn it into "A B F 0" or "A B 0 F" in case of dissatisfaction, and "A B F n" or "A B n F" in case of satisfaction (with n a nonzero value). Every "W" is either `s:B` (SWAP B) or `a:B` (TOALTSTACK B FROMALTSTACK). An example is `s:pk(key)` = `SWAP <key> CHECKSIG`. + +Then there are 6 type modifiers, which guarantee additional properties: +* "**z**" Zero-arg: this expression always consumes exactly 0 stack elements. +* "**o**" One-arg: this expression always consumes exactly 1 stack element. +* "**n**" Nonzero: this expression always consumes at least 1 stack element, no satisfaction for this expression requires the top input stack element to be zero. +* "**d**" Dissatisfiable: a dissatisfaction for this expression can unconditionally be constructed. This implies the dissatisfaction cannot include any signature or hash preimage, and cannot rely on timelocks being satisfied. +* "**u**" Unit: when satisfied, this expression will put an exact 1 on the stack (as opposed to any nonzero value). +* "**k**" No timelock mixing. This expression does not contain a mix of heightlock and timelock of the same type. If the miniscript does not have the "k" property, the miniscript template will not match the user expectation of the corresponding spending policy. + +Finally to analyze malleability guarantees we introduce 3 new type modifiers: +* "**s**" Signed: satisfying this expression always requires a signature (predicting whether all satisfactions will be HASSIG). +* "**f**" Forced: dissatisfying this expression always requires a signature (predicting whether all dissatisfactions will be HASSIG). +* "**e**" Expressive: this requires a unique unconditional dissatisfaction to exist, and forces all conditional dissatisfactions (if any) to require a signature. + + +### Malleability + +Since Segwit, malleating a transaction no longer breaks the validity of unconfirmed descendant +transactions. However, unintentional malleability may still have a number of much weaker undesirable +effects. If a witness can be stuffed with additional data, the transaction's feerate will go down, +potentially to the point where its ability to propagate and get confirmed is impacted. Additionally, +malleability can be exploited to add roundtrips to BIP152 block propagation, by trying to get +different miners to mine different versions of the same transaction. Finally, malleability may +interfere with the usage of hash locks as a mechanism for publishing preimages. + +Using the malleability type properties it is possible to determine statically whether a script can +be non-malleably satisfied under all circumstances. In many cases it is reasonable to only accept +such guaranteed-non-malleable scripts, as unexpected behavior can occur when using other scripts. + +For example, when running the non-malleable satisfaction algorithm above, adding available +preimages, or increasing the nLockTime/nSequence values actually may make it fail where it succeeded +before. This is because a larger set of met conditions may mean an existing satisfaction goes from +non-malleable to malleable. Restricting things to scripts that are guaranteed to be satisfiable in a +non-malleable way avoids this problem. + +When analysing Miniscripts for resource limits, restricting yourself to just non-malleable solutions +(or even non-malleable scripts) also leads to tighter bounds, as all non-canonical satisfactions and +dissatisfactions can be left out of consideration. + +The malleability analysis makes the following assumptions: +* The attacker does not have access to any of the private keys of public keys that participate in the Script. Participants with private keys inherently have the ability to produce different satisfactions by creating multiple signatures. While it is also interesting to study the impact rogue participants can have, we treat it as a distinct problem. +* The attacker only has access to hash preimages that honest users have access to as well. This is a reasonable assumption because hash preimages are revealed once globally, and then available to everyone. On the other hand, making the assumption that attackers may have access to more preimages than honest users makes a large portion of scripts impossible to satisfy in a non-malleable way. +* The attacker gets to see exactly one satisfying witness of any transaction. If he sees multiple, it becomes possible for the attacker to mix and match different satisfactions. This is very hard to reason about. +* We restrict this analysis to scripts where no public key is repeated. If signatures constructed for one part of the script can be bound to other checks in the same script, a variant of the mixing from the previous point becomes available that is equally hard to reason about. Furthermore this situation can be avoided by using separate keys. +* The attacker is constrained by common standardness rules. A miner may be able to malleate a witness considered non-malleable by Miniscript. + +#### Non-Malleable Satisfaction + +Malleable satisfactions or dissatisfactions appear whenever options are available to attackers distinct from the one taken by honest users. This can happen for multiple reasons: +1. Two or more options for a satisfaction or dissatisfaction are listed in the table above which are both available to attackers directly. Regardless of which option is used in the honest solution, the attacker can change the solution to the other one. +2. Two or more options for a satisfaction or dissatisfaction are listed in the table above, only one of which is available to attackers, but the honest solution uses another one. In that case, the attacker can modify the solution to pick the one available to him. +3. The honest users pick a solution that contains a satisfaction which can be turned into a dissatisfaction without invalidating the overall witness. Those are called overcomplete solutions. + +Because we assume attackers never have access to private keys, we can treat any solution that +includes a signature as one that is unavailable to attackers. For others, the worst case is that the +attacker has access to every solution the honest users have, but no others: for preimages this is an +explicit assumption, while timelock availability is determined by the nLockTime and nSequence fields +in the transaction. As long as the overall satisfaction includes at least one signature, those +values are fixed, and timelock availability is identical for attackers and honest users. + +The description of the non-malleable satisfaction algorithm can be used to show that no +non-canonical solutions listed in the satisfaction table can occur inside non-malleable +satisfaction: +* Some of the non-canonical options (the `or_b`, `and_b`, and `thresh` ones) are overcomplete, and thus can clearly not appear in non-malleable satisfactions. +* The fact that non-"d" expressions cannot be dissatisfied in valid witnesses rules out the usage of the non-canonical `and_v` dissatisfaction. +* "d" expressions are defined to be unconditionally dissatisfiable, which implies that for those a non-HASSIG dissatisfaction must exist. Non-HASSIG solutions must be preferred over HASSIG ones (reason 2), and when multiple non-HASSIG ones exist, none can be used (reason 1). This lets us rule out the other non-canonical options in the table: + * `j:X` is always "d", its non-HASSIG dissatisfaction "0" always exists, and thus rules out any usage of "dsat(X)". + * If `andor(X,Y,Z)` is "d", a non-HASSIG dissatisfaction "dsat(Z) dsat(X)" must exist, and thus rules out any usage of "dsat(Y) sat(X)". + * If `and_b(X,Y)` is "d", a non-HASSIG dissatisfaction "dsat(Y) dsat(X)" must exist, and thus rules out any usage of "dsat(Y) sat(X)" and "sat(Y) dsat(X)". Those are also overcomplete. + * `thresh(k,...)` is always "d", a non-HASSIG dissatisfaction with just dissatisfactions must exist due to typing rules, and thus rules out usage of the other dissatisfactions. They are also overcomplete. + + +### Resource Limits + +Various types of Bitcoin Scripts have different resource limitations, either through consensus or standardness. Some of them affect otherwise valid Miniscripts: +* In P2WSH, scripts larger than 3600 bytes are invalid by standardness. In Tapscript, scripts are implicitly bounded by the maximum size of a block (1 million virtual bytes). +* In P2WSH, script satisfactions where the total number of non-push opcodes plus the number of keys participating in all executed `CHECKMULTISIG` is above 201 are invalid by consensus. +* In both Tapscript and P2WSH, script satisfactions which make the stack exceed 1000 elements before or during execution are invalid. +* In P2WSH, satisfactions with a witness consisting of over 100 stack elements (excluding the script itself) are invalid by standardness. + +A static analysis can be performed on a Miniscript to verify if none, all or any of the spending +paths hit any of the limits. + + +## Test Vectors + +TBD + +## Backwards Compatibility + +Miniscript's syntax is compatible with BIP 380 Output Script Descriptors, and should be considered +an extension to it that provides a new type of Script expression that is only valid in +`wsh()` and `tr()` contexts. As these are wholly new expressions, they are not +compatible with any existing implementation of descriptors. Additionally, the scripts produced are +unlikely to be standard scripts. + +The `pk()`, `pkh()`, `multi()`, and `multi_a()` +fragments overlap with existing descriptors. These parse to the same semantic meanings as those +descriptors and produce the same scripts. + +## Reference Implementation + +A first reference implementation and documentation for Miniscript in P2WSH was originally published at +https://github.com/sipa/miniscript . + +The reference implementation for Miniscript in P2WSH was introduced in Bitcoin Core through PRs +[24147](https://github.com/bitcoin/bitcoin/pull/24147), [24148](https://github.com/bitcoin/bitcoin/pull/24148), and +[24149](https://github.com/bitcoin/bitcoin/pull/24149). The last one to be merged was released in Bitcoin +Core version 25.0. + +The reference implementation for Miniscript in Tapscript was introduced in Bitcoin Core in PR +[27255](https://github.com/bitcoin/bitcoin/pull/27255). This PR was merged and released in Bitcoin Core +version 26.0. diff --git a/bip-0380.mediawiki b/bip-0380.mediawiki index 27b7908..eea5ce1 100644 --- a/bip-0380.mediawiki +++ b/bip-0380.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0380 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause @@ -212,7 +212,7 @@ The following tests cover the checksum and character set: * Error in checksum: <tt>raw(deedbeef)##9f8spxm</tt> * Invalid characters in payload: <tt>raw(Ü)#00000000</tt> -The following tests cover key expressions: +The following tests cover key expressions: Valid expressions: @@ -332,4 +332,7 @@ This Table lists all available Script expressions and the BIPs specifying them. |- | <tt>tr(KEY)</tt>, <tt>tr(KEY, TREE)</tt> | [[bip-0386.mediawiki|386]] +|- +| <tt>musig(KEY, KEY, ..., KEY)</tt> +| [[bip-0390.mediawiki|390]] |} diff --git a/bip-0381.mediawiki b/bip-0381.mediawiki index bfda2c8..8d12c7a 100644 --- a/bip-0381.mediawiki +++ b/bip-0381.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0381 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause diff --git a/bip-0382.mediawiki b/bip-0382.mediawiki index bb1951d..261b7e3 100644 --- a/bip-0382.mediawiki +++ b/bip-0382.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0382 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause diff --git a/bip-0383.mediawiki b/bip-0383.mediawiki index 66e2f16..522eb0c 100644 --- a/bip-0383.mediawiki +++ b/bip-0383.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0383 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause diff --git a/bip-0384.mediawiki b/bip-0384.mediawiki index ba12b55..585af5e 100644 --- a/bip-0384.mediawiki +++ b/bip-0384.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0384 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause diff --git a/bip-0385.mediawiki b/bip-0385.mediawiki index 3e922b3..1686ef7 100644 --- a/bip-0385.mediawiki +++ b/bip-0385.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0385 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause diff --git a/bip-0386.mediawiki b/bip-0386.mediawiki index 759887d..55f0d15 100644 --- a/bip-0386.mediawiki +++ b/bip-0386.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0386 - Status: Draft + Status: Final Type: Informational Created: 2021-06-27 License: BSD-2-Clause diff --git a/bip-0387.mediawiki b/bip-0387.mediawiki index 5c039b8..0f8c88d 100644 --- a/bip-0387.mediawiki +++ b/bip-0387.mediawiki @@ -6,7 +6,7 @@ Ava Chow <me@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0387 - Status: Draft + Status: Final Type: Informational Created: 2024-04-17 License: BSD-2-Clause diff --git a/bip-0388/wallet_policies.py b/bip-0388/wallet_policies.py index 4cd5031..754d201 100755 --- a/bip-0388/wallet_policies.py +++ b/bip-0388/wallet_policies.py @@ -142,7 +142,7 @@ class WalletPolicy(object): continue if op in operators_key_all_but_first: - # skip the first argument (we now it's not a KEY expression, so it does not have a comma) + # skip the first argument (we know it's not a KEY expression, so it does not have a comma) first_comma_pos = descriptor.find(",", op_pos_start) if first_comma_pos == -1: raise Exception( diff --git a/bip-0389.mediawiki b/bip-0389.mediawiki index 500d7e3..6c88a89 100644 --- a/bip-0389.mediawiki +++ b/bip-0389.mediawiki @@ -36,7 +36,7 @@ For extended keys and their derivations paths in a Key Expression, BIP 380 state ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path elements indicating BIP 32 derivation steps to be taken after the given extended key. ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final step to denote all direct unhardened or hardened children. -This is modifed to state: +This is modified to state: * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded extended private key (as defined in BIP 32) ** Followed by zero or more <tt>/NUM</tt> (may be followed by <tt>h</tt>, <tt>H</tt>, or <tt>'</tt> to indicate a hardened step) path elements indicating BIP 32 derivation steps to be taken after the given extended key. @@ -48,6 +48,7 @@ This is modifed to state: When a <tt>/<NUM;NUM;...;NUM></tt> is encountered, parsers should account for a presence of multiple descriptors where the first descriptor uses the first <tt>NUM</tt>, and a second descriptor uses the second <tt>NUM</tt>, and so on, until each <tt>NUM</tt> is accounted for in the production of public keys, scripts, and addresses, as well as descriptor import and export operations. Descriptors that contain multiple Key Expressions that each have a <tt>/<NUM;NUM;...;NUM></tt> must have tuples of exactly the same length so that they are derived in lockstep in the same way that <tt>/*</tt> paths in multiple Key expressions are handled. +Duplicate <tt>NUM</tt>s within a tuple are not allowed. The common use case for this is to represent descriptors for producing receiving and change addresses. When interpreting for this use case, wallets should use the first descriptor for producing receiving addresses, and the second descriptor for producing change addresses. diff --git a/bip-0390.mediawiki b/bip-0390.mediawiki new file mode 100644 index 0000000..1024fb7 --- /dev/null +++ b/bip-0390.mediawiki @@ -0,0 +1,117 @@ +<pre> + BIP: 390 + Layer: Applications + Title: musig() Descriptor Key Expression + Author: Ava Chow <me@achow101.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0390 + Status: Draft + Type: Informational + Created: 2024-01-15 + License: CC0-1.0 +</pre> + +==Abstract== + +This document specifies a <tt>musig()</tt> key expression for output script descriptors. +<tt>musig()</tt> expressions take multiple keys and produce an aggregate public key using BIP 327. + +==Copyright== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +==Motivation== + +BIP 327 introduces the MuSig2 Multi-Signature scheme. It is useful to have a way for keys to be used +in a MuSig2 aggregate key to be expressed in descriptors so that wallets can more easily use MuSig2. + +==Specification== + +A new key expression is defined: <tt>musig()</tt>. + +===<tt>musig(KEY, KEY, ..., KEY)</tt>=== + +The <tt>musig(KEY, KEY, ..., KEY)</tt> expression can only be used inside of a <tt>tr()</tt> +expression as a key expression. It additionally cannot be nested within another <tt>musig()</tt> +expression. Repeated participant public keys are not allowed. The aggregate public key is produced +by using the <tt>KeyAgg</tt> algorithm on all KEYs specified in the expression after performing all +specified derivation. As with script expressions, KEY can contain child derivation specified by +<tt>/*</tt>. A new aggregate public key will be computed for each child index. Keys must be sorted +with the <tt>KeySort</tt> algorithm after all derivation and prior to aggregation<ref>'''Why must +the keys be sorted prior to aggregation?''' Although the descriptor's written form sets an order +for the keys that could be used for aggregation, the order should not matter as MuSig2 philosophically +operates over a set of keys, with the order merely being an implementation detail in aggregation +itself. Requiring sorting of keys prior to aggregation enforces this philosophy as keys can be +written in the descriptor in any order with the end result still being the same. Furthermore, this +aids with recovery where the descriptor was not backed up as users will not need to also have +backed up, or guess, the correct order of keys.</ref>. + +===<tt>musig(KEY, KEY, ..., KEY)/NUM/.../*</tt>=== + +<tt>musig(KEY, KEY, ..., KEY)/NUM/.../*</tt> expressions are also allowed, with the same usage +restrictions as in the previous section. The aggregate public key +is first computed as described above, with the keys also being sorted after all derivation and prior +to aggregation. Then further BIP 32 derivation will be performed on the aggregate public key as described in +[[bip-0328.mediawiki|BIP 328]]. As there is no aggregate private key, +only unhardened derivation from the aggregate public key is allowed, and thus the derivation steps +following the <tt>musig()</tt> expression cannot contain +<tt>/NUMh</tt> or <tt>/NUM'</tt> derivation steps nor <tt>/*h</tt>, or <tt>/*'</tt> child derivation. +For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from +xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>. + +==Test Vectors== + +Valid descriptors containing followed by the scripts they produce. Descriptors involving derived child keys +will have the 0th, 1st, and 2nd scripts listed. + +* <tt>rawtr(musig(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +** <tt>5120789d937bade6673538f3e28d8368dda4d0512f94da44cf477a505716d26a1575</tt> +* <tt>tr(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +** <tt>512079e6c3e628c9bfbce91de6b7fb28e2aec7713d377cf260ab599dcbc40e542312</tt> +* <tt>rawtr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*)</tt> +** <tt>51209508c08832f3bb9d5e8baf8cb5cfa3669902e2f2da19acea63ff47b93faa9bfc</tt> +** <tt>51205ca1102663025a83dd9b5dbc214762c5a6309af00d48167d2d6483808525a298</tt> +** <tt>51207dbed1b89c338df6a1ae137f133a19cae6e03d481196ee6f1a5c7d1aeb56b166</tt> +* <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*,pk(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9))</tt> +** <tt>51201d377b637b5c73f670f5c8a96a2c0bb0d1a682a1fca6aba91fe673501a189782</tt> +** <tt>51208950c83b117a6c208d5205ffefcf75b187b32512eb7f0d8577db8d9102833036</tt> +** <tt>5120a49a477c61df73691b77fcd563a80a15ea67bb9c75470310ce5c0f25918db60d</tt> +* <tt>tr(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,pk(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*))</tt> +** <tt>512068983d461174afc90c26f3b2821d8a9ced9534586a756763b68371a404635cc8</tt> +** <tt>5120368e2d864115181bdc8bb5dc8684be8d0760d5c33315570d71a21afce4afd43e</tt> +** <tt>512097a1e6270b33ad85744677418bae5f59ea9136027223bc6e282c47c167b471d5</tt> + +Invalid descriptors + +* <tt>musig()</tt> is not allowed in <tt>pk()</tt>: <tt>pk(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +* <tt>musig()</tt> is not allowed in <tt>pkh()</tt>: <tt>pkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +* <tt>musig()</tt> is not allowed in <tt>wpkh()</tt>: <tt>wpkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +* <tt>musig()</tt> is not allowed in <tt>combo()</tt>: <tt>combo(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +* <tt>musig()</tt> is not allowed in <tt>sh(wpkh())</tt>: <tt>sh(wpkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)))</tt> +* <tt>musig()</tt> is not allowed in <tt>sh(wsh())</tt>: <tt>sh(wsh(pk(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))))</tt> +* <tt>musig()</tt> is not allowed in <tt>wsh()</tt>: <tt>wsh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +* <tt>musig()</tt> is not allowed in <tt>sh()</tt>: <tt>sh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt> +* Ranged <tt>musig()</tt> requires all participants to be xpubs: <tt>tr(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)/0/0)</tt> +* Cannot have ranged participants if <tt>musig()</tt> is also ranged: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*)</tt> +* <tt>musig()</tt> cannot have hardened derivation steps: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0h/*)</tt> +* <tt>musig()</tt> cannot have hardened child derivation: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*h)</tt> + +==Backwards Compatibility== + +<tt>musig()</tt> expressions use the format and general operation specified in +[[bip-0380.mediawiki|BIP 380]]. As these are a set of wholly new expressions, they are not compatible +with any implementation. However the keys are produced using a standard process so existing software +are likely to be familiar with them. + +==Rationale== + +<references/> + +==Reference Implementation== + +TBD + +==Acknowledgements== + +Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who +participated in discussions on this topic. diff --git a/bip-0431.mediawiki b/bip-0431.mediawiki new file mode 100644 index 0000000..2af0e53 --- /dev/null +++ b/bip-0431.mediawiki @@ -0,0 +1,291 @@ +<pre> + BIP: 431 + Layer: Applications + Title: Topology Restrictions for Pinning + Author: Gloria Zhao <gloriajzhao@gmail.com> + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0431 + Status: Draft + Type: Informational + Created: 2024-01-10 + License: BSD-3-Clause + Post-History: 2022-01-27: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html [bitcoin-dev] discussion + 2022-01-27: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff gist discussion + 2022-09-23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [bitcoin-dev] proposal + 2024-01-02: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin post + 2024-01-16: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Delving Bitcoin post +</pre> + +==Abstract== + +This document describes pinning problems that can arise from limitations in mempool policy. + +It also describes a type of policy with adjusted topology limits which, combined with other policy rules, helps minimize the potential pinning problems. These restrictions simplify the assessment of incentive compatibility of accepting or replacing such transactions, thus helping ensure any replacements are more profitable for the node. Within the context of nodes that implement this policy, fee-bumping is more reliable for users. + +==Motivation== + +Mempools typically accept and relay transactions that spend outputs from other unconfirmed transactions, but restrict package sizes through ancestor and descendant limits +<ref>https://github.com/bitcoin/bitcoin/blob/632a2bb731804dffe52bd4cbd90bfee352d25ede/doc/policy/mempool-limits.md</ref> +to limit the computational complexity of mempool operations and mitigate Denial of Service attacks. + +Users may also create unconfirmed transactions that conflict with -- or are "double spends" of -- each other by spending the same input(s) in both. +Instead of always keeping the first-seen transaction, many mempools also have some kind of Replace by Fee (RBF) policy +<ref> +[https://github.com/bitcoin/bitcoin/blob/632a2bb731804dffe52bd4cbd90bfee352d25ede/doc/policy/mempool-replacements.md Bitcoin Core's RBF policy] at the time of writing. It is slightly different from what is described in BIP 125. +</ref> +to keep the more incentive compatible transaction, i.e. one that would earn a miner more fees. Users utilize these rules when they create higher feerate double-spends (replacements) to expedite confirmation of their transactions. + +However, these policies make imperfect trade-offs between incentive compatibility and DoS-resistance. For example, malicious actors may sometimes exploit limitations to prevent incentive-compatible transactions from being accepted or fee-bumped (''pinning''). + +Pinning is consequential to contracting protocols in which untrusted parties construct and sign time-sensitive transactions to be broadcast on-chain later +<ref>Posts about pinning in LN and LN-Symmetry: +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html "Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning"] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html "RBF Pinning with Counterparties and Competing Interest"] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html "Pinning : The Good, The Bad, The Ugly"] +* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md "Pinning Attacks"] +* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 "Eltoo Pinning"] +</ref>. +When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is crucial to the security of the protocol. + +===RBF pinning through absolute fees=== + +Imagine that counterparties Alice and Mallory have transactions (or packages) A and B, respectively, which conflict with each other. Alice broadcasts A and Mallory broadcasts B. RBF rules require the replacement transaction pay a higher absolute fee than the aggregate fees paid by all original transactions ([https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy "Rule 3"]). This means Mallory may increase the fees required to replace B beyond what Alice was planning to pay for A's fees. + +1. Adding transaction(s) that descend from B and pay a low feerate (too low to fee-bump B through CPFP)<ref>Example: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022216.html</ref>. + +2. Adding a high-fee descendant of B that also spends from another large, low-feerate mempool transaction (where the fee of the descendant is too low to fee-bump both B and its other parent through CPFP)<ref>Example: https://github.com/bitcoin/bitcoin/pull/25038#issuecomment-1320295394</ref>. + +===RBF pinning through number of conflicts=== + +RBF rules require that no replacement trigger the removal of more than 100 transactions ([https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy "Rule 5"]). This number includes the descendants of the conflicted mempool transactions. Mallory can make it more difficult to replace transactions by attaching lots of descendants to them. For example, if Alice wants to batch-replace 5 transactions but each has 21 descendants, her replacement will be rejected regardless of its fees. + +===RBF incentive compatibility requirements=== + +There is currently no effective rule to enforce that a replacement transaction would be more incentive compatible to keep in the mempool. It is difficult to quantify the incentive compatibility of a set of transactions, especially in comparison with another set of transactions<ref>https://delvingbitcoin.org/t/mempool-incentive-compatibility/553</ref>, but the requirement of a feerate increase ([https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy "Rule 6"]) is far too simplistic. + +For example, a user could create a replacement transaction that pays more fees and is higher feerate, but has a low feerate ancestor and would confirm slower than the original transaction. As a result, all transactions signed with SIGHASH_ANYONECANPAY are vulnerable to being replaced by a transaction that will confirm later than the original<ref>https://github.com/bitcoin/bitcoin/pull/23121#pullrequestreview-766271585</ref>. + +===Child fees don't count towards RBF rules=== + +A transaction must meet all fee-related requirements (Rules 3, 4, 6) alone; its child's fees cannot be used. A ''Package RBF'' policy would allow a transaction's child to be used for its RBF requirements. + +In LN Penalty, conflicting commitment transactions signed with the same fees cannot replace each other, even if accompanied by a fee-bumping child. This limitation necessitates the presence of two anchor outputs, allowing both parties to fee-bump either commitment transaction that enters their mempool. + +===Package limit pinning and replacing CPFP Carve Out=== + +Mempool policies limit the number and total virtual size of an unconfirmed transaction's descendants. A fee-bumping child of an unconfirmed transaction (CPFP) may be rejected for exceeding the descendant limit. When a transaction has multiple outputs owned by different parties, a malicious party can prevent the other(s) from CPFPing their transaction by attaching enough descendants to monopolize the descendant limit (''package limit pinning''). + +LN commitment transactions rely on CPFP carve out <ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html "CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)"]</ref> to avoid package limit pinning. + +There are weaknesses with this approach of using 2 anchors and CPFP Carve Out. This proposal helps address a few of them (see Related Work for how other weaknesses are addressed): + +* Cluster Mempool necessitates the removal of CPFP Carve Out <ref>https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12</ref>. +* CPFP Carve Out only allows ''one more'' child to be added to the transaction. This means it cannot guarantee the ability to CPFP for more than 2 parties of a shared transaction. + +==Topologically Restricted Until Confirmation== + +This section describes one approach for opt-in policy rules that can realistically be deployed today and is useful to today's applications. +It is based on the idea that most limitations stem from existing ancestor/descendant package limits being too permissive for the majority of use cases. + +The scope of the policy's anti-pinning benefits is limited to the individual node's mempool, and the degree to which a user's transaction is safe from pinning depends how much of the network has adopted this policy. + +Similarly, there are multiple approaches to creating a policy to minimize pinning, more may become available over time (see Related Work section), and the details of this approach can be tweaked if conditions change. For example, if loosening one of the topology restrictions enables a new use case while still providing acceptable pinning bounds, it can be changed. + +===Specification=== + +Senders can signal that they want a transaction to be Topologically Restricted Until Confirmation (TRUC). Specifically, set <code>nVersion=3</code>. +A node that implements this policy would apply their existing standardness and policy rules, along with the following set of rules, to TRUC transactions: + +1. A TRUC transaction signals replaceability, even if it does not signal BIP125 replaceability. + +2. Any TRUC transaction's unconfirmed ancestors must all be TRUC. Any descendant of an unconfirmed TRUC transaction must also be TRUC. +<ref>Rationale: +* Requiring packages to be all-or-none TRUC makes it possible to enforce the topology limits. For example, the TRUC descendant limit would not be very meaningful if it could be bypassed by creating a non-TRUC child. +* Combined with Rule 1, this requirement creates "inherited signaling" when descendants of unconfirmed transactions are created. Checking whether a transaction signals replaceability this way does not require mempool traversal, and does not change based on what transactions are mined. +</ref> +Note: A TRUC transaction can spend outputs from ''confirmed'' non-TRUC transactions. A non-TRUC transaction can spend outputs from ''confirmed'' TRUC transactions. + +3. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed descendant. CPFP Carve Out is not granted to TRUC transactions. +<ref>Rationale: +* The larger the descendant limit, the more transactions may need to be replaced. See #1 in Rule 3 Pinning section above. This also makes pinning using Rule 5 more difficult, since a directly conflicting transaction has fewer possible descendants. +* These two limits (ancestor count 2, descendant count 2) effectively create a cluster limit using the existing ancestor and descendant limits. Increasing them to 3 would imply an infinite cluster count limit. +* This 1-parent-1-child topology makes it possible to use ancestor score (minimum of ancestor feerate and individual feerate) as a measure of incentive compatibility. + +<br />Q: Why not allow multiple parents to enable batched fee-bumping? +<br />To mitigate pinning through absolute fees, we need to prevent a child of an unconfirmed TRUC transaction from bringing in more unconfirmed ancestors. See #2 in "RBF pinning through absolute fees" section above. + +<br />Q: Why not allow another child? +<br />Allowing another child disables the ability to use ancestor score to measure incentive compatibility. Imagine the original transaction, A, has a child B and co-parent C (i.e. B spends from A and C). C also has another child, D. B is one of the original transactions and thus its ancestor feerate must be lower than the package's feerate. However, this may be an underestimation because D can bump C without B's help. This is resolved if TRUC transactions can only have TRUC ancestors, as then C cannot have another child. + +<br />Q: Why allow any descendants at all? +<br />At least 1 descendant is required to allow CPFP of the presigned transaction. Without package RBF, multiple anchor outputs would be required to allow each counterparty to fee-bump any presigned transaction. With package RBF, since the presigned transactions can replace each other, 1 anchor output is sufficient. +</ref> + +4. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000 vB. +<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for payments, HTLCs, or other uses of the transaction. Generally, having a smaller maximum size helps to better define bounds for algorithms and memory usage, and the existing limit of 100,000 vB seems much larger than necessary. +</ref> + +5. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000 vB. +<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for inputs to fund the transaction. +<br />Q: Why not bigger? +<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000 vB, that might be an additional 100,000 sats (at 1 sat/vbyte) or more, depending on the feerate. Restricting all children to 1000 vB reduces the upper bound of the additional fees by a factor of 100. + +<br />This rule is also easily tacked on to existing logic for policy and wallets. A maximum size standard transaction (100 kvB) can have up to 1000 vB of descendants to be within the default descendant limit (101 kvB). + +<br />Q: Why not smaller? +<br/>The smaller this limit, the fewer UTXOs a child may use to fund this fee-bump. For example, only allowing the TRUC child to have 2 inputs would require wallets to maintain a pool of high-value confirmed UTXOs. However, as the fee-bumping child only needs to fund fees (as opposed to payments), just a few UTXOs should suffice. With a limit of 1000 vB and usage of taproot outputs, the child can have 15 inputs and 2 outputs (calculated using [https://bitcoinops.org/en/tools/calc-size/ this tool]). +</ref> + +6. An individual TRUC transaction is permitted to be below the mempool min relay feerate, assuming it is considered within a package that meets the mempool's feerate requirements. +<ref>Rationale: This allows contracting protocols to create presigned transactions with 0 fees and fee-bump them using CPFP at broadcast time. +</ref> + +====Implementation==== + +* https://github.com/bitcoin/bitcoin/pull/28948 +* https://github.com/bitcoin/bitcoin/pull/29873 +* https://github.com/bitcoin/bitcoin/pull/29496 + +====Related Work==== + +This 1-parent-1-child (aka cluster size 2) topology restriction makes the transactions much easier to reason about, which enables additional features like +feerate diagram comparisons +<ref> +[https://github.com/bitcoin/bitcoin/pull/29242 this PR] implements feerate diagram creation and comparison for sets of transactions in which the maximum cluster size is 2, e.g. all TRUC transactions. +</ref>, +package RBF +<ref> +[https://github.com/bitcoin/bitcoin/pull/28984 this PR] implements package RBF, enforcing incentive compatibility by comparing the feerate diagrams of the mempool before and after replacement. The feerate diagrams are easy to build when the relevant clusters are of size 2 and below, so package RBF is restricted to those scenarios. As TRUC transactions always have this property, package RBF is enabled for TRUC transactions. +</ref>, +and sibling eviction +<ref> +[https://github.com/bitcoin/bitcoin/pull/29306 This PR] implements sibling eviction for TRUC transactions: if a new transaction would exceed a transaction's descendant limit, it considers evicting the existing descendant using replacement rules. Sibling eviction is feasible for TRUC transactions because there is no difficulty in identifying which descendant to evict (there can only be 1). +</ref>. + +The [https://github.com/bitcoin/bips/pull/1524 Ephemeral Anchors] proposal builds on top of this one to add more features. +It changes the anchor script to be anyone can spend, allowing anybody to add fees and reducing the onchain footprint and fee costs. +It also allows anchor outputs to have 0 value, eliminating the need to deduct value from the input amount in order to create anchors. + +The [https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/7 Cluster Mempool] proposal makes fundamental changes to mempool structure and policy rules, enabling the accurate assessment of the incentive compatibility of accepting or removing a transaction, among other things. Notably, Cluster Mempool introduces a limit to all transactions' cluster size to make incentive compatibility calculations feasible. This cluster limit is similar to TRUC limits in that it bounds computation to enable improved policies, but is applied to all transactions (not just ones that opt in) and is much less restrictive than TRUC limits. + +Cluster Mempool provides a more holistic solution to some of the problems listed (such as adding an incentive compatibility requirement to RBF and safely enabling package RBF for more complex topologies). However, it does not help resolve all problems (such as RBF Pinning through absolute fees and number of conflicts). Also, since Cluster Mempool is incompatible with CPFP Carve Out<ref>https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12</ref>, TRUC with sibling eviction and package RBF provide an alternative solution to applications that rely on it. + +Building on top of Cluster Mempool, there are also various ideas for extending TRUC transactions and creating another anti-pinning policy +<ref>https://delvingbitcoin.org/t/v3-and-some-possible-futures/523/3</ref>. + +[https://bitcoinops.org/en/topics/package-relay Package Relay] includes changes in p2p protocol, transaction relay logic, and mempool policy to enable nodes to accept and relay packages of transactions. Much of this proposal's utility relies on the existence of package relay for 1-parent-1-child packages (the topology TRUC supports). + +====Backward Compatibility==== + +Transactions with <code>nVersion=3</code> were previously nonstandard. There are no known conflicts with previous usage. + +====Intended Usage==== + +Generally, users with no interest in spending unconfirmed outputs from a transaction can make them TRUC transactions for more robust RBF abilities. + +This proposal allows for a different solution to fee-bumping in LN, in which commitment transactions are signed with 0 fees and include a single anchor that can later be used to add fees at broadcast time +<ref>Proposals for changes to LN commitment transaction format using TRUC and a single anchor: +* [https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "Lightning transactions with v3 and ephemeral anchors"] +* [https://github.com/instagibbs/bolts/commits/zero_fee_commitment bolts proposal branch] +* See "Intended usage for LN" section in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html "New transaction policies (nVersion=3) for contracting protocols"] +</ref>. +A similar fee-bumping model can also be used in other contracting protocols +<ref>Examples of non-LN protocols that have shown interest in, designed, or built fee-bumping using TRUC: +* A LN-Symmetry implementation using TRUC and ephemeral anchors: [https://delvingbitcoin.org/t/ln-symmetry-project-recap/359 LN-Symmetry Project Recap] [https://github.com/instagibbs/lightning/tree/eltoo_support branch] +* See "Managing Fees Safely" mentioning ephemeral anchors in [https://jameso.be/vaults.pdf "Vaults and Covenants"] +</ref>. + +==Alternatives== + +Various alternatives for RBF +<ref>Proposals and discussions dedicated to improving RBF: +* [https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff "RBF Improvements"] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html "Improving RBF Policy"] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016998.html "[PROPOSAL] Emergency RBF (BIP 125)"] +</ref> +and new fee-bumping mechanisms +<ref> +<br />Proposals and discussions dedicated to improving or creating new fee-bumping mechanisms: +* [https://github.com/lightning/bolts/pull/1036 "Add option to sign commitments at various feerates"] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html "A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent"] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html "A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring"] +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html "Thoughts on fee bumping"] +</ref> +have been proposed across multiple discussion threads. +Most alternatives do not conflict with TRUC, and some work in conjunction with this proposal - see Related Work. +A few popular ideas that were not incorporated into this work are summarized here. + +===Alternatives: add static incentive compatibility rule in RBF policy=== + +Add incentive compatibility requirement to RBF policy using some existing score or static calculation +<ref>Examples of incentive compatibility score proposals and suggestions: +* [https://github.com/bitcoin/bitcoin/pull/23121 "check ancestor feerate in RBF, remove BIP125 Rule2"] +* [https://github.com/bitcoin/bitcoin/pull/26451 "Enforce incentive compatibility for all RBF replacements"] +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019841.html +* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349 +</ref>. + +As the incentive compatibility "score" of a transaction must be dynamically calculated given the structure of mempools today, there is no satisfactory solution. A full calculation is too computationally expensive. Static values can overestimate or underestimate, leading to more pinning problems <ref>Four examples of static calculations and an example in which they are all inaccurate: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff#mining-score-of-a-mempool-transaction</ref>. +The ability to calculate incentive compatibility scores efficiently is a primary feature and motivation for both TRUC transactions and Cluster Mempool. + +===Alternatives: replace by feerate=== + +"Instead of using Rule 3 and/or 4 (requiring an increase in absolute fees), allow replacements with a higher feerate." + +One variation of this proposal is to apply this rule in certain exceptional scenarios or when the replacement would confirm "soon" +<ref>Examples of Replace by Feerate proposals and suggestions: +* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016998.html "[PROPOSAL] Emergency RBF (BIP 125)"] +* [https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff#fees-in-next-block-and-feerate-for-the-rest-of-the-mempool] +* [https://petertodd.org/2024/one-shot-replace-by-fee-rate "One-Shot Replace-by-Fee-Rate"] +</ref>. + +The primary problem with these proposals is the potential for free relay and DDoS attacks. + +Removing Rule 3 and 4 in general would allow free relay +<ref>Examples of free relay with the removal of Rule 3 and/or 4: +<br/> Consider a rule where the fee can be decreased (remove Rule 3 and 4) but the feerate must double. In this scenario, a 100 kvB transaction can be replaced by a 100 vB transaction paying 200 sats. That's 200 sats to relay 100,200 vB of transaction data, which is less than 0.002 sat/vB. It becomes quite cheap to replace large portions of the mempool, decreasing both its average feerate and total absolute fees. + +<br/>Consider a rule where the fee can stay the same (keep Rule 3 but drop Rule 4) but the feerate must double. The attacker can start out with 100 kvB transaction, paying 1 sat/vB. A user can reduce its size over and over again, doubling the feerate each time until it gets too small, and end up paying 100 ksat for 100 kvB(1 + 1/2 + 1/4 + ... + log2(mintxsize)) -> approaches 200 kvB. This means the attacker pays a rate of 0.5 sat/vB to relay transactions, which is below our "free relay" threshold of 1 sat/vB. +</ref>. + +Another issue is the complexity of defining and implementing a "would confirm soon" or "is in the top N portion of the mempool." These proposals require an efficient way to assess the incentive compatibility score of a transaction and where it ranks amongst the other mempool transactions. This isn't feasible without something like cluster mempool (also see the "add static incentive compatibility rule in RBF policy" section above) +<ref>Concerns about Replace by Feerate proposals +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017020.html +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017002.html +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html +* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4044451#gistcomment-4044451 +</ref>. + +===Alternatives: implement rate-limiting without fee rules=== +"Since Rule 3 and 4 (requiring an increase in absolute fees) are for rate-limiting, replace them with a mempool-wide or per-peer rate limits on replacements by outpoint and/or bandwidth +<ref>Examples of general rate-limiting proposals and suggestions: +* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349 +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019820.html +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017024.html +<br />Related proposal for changing the amount of bandwidth that replacement transactions use: +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019820.html +</ref>." + +A problem with any global rate limit is that, in the absence of reputation or identities, the limit could be exhausted by an attacker, thus restricting replacements for honest users. For example, an outpoint-based rate limit could be exhausted by one dishonest participant of a shared transaction, preventing the other participants from making any replacements. There are also other concerns about implementation complexity, free relay issues, and other unresolved edge cases +<ref>Concerns +* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081559#gistcomment-4081559 +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019921.html +* https://docs.google.com/document/d/1LpYF17HdbXPGHKSl3WYdxG4XTJBNJKSn-c2UJ2yphhE/edit?usp=sharing +</ref>. + + +==Acknowledgements== + +Thank you to everyone who contributed to this proposal and document, including +Jon Atack, +Matt Corallo, +Suhas Daftuar, +Mark Erhardt, +Antoine Poinsot, +Antoine Riard, +Gregory Sanders, +and Bastien Teinturier. + +==References and Rationale== + +<references/> + |
