highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 13:22:51 +01:00
Code Issues Packages Projects Releases Wiki Activity

Remove trailing whitespace from all BIPs

Browse Source
This commit is contained in:
Orfeas Stefanos Thyfronitis Litos 2024-07-25 18:35:39 +03:00
parent ad1d3bc2a7
commit 9a56d3544e
48 changed files with 291 additions and 291 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bip-0009.mediawiki
View File

@ -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. 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) { if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED; return FAILED;
} }

2
bip-0017.mediawiki
View File

@ -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. * 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. 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.

12
bip-0038.mediawiki
View File

@ -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' * 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. ** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37 * 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 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 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. *** 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) **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): * 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) ** 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): * 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) ** 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): * 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) ** 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) ** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
@ -272,7 +272,7 @@ Test 2:
Test 1: Test 1:
*Passphrase: MOLON LABE *Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX *Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j *Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh *Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8 *Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
@ -280,9 +280,9 @@ Test 1:
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD *Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
*Lot/Sequence: 263183/1 *Lot/Sequence: 263183/1
Test 2: Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ *Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK *Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH *Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf *Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D *Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D

2
bip-0042.mediawiki
View File

@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak
===Floating-point approximation=== ===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=== ===Truncation===

4
bip-0052.mediawiki
View File

@ -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 invest in mining hardware. From a practical perspective, Bitcoin adoption by
companies like Tesla (which recently rescinded its acceptance of Bitcoin as companies like Tesla (which recently rescinded its acceptance of Bitcoin as
payment) has been hampered by its massive energy consumption and perceived payment) has been hampered by its massive energy consumption and perceived
environmental impact. environmental impact.
<img src="bip-0052/btc_energy-small.png"></img> <img src="bip-0052/btc_energy-small.png"></img>
@ -137,7 +137,7 @@ x1 <- keccak(input)
x2 <- reshape(x1, 64) x2 <- reshape(x1, 64)
// Perform a matrix-vector multiplication. // 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) x3 <- vector_matrix_mult(x2, M)
// Truncate all values to 4 most significant bits. // Truncate all values to 4 most significant bits.

2
bip-0064.mediawiki
View File

@ -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 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 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 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. 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. If the requesting client has a mapping of chain heights to block hashes in the best chain e.g.

20
bip-0065.mediawiki
View File

@ -205,19 +205,19 @@ transaction output ''can'' be spent.
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. semantics and detailed rationale for those semantics.
case OP_NOP2: case OP_NOP2:
{ {
// CHECKLOCKTIMEVERIFY // CHECKLOCKTIMEVERIFY
// //
// (nLockTime -- nLockTime ) // (nLockTime -- nLockTime )
if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
break; // not enabled; treat as a NOP break; // not enabled; treat as a NOP
if (stack.size() < 1) if (stack.size() < 1)
return false; return false;
// Note that elsewhere numeric opcodes are limited to // Note that elsewhere numeric opcodes are limited to
// operands in the range -2**31+1 to 2**31-1, however it is // operands in the range -2**31+1 to 2**31-1, however it is
// legal for opcodes to produce results exceeding that // 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 // to 5-byte bignums, which are good until 2**32-1, the
// same limit as the nLockTime field itself. // same limit as the nLockTime field itself.
const CScriptNum nLockTime(stacktop(-1), 5); const CScriptNum nLockTime(stacktop(-1), 5);
// In the rare event that the argument may be < 0 due to // In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use // some arithmetic being done first, you can always use
// 0 MAX CHECKLOCKTIMEVERIFY. // 0 MAX CHECKLOCKTIMEVERIFY.
if (nLockTime < 0) if (nLockTime < 0)
return false; return false;
// There are two types of nLockTime: lock-by-blockheight // There are two types of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether // and lock-by-blocktime, distinguished by whether
// nLockTime < LOCKTIME_THRESHOLD. // nLockTime < LOCKTIME_THRESHOLD.
@ -252,12 +252,12 @@ semantics and detailed rationale for those semantics.
(txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
)) ))
return false; return false;
// Now that we know we're comparing apples-to-apples, the // Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one. // comparison is a simple numeric one.
if (nLockTime > (int64_t)txTo.nLockTime) if (nLockTime > (int64_t)txTo.nLockTime)
return false; return false;
// Finally the nLockTime feature can be disabled and thus // Finally the nLockTime feature can be disabled and thus
// CHECKLOCKTIMEVERIFY bypassed if every txin has been // CHECKLOCKTIMEVERIFY bypassed if every txin has been
// finalized by setting nSequence to maxint. The // finalized by setting nSequence to maxint. The
@ -270,9 +270,9 @@ semantics and detailed rationale for those semantics.
// required to prove correct CHECKLOCKTIMEVERIFY execution. // required to prove correct CHECKLOCKTIMEVERIFY execution.
if (txTo.vin[nIn].IsFinal()) if (txTo.vin[nIn].IsFinal())
return false; return false;
break; break;
} }
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4 https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4

4
bip-0066.mediawiki
View File

@ -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 // Verify that the length of the signature matches the sum of the length
// of the elements. // of the elements.
if ((size_t)(lenR + lenS + 7) != sig.size()) return false; if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
// Check whether the R element is an integer. // Check whether the R element is an integer.
if (sig[2] != 0x02) return false; if (sig[2] != 0x02) return false;
@ -140,7 +140,7 @@ An implementation for the reference client is available at https://github.com/bi
==Acknowledgements== ==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== ==Disclosures==

46
bip-0067.mediawiki
View File

@ -19,7 +19,7 @@ This BIP describes a method to deterministically generate multi-signature pay-to
==Motivation== ==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. 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. 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. 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== ==Specification==
For a set of public keys, ensure that they have been received in compressed form: For a set of public keys, ensure that they have been received in compressed form:
022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
Sort them lexicographically according to their binary representation: Sort them lexicographically according to their binary representation:
021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 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 OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG
Hash the redeem script according to BIP-0016 to get the P2SH address. Hash the redeem script according to BIP-0016 to get the P2SH address.
3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
==Compatibility== ==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. * 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. * 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 ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
Vector 2 (Already sorted, no action required) Vector 2 (Already sorted, no action required)
* List: * List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0 ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted: * Sorted:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0 ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
@ -89,12 +89,12 @@ Vector 2 (Already sorted, no action required)
** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH ** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
Vector 3: Vector 3:
* List: * List:
** 030000000000000000000000000000000000004141414141414141414141414141 ** 030000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414141 ** 020000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414140 ** 020000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414140 ** 030000000000000000000000000000000000004141414141414141414141414140
* Sorted: * Sorted:
** 020000000000000000000000000000000000004141414141414141414141414140 ** 020000000000000000000000000000000000004141414141414141414141414140
** 020000000000000000000000000000000000004141414141414141414141414141 ** 020000000000000000000000000000000000004141414141414141414141414141
** 030000000000000000000000000000000000004141414141414141414141414140 ** 030000000000000000000000000000000000004141414141414141414141414140
@ -105,11 +105,11 @@ Vector 3:
** 32V85igBri9zcfBRVupVvwK18NFtS37FuD ** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
Vector 4: (from bitcore) Vector 4: (from bitcore)
* List: * List:
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
* Sorted: * Sorted:
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
@ -119,13 +119,13 @@ Vector 4: (from bitcore)
** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba ** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
==Acknowledgements== ==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== ==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/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/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/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]] * [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]
== References == == References ==

6
bip-0068.mediawiki
View File

@ -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. 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. 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. */ /* Interpret sequence numbers as relative lock-time constraints. */
LOCKTIME_VERIFY_SEQUENCE = (1 << 0), LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
}; };
/* Setting nSequence to this value for every input in a transaction /* Setting nSequence to this value for every input in a transaction
* disables nLockTime. */ * disables nLockTime. */
static const uint32_t SEQUENCE_FINAL = 0xffffffff; 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) // 0 <= nHeight < 65,535 blocks (1.25 years)
nSequence = nHeight; nSequence = nHeight;
nHeight = nSequence & 0x0000ffff; nHeight = nSequence & 0x0000ffff;
// 0 <= nTime < 33,554,431 seconds (1.06 years) // 0 <= nTime < 33,554,431 seconds (1.06 years)
nSequence = (1 << 22) | (nTime >> 9); nSequence = (1 << 22) | (nTime >> 9);
nTime = (nSequence & 0x0000ffff) << 9; nTime = (nSequence & 0x0000ffff) << 9;

2
bip-0072.mediawiki
View File

@ -69,4 +69,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
==References== ==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

18
bip-0075.mediawiki
View File

@ -18,11 +18,11 @@
This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol. 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. # 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. "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Copyright== ==Copyright==
@ -217,9 +217,9 @@ message EncryptedProtocolMessage {
|} |}
==Payment Protocol Process with InvoiceRequests== ==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/> <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/> <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. 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/> <br/><br/>
@ -257,14 +257,14 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL
===Payment Protocol Status Communication=== ===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/> <br/><br/>
The status_message value SHOULD be set with a human readable explanation of the status code. The status_message value SHOULD be set with a human readable explanation of the status code.
====Payment Protocol Status Codes==== ====Payment Protocol Status Codes====
{| class="wikitable" {| class="wikitable"
! Status Code !! Description ! Status Code !! Description
|- |-
| 1 || OK | 1 || OK
|- |-
| 2 || Cancel | 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 ** Set '''signature''' value to the computed signature
===InvoiceRequest Validation=== ===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). * 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 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 * 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. 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==== ====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 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: 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== ==Public Key & Signature Encoding==
* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. * 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 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. * All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.

2
bip-0083.mediawiki
View File

@ -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. 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== ==References==

2
bip-0088.mediawiki
View File

@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though.
==Specification== ==Specification==
The format for the template was chosen to make it easy to read, convenient and visually unambiguous. 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>). Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>).

2
bip-0090.mediawiki
View File

@ -82,7 +82,7 @@ https://github.com/bitcoin/bitcoin/pull/8391.
==References== ==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] [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures]

28
bip-0099.mediawiki
View File

@ -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. consensus validation rules may vary depending on the type of change being deployed.
Discussing such changes without a uniform view on the deployment Discussing such changes without a uniform view on the deployment
paths often leads to misunderstandings and unnecessarily delays the paths often leads to misunderstandings and unnecessarily delays the
deployment of changes. deployment of changes.
==Definitions== ==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). : 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 ;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== ==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 Core. It is to be noted that sharing the same code for consensus
validation doesn't prevent alternative implementations from validation doesn't prevent alternative implementations from
independently changing their consensus rules: they can always fork 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 Hopefully libbitcoinconsensus will remove this type of consensus fork
which - being accidental - obviously doesn't need a deployment plan. which - being accidental - obviously doesn't need a deployment plan.
====11/12 March 2013 Chain Fork==== ====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 Without entering into much detail (see [2]), the situation was different from
what's being described from the alternative implementation risks (today alternative implementation what's being described from the alternative implementation risks (today alternative implementation
still usually rely in different degrees on Bitcoin Core trusted proxies, which 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. the solution.
But there's some philosophical disagreements on the terms of what the 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 If "the implementation is the specification", then those
levelDB-specific limitations were part of the consensus rules. levelDB-specific limitations were part of the consensus rules.
Then additional rules were necessary and any alternative 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 instead of one but the first one deployed practically for free. The
practical result would have been identical and only the definitions practical result would have been identical and only the definitions
change. This means discussing something that went uncontroversially change. This means discussing something that went uncontroversially
well further is "philosophical bike-shed" (TM). well further is "philosophical bike-shed" (TM).
===Unilateral softforks=== ===Unilateral softforks===
@ -157,17 +157,17 @@ that this must always be the case.
While 2 chains cohexist, they can be considered two different While 2 chains cohexist, they can be considered two different
currencies. currencies.
We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market 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) = 1000 * mc(old_bitcoin),
maybe mc(bitcoinA) + mc(bitcoinB) = 0, maybe mc(bitcoinA) + mc(bitcoinB) = 0,
... ...
Schism hardforks have been compared to one type of altcoins called Schism hardforks have been compared to one type of altcoins called
"spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to "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 that nobody noticed and allows an evil developer cabal to steal
everyone's coins. The users and non-evil developers could join, fork everyone's coins. The users and non-evil developers could join, fork
libconsensus and use the forked version in their respective bitcoin 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 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 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 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 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 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 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 The current miners' voting mechanism can be modified to allow for
changes to be deployed in parallel, the rejection of a concrete changes to be deployed in parallel, the rejection of a concrete
@ -355,12 +355,12 @@ worth of blocks).
[5] Original references: [5] Original references:
https://bitcointalk.org/index.php?topic=114751.0 https://bitcointalk.org/index.php?topic=114751.0
https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
Rebased patch: Rebased patch:
https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14 https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
==Attribution== ==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. Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke.
==Copyright== ==Copyright==

2
bip-0104.mediawiki
View File

@ -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: Allow miners to vote for max block size, rejected because:
* overly complex and political * overly complex and political
* human involvement makes this slow to respond to changing transaction volumes * 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 * unpredictable transaction fees caused by this would create uncertainty in the ecosystem
==Backward Compatibility== ==Backward Compatibility==

24
bip-0105.mediawiki
View File

@ -13,21 +13,21 @@
==Abstract== ==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. using a consensus based approach.
==Motivation== ==Motivation==
There is a belief that Bitcoin cannot easily respond to raising the 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 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 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 unable to respond in a timely manner would irreparably harm the credibility of
bitcoin. bitcoin.
Additionally, predetermined block size increases are problematic because they Additionally, predetermined block size increases are problematic because they
attempt to predict the future, and if too large could have unintended attempt to predict the future, and if too large could have unintended
consequences like damaging the possibility for a fee market to develop consequences like damaging the possibility for a fee market to develop
as block subsidy decreases substantially over the next 9 years; introducing as block subsidy decreases substantially over the next 9 years; introducing
or exacerbating mining attack vectors; or somehow affect the network in unknown 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 or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
extensive. extensive.
@ -36,14 +36,14 @@ Dynamic block size adjustments also suffer from the potential to be gamed by the
larger hash power. larger hash power.
Free voting as suggested by BIP100 allows miners to sell their votes out of band 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 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. manipulate the blocksize such to disadvantage or attack smaller pools.
==Rationale== ==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 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 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 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. The initial block size limit shall be 1MB.
Each time a miner creates a block, they may vote to increase or decrease the 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. be used to recalculate the new block size limit every 2016 blocks.
Votes are cast using the block's coinbase transaction scriptSig. 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 which is proportionally larger than the standard difficulty target based on the
percentage increase they voted for. 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. difficulty target.
Miners can vote for no change by voting for the current block size. Miners can vote for no change by voting for the current block size.

6
bip-0106.mediawiki
View File

@ -36,13 +36,13 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&
Keep the same MaxBlockSize Keep the same MaxBlockSize
===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== ===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 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) 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 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) 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) ) 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 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) ) Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )

16
bip-0107.mediawiki
View File

@ -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 # Layer 2 services and networks for off-chain transactions
# General efficiency improvements to transactions and the blockchain # 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'. * 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. * 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''' * '''Phase 2'''
** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume ** 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 ** 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% ** 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 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 * 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: 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 * 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. * 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. * 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== ==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 *** 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 *** 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 **** 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? ** Why 3025 blocks?
*** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 *** 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: *** 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 ***# 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 *** 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? ** 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 *** 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== ==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> <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== ==Acknowledgements==

2
bip-0109.mediawiki
View File

@ -65,7 +65,7 @@ SPV (simple payment validation) wallets are compatible with this change.
==Rationale== ==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. 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.

10
bip-0112.mediawiki
View File

@ -69,13 +69,13 @@ address with the following redeemscript.
<Alice's pubkey> CHECKSIG <Alice's pubkey> CHECKSIG
ENDIF 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. Bob or the Escrow.
After 30 days Alice can sign alone. After 30 days Alice can sign alone.
The clock does not start ticking until the payment to the escrow address The clock does not start ticking until the payment to the escrow address
confirms. confirms.
===Retroactive Invalidation=== ===Retroactive Invalidation===
@ -230,7 +230,7 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics
==Specification== ==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. semantics and detailed rationale for those semantics.
<pre> <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 /* If CTxIn::nSequence encodes a relative lock-time, this mask is
* applied to extract that lock-time from the sequence field. */ * applied to extract that lock-time from the sequence field. */
static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff; static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
case OP_NOP3: case OP_NOP3:
{ {
if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
@ -290,7 +290,7 @@ case OP_NOP3:
break; break;
} }
bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
{ {
// Relative lock times are supported by comparing the passed // Relative lock times are supported by comparing the passed

8
bip-0113.mediawiki
View File

@ -45,13 +45,13 @@ BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).
==Specification== ==Specification==
The values for transaction locktime remain unchanged. The difference is only in The values for transaction locktime remain unchanged. The difference is only in
the calculation determining whether a transaction can be included. Instead of the calculation determining whether a transaction can be included. Instead of
an unreliable timestamp, the following function is used to determine the current an unreliable timestamp, the following function is used to determine the current
block time for the purpose of checking lock-time constraints: block time for the purpose of checking lock-time constraints:
enum { nMedianTimeSpan=11 }; enum { nMedianTimeSpan=11 };
int64_t GetMedianTimePast(const CBlockIndex* pindex) int64_t GetMedianTimePast(const CBlockIndex* pindex)
{ {
int64_t pmedian[nMedianTimeSpan]; int64_t pmedian[nMedianTimeSpan];

4
bip-0120.mediawiki
View File

@ -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> OP_RETURN <version> <txid> <nonce>
{| {|
! Field !! Size [B] !! Description ! Field !! Size [B] !! Description
|- |-
| &lt;version> || 2 || Version, little endian, currently 0x01 0x00 | &lt;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 | |input2 4,ffffffff | 1,pay to B |
| | 4,pay to C | | | 4,pay to C |
+------------------------------------------------+ +------------------------------------------------+
PoP(T) PoP(T)
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| inputs | outputs | | inputs | outputs |

8
bip-0122.mediawiki
View File

@ -43,7 +43,7 @@ Where:
| rowspan="3" | type | rowspan="3" | type
| tx | tx
| for transactions. | for transactions.
| rowspan="3" | required | rowspan="3" | required
|- |-
| block | block
| for blocks (supports both hash or height). | 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: So, for example:
<pre> <pre>
Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Bitcoin test : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 Bitcoin test : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206 Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206
</pre> </pre>
An example of forked chain (Feathercoin, that forked Litecoin): An example of forked chain (Feathercoin, that forked Litecoin):
@ -87,7 +87,7 @@ An example of forked chain (Feathercoin, that forked Litecoin):
<pre> <pre>
Litecoin : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2 Litecoin : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb
</pre> </pre>
==Examples== ==Examples==

2
bip-0123.mediawiki
View File

@ -72,7 +72,7 @@ There's room at this layer to allow for competing standards without breaking bas
===4. Applications Layer=== ===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== ==Classification of existing BIPs==

8
bip-0129.mediawiki
View File

@ -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>. * 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. * 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 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 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 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. * 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 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 it is compatible with the derivation path restrictions.
* The Signer verifies that the wallet's first address is valid. * 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). * 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. * 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. # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
The <tt>TOKEN</tt> can be converted to one of these formats: 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 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 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. * A QR code.
* Other formats. * Other formats.

2
bip-0132.mediawiki
View File

@ -83,7 +83,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c
** User communities ** 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. * 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. * At any point, a Committee Declaration can be posted.
* This Declaration must contain details about: * This Declaration must contain details about:
** The segment the Committee is representing ** The segment the Committee is representing

2
bip-0134.mediawiki
View File

@ -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 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 can be omitted from individual transactions. Some other ideas are the
standardization of data-formats (like integer and string encoding) so 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 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] 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. (CMF) which is optimized to keep the size small and fast to parse.

14
bip-0141.mediawiki
View File

@ -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. 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: Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format:
[nVersion][txins][txouts][nLockTime] [nVersion][txins][txouts][nLockTime]
A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data: A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data:
[nVersion][marker][flag][txins][txouts][witness][nLockTime] [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. 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>. 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. 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: 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 - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24) 1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed) 4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value) 32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)
39th byte onwards: Optional data with no consensus meaning 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>. 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. If there are more than one <code>scriptPubKey</code> matching the pattern, the one with highest output index is assumed to be the commitment.

22
bip-0142.mediawiki
View File

@ -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 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: The new address is encoded in a way similar to existing address formats:
base58-encode: base58-encode:
[1-byte address version] [1-byte address version]
[1-byte witness program version] [1-byte witness program version]
[0x00] [0x00]
[20/32-byte-hash] [20/32-byte-hash]
[4-byte checksum] [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 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. 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 == == Example ==
The following public key, The following public key,
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6 0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
when encoded as a P2PKH template, would become: when encoded as a P2PKH template, would become:
DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
With the corresponding version 1 Bitcoin address being: With the corresponding version 1 Bitcoin address being:
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM 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> OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is: Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
== Reference implementation == == Reference implementation ==
https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80 https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80

166
bip-0143.mediawiki
View File

@ -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) 1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash) 2. hashPrevouts (32-byte hash)
3. hashSequence (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) 5. scriptCode of the input (serialized as scripts inside CTxOuts)
6. value of the output spent by this input (8-byte little endian) 6. value of the output spent by this input (8-byte little endian)
7. nSequence of the input (4-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 hashPrevouts;
uint256 hashSequence; uint256 hashSequence;
uint256 hashOutputs; uint256 hashOutputs;
if (!(nHashType & SIGHASH_ANYONECANPAY)) { if (!(nHashType & SIGHASH_ANYONECANPAY)) {
CHashWriter ss(SER_GETHASH, 0); CHashWriter ss(SER_GETHASH, 0);
for (unsigned int n = 0; n < txTo.vin.size(); n++) { 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(); hashPrevouts = ss.GetHash();
} }
if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
CHashWriter ss(SER_GETHASH, 0); CHashWriter ss(SER_GETHASH, 0);
for (unsigned int n = 0; n < txTo.vin.size(); n++) { 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(); hashSequence = ss.GetHash();
} }
if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) { if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
CHashWriter ss(SER_GETHASH, 0); CHashWriter ss(SER_GETHASH, 0);
for (unsigned int n = 0; n < txTo.vout.size(); n++) { 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]; ss << txTo.vout[nIn];
hashOutputs = ss.GetHash(); hashOutputs = ss.GetHash();
} }
CHashWriter ss(SER_GETHASH, 0); CHashWriter ss(SER_GETHASH, 0);
// Version // Version
ss << txTo.nVersion; ss << txTo.nVersion;
@ -125,7 +125,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
ss << txTo.nLockTime; ss << txTo.nLockTime;
// Sighash type // Sighash type
ss << nHashType; ss << nHashType;
return ss.GetHash(); return ss.GetHash();
</source> </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 . 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 === === Native P2WPKH ===
The following is an unsigned transaction: The following is an unsigned transaction:
0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000 0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000
nVersion: 01000000 nVersion: 01000000
txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff
ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac 9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
nLockTime: 11000000 nLockTime: 11000000
The first input comes from an ordinary P2PK: The first input comes from an ordinary P2PK:
scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25 scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
private key : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866 private key : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866
The second input comes from a P2WPKH witness program: The second input comes from a P2WPKH witness program:
scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6 scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6
private key : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9 private key : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9
public key : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357 public key : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
To sign it with a nHashType of 1 (SIGHASH_ALL): To sign it with a nHashType of 1 (SIGHASH_ALL):
hashPrevouts: hashPrevouts:
dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000) dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
= 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
hashSequence: hashSequence:
dSHA256(eeffffffffffffff) dSHA256(eeffffffffffffff)
= 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
hashOutputs: hashOutputs:
dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac) dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac)
= 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000 hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37 hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
@ -185,12 +185,12 @@ To ensure consistency in consensus-critical behaviour, developers should test th
hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5 hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
nLockTime: 11000000 nLockTime: 11000000
nHashType: 01000000 nHashType: 01000000
sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670 sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670
signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01
The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000 The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000
nVersion: 01000000 nVersion: 01000000
marker: 00 marker: 00
flag: 01 flag: 01
@ -203,38 +203,38 @@ To ensure consistency in consensus-critical behaviour, developers should test th
nLockTime: 11000000 nLockTime: 11000000
=== P2SH-P2WPKH === === P2SH-P2WPKH ===
The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000 The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000
nVersion: 01000000 nVersion: 01000000
txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff
txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac
0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac 0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac
nLockTime: 92040000 nLockTime: 92040000
The input comes from a P2SH-P2WPKH witness program: The input comes from a P2SH-P2WPKH witness program:
scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10 scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10
redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089 redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089
private key : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf private key : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf
public key : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873 public key : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873
To sign it with a nHashType of 1 (SIGHASH_ALL): To sign it with a nHashType of 1 (SIGHASH_ALL):
hashPrevouts: hashPrevouts:
dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000) dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000)
= b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a = b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a
hashSequence: hashSequence:
dSHA256(feffffff) dSHA256(feffffff)
= 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198 = 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198
hashOutputs: hashOutputs:
dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac) dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac)
= de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83 = de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83
hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000 hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a
hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198 hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198
@ -245,10 +245,10 @@ To ensure consistency in consensus-critical behaviour, developers should test th
hashOutputs: de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83 hashOutputs: de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83
nLockTime: 92040000 nLockTime: 92040000
nHashType: 01000000 nHashType: 01000000
sigHash: 64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6 sigHash: 64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6
signature: 3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01 signature: 3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01
The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000 The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000
nVersion: 01000000 nVersion: 01000000
marker: 00 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: This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> are processed:
The following is an unsigned transaction: The following is an unsigned transaction:
0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000
nVersion: 01000000 nVersion: 01000000
txin: 02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff txin: 02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff
0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff 0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff
txout: 01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac txout: 01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac
nLockTime: 00000000 nLockTime: 00000000
The first input comes from an ordinary P2PK: The first input comes from an ordinary P2PK:
scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625 scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL) signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)
The second input comes from a native P2WSH witness program: The second input comes from a native P2WSH witness program:
scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49 scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
<026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG
To sign it with a nHashType of 3 (SIGHASH_SINGLE): To sign it with a nHashType of 3 (SIGHASH_SINGLE):
hashPrevouts: hashPrevouts:
dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000) dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)
= ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41 = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
nVersion: 01000000 nVersion: 01000000
hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41 hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 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) hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)
nLockTime: 00000000 nLockTime: 00000000
nHashType: 03000000 nHashType: 03000000
scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
^^ ^^
(please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode) (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 public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703 signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
(everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000 preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
@ -317,36 +317,36 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465 public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503 signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000 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: 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: The following is an unsigned transaction:
0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000 0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000
nVersion: 01000000 nVersion: 01000000
txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff
80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff
txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac
8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac 8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac
nLockTime: 00000000 nLockTime: 00000000
The first input comes from a native P2WSH witness program: The first input comes from a native P2WSH witness program:
scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215 scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215
witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG 0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
The second input comes from a native P2WSH witness program: The second input comes from a native P2WSH witness program:
scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215 scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215
witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG 1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY): To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY):
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
hashSequence: 0000000000000000000000000000000000000000000000000000000000000000 hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
@ -357,7 +357,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
hashOutputs: (see below) hashOutputs: (see below)
nLockTime: 00000000 nLockTime: 00000000
nHashType: 83000000 nHashType: 83000000
outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000 outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000
scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
(since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode) (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 public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98
private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d
signature: 3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 signature: 3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683
outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000 outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000
scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
(everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed) (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 public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98
private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d
signature: 30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 signature: 30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83
The serialized signed transaction is: The serialized signed transaction is:
01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
nVersion: 01000000 nVersion: 01000000
@ -390,7 +390,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
witness 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac witness 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
nLockTime: 00000000 nLockTime: 00000000
Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped: Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped:
0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
nVersion: 01000000 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. 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 The following is an unsigned transaction: 010000000136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000000ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac00000000
nVersion: 01000000 nVersion: 01000000
txin: 01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff txin: 01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff
txout: 02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac txout: 02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac
c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac
nLockTime: 00000000 nLockTime: 00000000
The input comes from a P2SH-P2WSH 6-of-6 multisig witness program: The input comes from a P2SH-P2WSH 6-of-6 multisig witness program:
scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321 scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321
redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54 redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54
witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae
hashPrevouts: hashPrevouts:
dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000) dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000)
= 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 = 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
hashSequence: hashSequence:
dSHA256(ffffffff) dSHA256(ffffffff)
= 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
hashOutputs for ALL: hashOutputs for ALL:
dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac) dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac)
= bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc = bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc
hashOutputs for SINGLE: hashOutputs for SINGLE:
dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac) dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac)
= 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708 = 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708
hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000 hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 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 public key: 0307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba3
private key: 730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6 private key: 730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6
signature: 304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01 signature: 304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01
hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000 hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 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 public key: 03b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b
private key: 11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3 private key: 11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3
signature: 3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502 signature: 3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502
hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000 hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0 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 public key: 034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a
private key: 77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661 private key: 77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661
signature: 3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403 signature: 3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403
hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000 hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 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 public key: 033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f4
private key: 14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49 private key: 14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49
signature: 3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381 signature: 3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381
hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000 hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 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 public key: 03a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac16
private key: fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323 private key: fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323
signature: 3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882 signature: 3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882
hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000 hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000 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 public key: 02d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b
private key: 428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890 private key: 428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890
signature: 30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783 signature: 30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783
The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000 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. 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 The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000
nVersion: 01000000 nVersion: 01000000
txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff
txout: 01 0100000000000000 00 txout: 01 0100000000000000 00
nLockTime: 00000000 nLockTime: 00000000
The input comes from a P2WSH witness program: The input comes from a P2WSH witness program:
scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000 scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000
redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01>
ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
To sign it with a nHashType of 1 (SIGHASH_ALL): To sign it with a nHashType of 1 (SIGHASH_ALL):
hashPrevouts: hashPrevouts:
dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000) dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000)
= b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f = b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
hashSequence: hashSequence:
dSHA256(ffffffff) dSHA256(ffffffff)
= 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 = 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
hashOutputs: hashOutputs:
dSHA256(010000000000000000) dSHA256(010000000000000000)
= e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228 = e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000 hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
nVersion: 01000000 nVersion: 01000000
hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044 hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
@ -581,11 +581,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app
hashOutputs: e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228 hashOutputs: e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
nLockTime: 00000000 nLockTime: 00000000
nHashType: 01000000 nHashType: 01000000
sigHash: 71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23 sigHash: 71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23
signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01 signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01
pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000 The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000
nVersion: 01000000 nVersion: 01000000
@ -597,11 +597,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app
2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c 2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01 4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
nLockTime: 00000000 nLockTime: 00000000
The following transaction is a <code>OP_CHECKMULTISIGVERIFY</code> version of the <code>FindAndDelete</code> examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000 The following transaction is a <code>OP_CHECKMULTISIGVERIFY</code> version of the <code>FindAndDelete</code> examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000
redeemScript: OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601> redeemScript: OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601>
hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000 hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
sighash: c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72 sighash: c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72
@ -618,7 +618,7 @@ The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BI
== Deployment == == Deployment ==
This proposal is deployed with Segregated Witness softfork (BIP 141) This proposal is deployed with Segregated Witness softfork (BIP 141)
== Backward compatibility == == Backward compatibility ==

2
bip-0144.mediawiki
View File

@ -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. 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. 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.

8
bip-0154.mediawiki
View File

@ -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 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 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" {|class="wikitable"
! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status ! 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, 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 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 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" {|class="wikitable"
! ID !! Purpose Name !! Description !! Status ! 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 | 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* | 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 | 19..22 || pow-id || 2 || cuckoo-cycle
|- |-
| 23 || pow-params (config_length) || 8 || | 23 || pow-params (config_length) || 8 ||
|- |-
| 24 || pow-params (sizeshift) || 28 | 24 || pow-params (sizeshift) || 28
|- |-

2
bip-0155.mediawiki
View File

@ -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>. 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. 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]. 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: This means that the message contains a serialized <code>std::vector</code> of the following structure:

2
bip-0156.mediawiki
View File

@ -109,7 +109,7 @@ Figure 3
To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is
assigned a particular Dandelion destination. Each Dandelion transaction that 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 Per-inbound-edge routing breaks the described attack by blocking an adversary's
ability to construct useful fingerprints. Fingerprints arise when routing ability to construct useful fingerprints. Fingerprints arise when routing
decisions are made independently per transaction at each node. In this case, two decisions are made independently per transaction at each node. In this case, two

2
bip-0159.mediawiki
View File

@ -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. 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. This proposal is backward compatible.

2
bip-0174.mediawiki
View File

@ -881,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. 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, 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 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=== ===Procedure For New Versions===

2
bip-0176.mediawiki
View File

@ -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 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) * 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 == == Copyright ==
This BIP is licensed under the BSD 2-clause license. This BIP is licensed under the BSD 2-clause license.

20
bip-0199.mediawiki
View File

@ -19,13 +19,13 @@ This BIP describes a script for generalized off-chain contract negotiation.
==Summary== ==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. a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation.
The script takes the following form: The script takes the following form:
OP_IF 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 OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF 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 ** 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 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 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 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. not enter the blockchain before Victor's but does reveal the preimage to Victor anyway.
==Motivation== ==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 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 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. opportunity that the possessor of a secret has to receive the funds before such a refund can occur.
===Lightning network=== ===Lightning network===
In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels. 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 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 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. at any point some parties become uncooperative, the process can be aborted via the refund conditions.
===Zero-knowledge contingent payments=== ===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 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 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.) [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. 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.

14
bip-0300.mediawiki
View File

@ -213,7 +213,7 @@ M2 is invalid if:
* An M2 is already in this block. * An M2 is already in this block.
* It tries to ACK two different M1s for the same slot. * 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.) * 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. 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). 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 1-byte - Version
n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain. 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]. 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: For example:
{| class="wikitable" {| class="wikitable"
|- |-
! SC# ! SC#
! Bundle Hash ! Bundle Hash
@ -350,7 +350,7 @@ For example:
...in block 900,000 could become... ...in block 900,000 could become...
{| class="wikitable" {| class="wikitable"
|- |-
! SC# ! SC#
! Bundle Hash ! 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. * 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. * 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.) (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== ==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== ==Reference Implementation==

2
bip-0301.mediawiki
View File

@ -89,7 +89,7 @@ So we will discuss:
=== h* === === 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. 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.

12
bip-0329.mediawiki
View File

@ -39,8 +39,8 @@ The Electrum wallet imports and exports address and transaction labels in a JSON
==Specification== ==Specification==
In order to be lightweight, human readable and well structured, this BIP uses a JSON format. 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>. 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. 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. 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. 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: Each JSON object must contain 3 or 4 key/value pairs, defined as follows:
{| class="wikitable" {| class="wikitable"
|- |-
! Key ! Key
! Description ! 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: The reference is defined for each <tt>type</tt> as follows:
{| class="wikitable" {| class="wikitable"
|- |-
! Type ! Type
! Description ! 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. 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. 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. 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. Unencrypted exports should be deleted as soon as possible.
For security reasons no private key types are defined. For security reasons no private key types are defined.
@ -120,7 +120,7 @@ For security reasons no private key types are defined.
==Backwards Compatibility== ==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. However, importing wallets complying to this specification may ignore types not defined here.
==Test Vectors== ==Test Vectors==

2
bip-0340.mediawiki
View File

@ -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 ''(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> # 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. '''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.

2
bip-0343.mediawiki
View File

@ -19,7 +19,7 @@ This document specifies a BIP8 (LOT=true) deployment to activate taproot.
==Motivation== ==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== ==Specification==

54
bip-0345.mediawiki
View File

@ -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 signature and passphrase" using a hardware wallet. A user with such a
configuration might be concerned about the risk associated with relying on 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 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 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 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 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 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 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 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 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 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" 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 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 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 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 ===== ===== 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 [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 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 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 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 ([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 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 The only way to implement vaults given the existing consensus rules, aside from
[https://github.com/revault emulating vaults with large multisig [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 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-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 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, 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 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: 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. * '''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)] 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 containing at least two leaves: one with an <code>OP_VAULT</code>-containing script that
facilitates the expected withdrawal process, and another leaf with 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. at any time prior to withdrawal finalization.
The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible 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 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 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 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]. [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021].
These tapleaf replacement rules, described more precisely below, ensure a 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 === === Fee management ===
A primary consideration of this proposal is how fee management is handled. 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 * 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. * a fee wallet that is prespecified might be compromised or lost before use.
But dynamic fee management can introduce But dynamic fee management can introduce
[https://bitcoinops.org/en/topics/transaction-pinning/ pinning vectors]. Care [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. destination-based spending policies that this proposal introduces.
Originally, this proposal had a hard dependency on reformed transaction 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> <leaf-update-script-body>
<push-count> <push-count>
[ <push-count> leaf-update script data items ... ] [ <push-count> leaf-update script data items ... ]
<trigger-vout-idx> <trigger-vout-idx>
<revault-vout-idx> <revault-vout-idx>
<revault-amount> <revault-amount>
</source> </source>
@ -413,10 +413,10 @@ that contains a taptree of the form
<source> <source>
tr(<internal-pubkey>, tr(<internal-pubkey>,
leaves = { leaves = {
recover: recover:
<recovery-sPK-hash> OP_VAULT_RECOVER, <recovery-sPK-hash> OP_VAULT_RECOVER,
trigger: trigger:
<trigger-auth-pubkey> OP_CHECKSIGVERIFY (i) <trigger-auth-pubkey> OP_CHECKSIGVERIFY (i)
<spend-delay> 2 $leaf-update-script-body OP_VAULT, (ii) <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 that it is controlled by the same descriptor as the recovery path, which
facilitates another (though probably unused) means of recovering the vault facilitates another (though probably unused) means of recovering the vault
output to the recovery path. This has the potential advantage of recovering the 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 Otherwise, the internal key can be chosen to be an unspendable NUMS point to
force execution of the taptree contents. force execution of the taptree contents.
@ -442,7 +442,7 @@ force execution of the taptree contents.
=== Triggering a withdrawal === === Triggering a withdrawal ===
To make use of the vault, and spend it towards some output, we construct a spend 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): full leaf-update script (in this case, a timelocked CTV script):
<source> <source>
@ -461,17 +461,17 @@ Output scripts:
[ [
tr(<internal-pubkey>, tr(<internal-pubkey>,
leaves = { leaves = {
recover: recover:
<recovery-sPK-hash> OP_VAULT_RECOVER, <-- unchanged <recovery-sPK-hash> OP_VAULT_RECOVER, <-- unchanged
trigger: trigger:
<target-CTV-hash> <spend-delay> <target-CTV-hash> <spend-delay>
OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the
leaf-update leaf-update
rules of OP_VAULT rules of OP_VAULT
... [ possibly other leaves ] ... [ possibly other leaves ]
} }
), ),
[ optional revault output with the [ optional revault output with the
same sPK as the original vault output ], same sPK as the original vault output ],
@ -499,7 +499,7 @@ entails trade-offs.
==== Unauthorized recovery ==== ==== 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). 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 ==== ==== 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). 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 ==== ==== 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 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 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 Note that when using unauthorized recovery, the reveal of the
recovery scriptPubKey will allow any observer to initiate the recovery process recovery scriptPubKey will allow any observer to initiate the recovery process
for any vault with matching recovery params, provided they are able to locate 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'''. '''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 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 <code>OP_VAULT</code> outputs with the same taptree, aside from slightly
different trigger leaves, can be batched together in the same withdrawal 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. <code>OP_VAULT</code> arguments.
Note that this allows the trigger authorization -- the script prefixing the 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 Recovery-incompatible vaults which have authorized recovery can be recovered in
the same transaction, so long as each set (grouped by 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. unrelated recoveries to share common fee management.
=== Watchtowers === === Watchtowers ===

4
bip-0347.mediawiki
View File

@ -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. * 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>. * 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. 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. 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. 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== ==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. Tim Ruffing and Johan T. Halseth for their feedback, review and helpful comments.

2
bip-0380.mediawiki
View File

@ -212,7 +212,7 @@ The following tests cover the checksum and character set:
* Error in checksum: <tt>raw(deedbeef)##9f8spxm</tt> * Error in checksum: <tt>raw(deedbeef)##9f8spxm</tt>
* Invalid characters in payload: <tt>raw(Ü)#00000000</tt> * Invalid characters in payload: <tt>raw(Ü)#00000000</tt>
The following tests cover key expressions: The following tests cover key expressions:
Valid expressions: Valid expressions: