mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
Remove trailing whitespace from all BIPs
This commit is contained in:
Orfeas Stefanos Thyfronitis Litos
parent
ad1d3bc2a7
commit
9a56d3544e
@ -119,7 +119,7 @@ other one simultaneously transitions to STARTED, which would mean both would dem
|
||||
|
||||
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
|
||||
|
||||
case STARTED:
|
||||
case STARTED:
|
||||
if (GetMedianTimePast(block.parent) >= timeout) {
|
||||
return FAILED;
|
||||
}
|
||||
|
||||
@ -86,7 +86,7 @@ Avoiding a block-chain split by malicious pay-to-script transactions requires ca
|
||||
|
||||
* A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners.
|
||||
|
||||
To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
|
||||
To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
|
||||
|
||||
To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "p2sh/CHV" in the input of the coinbase transaction for blocks that they create.
|
||||
|
||||
|
||||
@ -64,7 +64,7 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
|
||||
* How the user sees it: 58 characters always starting with '6P'
|
||||
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
|
||||
* Count of payload bytes (beyond prefix): 37
|
||||
** 1 byte (''flagbyte''):
|
||||
** 1 byte (''flagbyte''):
|
||||
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
|
||||
*** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format.
|
||||
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
|
||||
@ -75,10 +75,10 @@ To keep the size of the encrypted key down, no initialization vectors (IVs) are
|
||||
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
|
||||
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
|
||||
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
|
||||
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
|
||||
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
|
||||
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
|
||||
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
|
||||
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
|
||||
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
|
||||
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
|
||||
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
|
||||
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
|
||||
@ -272,7 +272,7 @@ Test 2:
|
||||
|
||||
Test 1:
|
||||
*Passphrase: MOLON LABE
|
||||
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
|
||||
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
|
||||
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
|
||||
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
|
||||
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
|
||||
@ -280,9 +280,9 @@ Test 1:
|
||||
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
|
||||
*Lot/Sequence: 263183/1
|
||||
|
||||
Test 2:
|
||||
Test 2:
|
||||
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
|
||||
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
|
||||
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
|
||||
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
|
||||
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
|
||||
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
|
||||
|
||||
@ -42,7 +42,7 @@ Note that several other programming languages do not exhibit this behaviour, mak
|
||||
|
||||
===Floating-point approximation===
|
||||
|
||||
An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
|
||||
An obvious solution would be to reimplement the shape of the subsidy curve using floating-point approximations, such as simulated annealing or quantitative easing, which have already proven their worth in consensus systems. Unfortunately, since the financial crisis everyone considers numbers with decimal points in them fishy, and integers are not well supported by Javascript.
|
||||
|
||||
===Truncation===
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ Bitcoin network cannot profitably mine Bitcoin even if they have the capital to
|
||||
invest in mining hardware. From a practical perspective, Bitcoin adoption by
|
||||
companies like Tesla (which recently rescinded its acceptance of Bitcoin as
|
||||
payment) has been hampered by its massive energy consumption and perceived
|
||||
environmental impact.
|
||||
environmental impact.
|
||||
|
||||
<img src="bip-0052/btc_energy-small.png"></img>
|
||||
|
||||
@ -137,7 +137,7 @@ x1 <- keccak(input)
|
||||
x2 <- reshape(x1, 64)
|
||||
|
||||
// Perform a matrix-vector multiplication.
|
||||
// The result is 64-vector of 14-bit unsigned.
|
||||
// The result is 64-vector of 14-bit unsigned.
|
||||
x3 <- vector_matrix_mult(x2, M)
|
||||
|
||||
// Truncate all values to 4 most significant bits.
|
||||
|
||||
@ -86,7 +86,7 @@ If the requesting client is looking up outputs for a signed transaction that the
|
||||
client can partly verify the returned output by running the input scripts with it. Currently this
|
||||
verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also
|
||||
allow the value to be checked in this way. It does not show that the output is really unspent or was
|
||||
ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey
|
||||
ever actually created in the block chain however. Additionally, the form of the provided scriptPubKey
|
||||
should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.
|
||||
|
||||
If the requesting client has a mapping of chain heights to block hashes in the best chain e.g.
|
||||
|
||||
@ -205,19 +205,19 @@ transaction output ''can'' be spent.
|
||||
Refer to the reference implementation, reproduced below, for the precise
|
||||
semantics and detailed rationale for those semantics.
|
||||
|
||||
|
||||
|
||||
case OP_NOP2:
|
||||
{
|
||||
// CHECKLOCKTIMEVERIFY
|
||||
//
|
||||
// (nLockTime -- nLockTime )
|
||||
|
||||
|
||||
if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
|
||||
break; // not enabled; treat as a NOP
|
||||
|
||||
|
||||
if (stack.size() < 1)
|
||||
return false;
|
||||
|
||||
|
||||
// Note that elsewhere numeric opcodes are limited to
|
||||
// operands in the range -2**31+1 to 2**31-1, however it is
|
||||
// legal for opcodes to produce results exceeding that
|
||||
@ -233,13 +233,13 @@ semantics and detailed rationale for those semantics.
|
||||
// to 5-byte bignums, which are good until 2**32-1, the
|
||||
// same limit as the nLockTime field itself.
|
||||
const CScriptNum nLockTime(stacktop(-1), 5);
|
||||
|
||||
|
||||
// In the rare event that the argument may be < 0 due to
|
||||
// some arithmetic being done first, you can always use
|
||||
// 0 MAX CHECKLOCKTIMEVERIFY.
|
||||
if (nLockTime < 0)
|
||||
return false;
|
||||
|
||||
|
||||
// There are two types of nLockTime: lock-by-blockheight
|
||||
// and lock-by-blocktime, distinguished by whether
|
||||
// nLockTime < LOCKTIME_THRESHOLD.
|
||||
@ -252,12 +252,12 @@ semantics and detailed rationale for those semantics.
|
||||
(txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
|
||||
))
|
||||
return false;
|
||||
|
||||
|
||||
// Now that we know we're comparing apples-to-apples, the
|
||||
// comparison is a simple numeric one.
|
||||
if (nLockTime > (int64_t)txTo.nLockTime)
|
||||
return false;
|
||||
|
||||
|
||||
// Finally the nLockTime feature can be disabled and thus
|
||||
// CHECKLOCKTIMEVERIFY bypassed if every txin has been
|
||||
// finalized by setting nSequence to maxint. The
|
||||
@ -270,9 +270,9 @@ semantics and detailed rationale for those semantics.
|
||||
// required to prove correct CHECKLOCKTIMEVERIFY execution.
|
||||
if (txTo.vin[nIn].IsFinal())
|
||||
return false;
|
||||
|
||||
|
||||
break;
|
||||
|
||||
|
||||
}
|
||||
|
||||
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
|
||||
|
||||
@ -75,7 +75,7 @@ bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
|
||||
// Verify that the length of the signature matches the sum of the length
|
||||
// of the elements.
|
||||
if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
|
||||
|
||||
|
||||
// Check whether the R element is an integer.
|
||||
if (sig[2] != 0x02) return false;
|
||||
|
||||
@ -140,7 +140,7 @@ An implementation for the reference client is available at https://github.com/bi
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
|
||||
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
|
||||
|
||||
==Disclosures==
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ This BIP describes a method to deterministically generate multi-signature pay-to
|
||||
|
||||
==Motivation==
|
||||
|
||||
Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
|
||||
Pay-to-script-hash (BIP-0011<ref>[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki BIP-0011]</ref>) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the cost of fee's associated with using longer, more complex scripts.
|
||||
|
||||
Multi-signature pay-to-script-hash transactions are defined in BIP-0016<ref>[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016]</ref>. The redeem script does not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.
|
||||
|
||||
@ -27,31 +27,31 @@ By adopting a sorting and encoding standard, compliant wallets will always produ
|
||||
|
||||
While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this.
|
||||
|
||||
Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
|
||||
Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions.
|
||||
This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider.
|
||||
|
||||
==Specification==
|
||||
|
||||
For a set of public keys, ensure that they have been received in compressed form:
|
||||
|
||||
|
||||
022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
|
||||
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
|
||||
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
|
||||
021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
|
||||
|
||||
Sort them lexicographically according to their binary representation:
|
||||
|
||||
|
||||
Sort them lexicographically according to their binary representation:
|
||||
|
||||
021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
|
||||
022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
|
||||
03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
|
||||
|
||||
..before using the resulting list of keys in a standard multisig redeem script:
|
||||
|
||||
..before using the resulting list of keys in a standard multisig redeem script:
|
||||
|
||||
OP_2 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9 OP_3 OP_CHECKMULTISIG
|
||||
|
||||
Hash the redeem script according to BIP-0016 to get the P2SH address.
|
||||
|
||||
|
||||
3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
|
||||
|
||||
|
||||
==Compatibility==
|
||||
* Uncompressed keys are incompatible with this specification. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation.
|
||||
* P2SH addresses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork.
|
||||
@ -75,11 +75,11 @@ Vector 1
|
||||
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
|
||||
|
||||
Vector 2 (Already sorted, no action required)
|
||||
* List:
|
||||
* List:
|
||||
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
|
||||
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
|
||||
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
|
||||
* Sorted:
|
||||
* Sorted:
|
||||
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
|
||||
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
|
||||
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
|
||||
@ -89,12 +89,12 @@ Vector 2 (Already sorted, no action required)
|
||||
** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
|
||||
|
||||
Vector 3:
|
||||
* List:
|
||||
* List:
|
||||
** 030000000000000000000000000000000000004141414141414141414141414141
|
||||
** 020000000000000000000000000000000000004141414141414141414141414141
|
||||
** 020000000000000000000000000000000000004141414141414141414141414140
|
||||
** 030000000000000000000000000000000000004141414141414141414141414140
|
||||
* Sorted:
|
||||
* Sorted:
|
||||
** 020000000000000000000000000000000000004141414141414141414141414140
|
||||
** 020000000000000000000000000000000000004141414141414141414141414141
|
||||
** 030000000000000000000000000000000000004141414141414141414141414140
|
||||
@ -105,11 +105,11 @@ Vector 3:
|
||||
** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
|
||||
|
||||
Vector 4: (from bitcore)
|
||||
* List:
|
||||
* List:
|
||||
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
|
||||
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
|
||||
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
|
||||
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
|
||||
* Sorted:
|
||||
* Sorted:
|
||||
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
|
||||
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
|
||||
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
|
||||
@ -119,13 +119,13 @@ Vector 4: (from bitcore)
|
||||
** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
|
||||
|
||||
==Acknowledgements==
|
||||
The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.
|
||||
The authors wish to thank BtcDrak and Luke-Jr for their involvement & contributions in the early discussions of this BIP.
|
||||
|
||||
==Usage & Implementations==
|
||||
* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets
|
||||
* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]
|
||||
==Usage & Implementations==
|
||||
* [[https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure|BIP-0045]] - Structure for Deterministic P2SH Multisignature Wallets
|
||||
* [[https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541|Bitcore]]
|
||||
* [[https://github.com/haskoin/haskoin-core/blob/b41b1deb0989334a7ead6fc993fb8b02f0c00810/haskoin-core/Network/Haskoin/Script/Parser.hs#L112-L122|Haskoin]] - Bitcoin implementation in Haskell
|
||||
* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]
|
||||
* [[https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441|Armory]]
|
||||
* [[https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/script/ScriptBuilder.java#L331|BitcoinJ]]
|
||||
|
||||
== References ==
|
||||
|
||||
@ -33,7 +33,7 @@ If bit (1 << 31) of the sequence number is set, then no consensus meaning is app
|
||||
|
||||
If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
|
||||
|
||||
The sequence number encoding is interpreted as follows:
|
||||
The sequence number encoding is interpreted as follows:
|
||||
|
||||
Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
|
||||
|
||||
@ -65,7 +65,7 @@ enum {
|
||||
/* Interpret sequence numbers as relative lock-time constraints. */
|
||||
LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
|
||||
};
|
||||
|
||||
|
||||
/* Setting nSequence to this value for every input in a transaction
|
||||
* disables nLockTime. */
|
||||
static const uint32_t SEQUENCE_FINAL = 0xffffffff;
|
||||
@ -245,7 +245,7 @@ The most efficient way to calculate sequence number from relative lock-time is w
|
||||
// 0 <= nHeight < 65,535 blocks (1.25 years)
|
||||
nSequence = nHeight;
|
||||
nHeight = nSequence & 0x0000ffff;
|
||||
|
||||
|
||||
// 0 <= nTime < 33,554,431 seconds (1.06 years)
|
||||
nSequence = (1 << 22) | (nTime >> 9);
|
||||
nTime = (nSequence & 0x0000ffff) << 9;
|
||||
|
||||
@ -69,4 +69,4 @@ bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
|
||||
|
||||
==References==
|
||||
|
||||
[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1
|
||||
[[http://www.w3.org/Protocols/rfc2616/rfc2616.html|RFC 2616]] : Hypertext Transfer Protocol -- HTTP/1.1
|
||||
|
||||
@ -18,11 +18,11 @@
|
||||
|
||||
This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
|
||||
|
||||
# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.
|
||||
# It allows the requester (Sender) of a PaymentRequest to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.
|
||||
|
||||
# It encrypts the PaymentRequest that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
|
||||
"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
|
||||
|
||||
==Copyright==
|
||||
@ -217,9 +217,9 @@ message EncryptedProtocolMessage {
|
||||
|}
|
||||
|
||||
==Payment Protocol Process with InvoiceRequests==
|
||||
The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
|
||||
The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
|
||||
<br/><br/>
|
||||
All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]].
|
||||
All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]].
|
||||
<br/><br/>
|
||||
All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown.
|
||||
<br/><br/>
|
||||
@ -257,14 +257,14 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL
|
||||
|
||||
===Payment Protocol Status Communication===
|
||||
|
||||
Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
|
||||
Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
|
||||
<br/><br/>
|
||||
The status_message value SHOULD be set with a human readable explanation of the status code.
|
||||
|
||||
====Payment Protocol Status Codes====
|
||||
{| class="wikitable"
|
||||
! Status Code !! Description
|
||||
|-
|
||||
|-
|
||||
| 1 || OK
|
||||
|-
|
||||
| 2 || Cancel
|
||||
@ -324,7 +324,7 @@ For the following we assume the Sender already knows the Receiver's public key,
|
||||
** Set '''signature''' value to the computed signature
|
||||
|
||||
===InvoiceRequest Validation===
|
||||
* Validate '''sender_public_key''' is a valid EC public key
|
||||
* Validate '''sender_public_key''' is a valid EC public key
|
||||
* Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
|
||||
* If '''pki_type''' is None, [[#InvoiceRequest|InvoiceRequest]] is VALID
|
||||
* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID
|
||||
@ -366,7 +366,7 @@ For the following we assume the Sender already knows the Receiver's public key,
|
||||
The 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST be prefixed to the returned ciphertext. The decrypt operation will use the first 16 bytes of the ciphertext as the GCM authentication tag and the remainder of the ciphertext as the ciphertext in the decrypt operation.
|
||||
|
||||
====AES-256 GCM Additional Authenticated Data====
|
||||
When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
|
||||
When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
|
||||
|
||||
===Initial Public Key Retrieval for InvoiceRequest Encryption===
|
||||
Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
|
||||
@ -387,7 +387,7 @@ Clients SHOULD keep in mind Receivers can broadcast a transaction without return
|
||||
|
||||
==Public Key & Signature Encoding==
|
||||
* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
|
||||
* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.
|
||||
* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed.
|
||||
* All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
|
||||
* All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.
|
||||
|
||||
|
||||
@ -83,7 +83,7 @@ We can continue creating subaccounts indefinitely using this scheme.
|
||||
|
||||
In order to create a bidirectional payment channel, it is necessary that previous commitments be revokable. In order to revoke previous commitments, each party reveals a secret to the other that would allow them to steal the funds in the channel if a transaction for a previous commitment is inserted into the blockchain.
|
||||
|
||||
By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children.
|
||||
By allowing for arbitrary nesting of sublevels, we can construct decision trees of arbitrary depth and revoke an entire branch by revealing a parent node used to derive all the children.
|
||||
|
||||
==References==
|
||||
|
||||
|
||||
@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though.
|
||||
|
||||
==Specification==
|
||||
|
||||
The format for the template was chosen to make it easy to read, convenient and visually 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>).
|
||||
|
||||
|
||||
@ -82,7 +82,7 @@ https://github.com/bitcoin/bitcoin/pull/8391.
|
||||
|
||||
==References==
|
||||
|
||||
[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase]
|
||||
[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP34 Block v2, Height in Coinbase]
|
||||
|
||||
[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 Strict DER signatures]
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ not always well-understood, and the best upgrade mechanisms to the
|
||||
consensus validation rules may vary depending on the type of change being deployed.
|
||||
Discussing such changes without a uniform view on the deployment
|
||||
paths often leads to misunderstandings and unnecessarily delays the
|
||||
deployment of changes.
|
||||
deployment of changes.
|
||||
|
||||
==Definitions==
|
||||
|
||||
@ -43,7 +43,7 @@ deployment of changes.
|
||||
: a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest).
|
||||
|
||||
;Libbitcoinconsensus
|
||||
: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line
|
||||
: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line
|
||||
|
||||
==Taxonomy of consensus forks==
|
||||
|
||||
@ -76,14 +76,14 @@ without burdening them with specific design choices made by Bitcoin
|
||||
Core. It is to be noted that sharing the same code for consensus
|
||||
validation doesn't prevent alternative implementations from
|
||||
independently changing their consensus rules: they can always fork
|
||||
the libbitcoinconsensus project (once it is in a separate repository).
|
||||
the libbitcoinconsensus project (once it is in a separate repository).
|
||||
|
||||
Hopefully libbitcoinconsensus will remove this type of consensus fork
|
||||
which - being accidental - obviously doesn't need a deployment plan.
|
||||
|
||||
====11/12 March 2013 Chain Fork====
|
||||
|
||||
There is a precedent of an accidental consensus fork at height 225430.
|
||||
There is a precedent of an accidental consensus fork at height 225430.
|
||||
Without entering into much detail (see [2]), the situation was different from
|
||||
what's being described from the alternative implementation risks (today alternative implementation
|
||||
still usually rely in different degrees on Bitcoin Core trusted proxies, which
|
||||
@ -104,7 +104,7 @@ rapidly by the whole worldwide community and nobody is unhappy about
|
||||
the solution.
|
||||
|
||||
But there's some philosophical disagreements on the terms of what the
|
||||
solution was: we can add a pedantic note on that.
|
||||
solution was: we can add a pedantic note on that.
|
||||
If "the implementation is the specification", then those
|
||||
levelDB-specific limitations were part of the consensus rules.
|
||||
Then additional rules were necessary and any alternative
|
||||
@ -126,7 +126,7 @@ another consensus fork to remove them. Two theoretical consensus forks
|
||||
instead of one but the first one deployed practically for free. The
|
||||
practical result would have been identical and only the definitions
|
||||
change. This means discussing something that went uncontroversially
|
||||
well further is "philosophical bike-shed" (TM).
|
||||
well further is "philosophical bike-shed" (TM).
|
||||
|
||||
===Unilateral softforks===
|
||||
|
||||
@ -157,17 +157,17 @@ that this must always be the case.
|
||||
While 2 chains cohexist, they can be considered two different
|
||||
currencies.
|
||||
We could say that bitcoin becomes bitcoinA and bitcoinB. The implications for market
|
||||
capitalization are completely unpredictable,
|
||||
capitalization are completely unpredictable,
|
||||
|
||||
maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin),
|
||||
maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin),
|
||||
|
||||
maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin),
|
||||
maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin),
|
||||
|
||||
maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin),
|
||||
|
||||
maybe mc(bitcoinA) + mc(bitcoinB) = 0,
|
||||
|
||||
...
|
||||
...
|
||||
|
||||
Schism hardforks have been compared to one type of altcoins called
|
||||
"spinoffs"[spinoffs] that distribute all or part of its initial seigniorage to
|
||||
@ -224,7 +224,7 @@ Let's imagine BIP66 had a crypto backdoor
|
||||
that nobody noticed and allows an evil developer cabal to steal
|
||||
everyone's coins. The users and non-evil developers could join, fork
|
||||
libconsensus and use the forked version in their respective bitcoin
|
||||
implementations.
|
||||
implementations.
|
||||
Should miner's "vote" be required to express their consent? What if some miners
|
||||
are part of the cabal? In the unlikely event that most miners are
|
||||
part of such an evil cabal, changing the pow function may be
|
||||
@ -268,7 +268,7 @@ that's why the voting mechanism and first used for BIP30 and BIP66.
|
||||
The current voting threshold for softfork enforcement is 95%. There's
|
||||
also a 75% threshold for miners to activate it as a policy rule, but
|
||||
it should be safe for miners to activate such a policy from the start
|
||||
or later than 75%, as long as they enforce it as consensus rule after 95%.
|
||||
or later than 75%, as long as they enforce it as consensus rule after 95%.
|
||||
|
||||
The current miners' voting mechanism can be modified to allow for
|
||||
changes to be deployed in parallel, the rejection of a concrete
|
||||
@ -355,12 +355,12 @@ worth of blocks).
|
||||
[5] Original references:
|
||||
https://bitcointalk.org/index.php?topic=114751.0
|
||||
https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
|
||||
Rebased patch:
|
||||
Rebased patch:
|
||||
https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14
|
||||
|
||||
==Attribution==
|
||||
|
||||
Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop,
|
||||
Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop,
|
||||
Btcdrak, Gavin Andresen, Gregory Sanders, Luke Dashjr, Marco Falke.
|
||||
|
||||
==Copyright==
|
||||
|
||||
@ -65,7 +65,7 @@ A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because:
|
||||
Allow miners to vote for max block size, rejected because:
|
||||
* overly complex and political
|
||||
* human involvement makes this slow to respond to changing transaction volumes
|
||||
* focuses power over max block size to a relatively small group of people
|
||||
* focuses power over max block size to a relatively small group of people
|
||||
* unpredictable transaction fees caused by this would create uncertainty in the ecosystem
|
||||
|
||||
==Backward Compatibility==
|
||||
|
||||
@ -13,21 +13,21 @@
|
||||
|
||||
==Abstract==
|
||||
|
||||
A method of altering the maximum allowed block size of the Bitcoin protocol
|
||||
A method of altering the maximum allowed block size of the Bitcoin protocol
|
||||
using a consensus based approach.
|
||||
|
||||
==Motivation==
|
||||
|
||||
There is a belief that Bitcoin cannot easily respond to raising the
|
||||
blocksize limit if popularity was to suddenly increase due to a mass adoption
|
||||
curve, because co-ordinating a hard fork takes considerable time, and being
|
||||
unable to respond in a timely manner would irreparably harm the credibility of
|
||||
There is a belief that Bitcoin cannot easily respond to raising the
|
||||
blocksize limit if popularity was to suddenly increase due to a mass adoption
|
||||
curve, because co-ordinating a hard fork takes considerable time, and being
|
||||
unable to respond in a timely manner would irreparably harm the credibility of
|
||||
bitcoin.
|
||||
|
||||
Additionally, predetermined block size increases are problematic because they
|
||||
attempt to predict the future, and if too large could have unintended
|
||||
consequences like damaging the possibility for a fee market to develop
|
||||
as block subsidy decreases substantially over the next 9 years; introducing
|
||||
attempt to predict the future, and if too large could have unintended
|
||||
consequences like damaging the possibility for a fee market to develop
|
||||
as block subsidy decreases substantially over the next 9 years; introducing
|
||||
or exacerbating mining attack vectors; or somehow affect the network in unknown
|
||||
or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
|
||||
extensive.
|
||||
@ -36,14 +36,14 @@ Dynamic block size adjustments also suffer from the potential to be gamed by the
|
||||
larger hash power.
|
||||
|
||||
Free voting as suggested by BIP100 allows miners to sell their votes out of band
|
||||
at no risk, and enable the sponsor the ability to manipulate the blocksize.
|
||||
at no risk, and enable the sponsor the ability to manipulate the blocksize.
|
||||
It also provides a cost free method or the larger pools to vote in ways to
|
||||
manipulate the blocksize such to disadvantage or attack smaller pools.
|
||||
|
||||
|
||||
==Rationale==
|
||||
|
||||
By introducing a cost to increase the block size ensures the mining community
|
||||
By introducing a cost to increase the block size ensures the mining community
|
||||
will collude to increase it only when there is a clear necessity, and reduce it
|
||||
when it is unnecessary. Larger miners cannot force their wishes so easily
|
||||
because not only will they have to pay extra a difficulty target, then can be
|
||||
@ -63,7 +63,7 @@ honest.
|
||||
The initial block size limit shall be 1MB.
|
||||
|
||||
Each time a miner creates a block, they may vote to increase or decrease the
|
||||
blocksize by a maximum of 10% of the current block size limit. These votes will
|
||||
blocksize by a maximum of 10% of the current block size limit. These votes will
|
||||
be used to recalculate the new block size limit every 2016 blocks.
|
||||
|
||||
Votes are cast using the block's coinbase transaction scriptSig.
|
||||
@ -77,7 +77,7 @@ If a miner votes for an increase, the block hash must meet a difficulty target
|
||||
which is proportionally larger than the standard difficulty target based on the
|
||||
percentage increase they voted for.
|
||||
|
||||
Votes proposing decreasing the block size limit do not need to meet a higher
|
||||
Votes proposing decreasing the block size limit do not need to meet a higher
|
||||
difficulty target.
|
||||
|
||||
Miners can vote for no change by voting for the current block size.
|
||||
|
||||
@ -36,13 +36,13 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&
|
||||
Keep the same MaxBlockSize
|
||||
|
||||
===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners===
|
||||
|
||||
|
||||
TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period
|
||||
TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
|
||||
|
||||
|
||||
TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period
|
||||
TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
|
||||
|
||||
|
||||
If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) )
|
||||
MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
|
||||
Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )
|
||||
|
||||
@ -24,7 +24,7 @@ Over the next few years, large infrastructure investments will be made into:
|
||||
# Layer 2 services and networks for off-chain transactions
|
||||
# General efficiency improvements to transactions and the blockchain
|
||||
|
||||
* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network.
|
||||
* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network.
|
||||
* In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'.
|
||||
* These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network.
|
||||
|
||||
@ -40,7 +40,7 @@ Over the next few years, large infrastructure investments will be made into:
|
||||
* '''Phase 2'''
|
||||
** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume
|
||||
** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur
|
||||
*** This calculates to a theoretical maximum of 13 increases per year
|
||||
*** This calculates to a theoretical maximum of 13 increases per year
|
||||
** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10%
|
||||
** The maximum block size can only ever be increased, not decreased
|
||||
* The default <code>limitfreerelay</code> will also be raised in proportion to maximum block size increases
|
||||
@ -49,8 +49,8 @@ Over the next few years, large infrastructure investments will be made into:
|
||||
|
||||
For example:
|
||||
* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB
|
||||
* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB.
|
||||
* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year.
|
||||
* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB.
|
||||
* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year.
|
||||
|
||||
==Rationale==
|
||||
|
||||
@ -63,19 +63,19 @@ For example:
|
||||
*** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place
|
||||
*** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size
|
||||
**** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered
|
||||
*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit.
|
||||
*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit.
|
||||
** Why 3025 blocks?
|
||||
*** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1
|
||||
*** Increases in the maximum block size should only occur after a sustained trend can be observed in order to:
|
||||
***# Demonstrate a market-driven secular elevation in the transaction volume
|
||||
***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions
|
||||
***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions
|
||||
*** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand
|
||||
** Why 10% increase in the block size?
|
||||
*** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities to increase the block size per year
|
||||
*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community
|
||||
*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community
|
||||
|
||||
==Deployment==
|
||||
Similar deployment model to BIP101:
|
||||
Similar deployment model to BIP101:
|
||||
<blockquote>Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.</blockquote>
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
@ -65,7 +65,7 @@ SPV (simple payment validation) wallets are compatible with this change.
|
||||
|
||||
==Rationale==
|
||||
|
||||
In the short term, an increase is needed to handle increasing transaction volume.
|
||||
In the short term, an increase is needed to handle increasing transaction volume.
|
||||
|
||||
The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
|
||||
|
||||
|
||||
@ -69,13 +69,13 @@ address with the following redeemscript.
|
||||
<Alice's pubkey> CHECKSIG
|
||||
ENDIF
|
||||
|
||||
At any time funds can be spent using signatures from any two of Alice,
|
||||
At any time funds can be spent using signatures from any two of Alice,
|
||||
Bob or the Escrow.
|
||||
|
||||
After 30 days Alice can sign alone.
|
||||
|
||||
The clock does not start ticking until the payment to the escrow address
|
||||
confirms.
|
||||
confirms.
|
||||
|
||||
|
||||
===Retroactive Invalidation===
|
||||
@ -230,7 +230,7 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics
|
||||
|
||||
==Specification==
|
||||
|
||||
Refer to the reference implementation, reproduced below, for the precise
|
||||
Refer to the reference implementation, reproduced below, for the precise
|
||||
semantics and detailed rationale for those semantics.
|
||||
|
||||
<pre>
|
||||
@ -247,7 +247,7 @@ static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
|
||||
/* If CTxIn::nSequence encodes a relative lock-time, this mask is
|
||||
* applied to extract that lock-time from the sequence field. */
|
||||
static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
|
||||
|
||||
|
||||
case OP_NOP3:
|
||||
{
|
||||
if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
|
||||
@ -290,7 +290,7 @@ case OP_NOP3:
|
||||
|
||||
break;
|
||||
}
|
||||
|
||||
|
||||
bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
|
||||
{
|
||||
// Relative lock times are supported by comparing the passed
|
||||
|
||||
@ -45,13 +45,13 @@ BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).
|
||||
|
||||
==Specification==
|
||||
|
||||
The values for transaction locktime remain unchanged. The difference is only in
|
||||
the calculation determining whether a transaction can be included. Instead of
|
||||
an unreliable timestamp, the following function is used to determine the current
|
||||
The values for transaction locktime remain unchanged. The difference is only in
|
||||
the calculation determining whether a transaction can be included. Instead of
|
||||
an unreliable timestamp, the following function is used to determine the current
|
||||
block time for the purpose of checking lock-time constraints:
|
||||
|
||||
enum { nMedianTimeSpan=11 };
|
||||
|
||||
|
||||
int64_t GetMedianTimePast(const CBlockIndex* pindex)
|
||||
{
|
||||
int64_t pmedian[nMedianTimeSpan];
|
||||
|
||||
@ -52,7 +52,7 @@ A proof of payment for a transaction T, here called PoP(T), is used to prove tha
|
||||
|
||||
OP_RETURN <version> <txid> <nonce>
|
||||
|
||||
{|
|
||||
{|
|
||||
! Field !! Size [B] !! Description
|
||||
|-
|
||||
| <version> || 2 || Version, little endian, currently 0x01 0x00
|
||||
@ -77,7 +77,7 @@ An illustration of the PoP data structure and its original payment is shown belo
|
||||
|input2 4,ffffffff | 1,pay to B |
|
||||
| | 4,pay to C |
|
||||
+------------------------------------------------+
|
||||
|
||||
|
||||
PoP(T)
|
||||
+-------------------------------------------------------------+
|
||||
| inputs | outputs |
|
||||
|
||||
@ -43,7 +43,7 @@ Where:
|
||||
| rowspan="3" | type
|
||||
| tx
|
||||
| for transactions.
|
||||
| rowspan="3" | required
|
||||
| rowspan="3" | required
|
||||
|-
|
||||
| block
|
||||
| for blocks (supports both hash or height).
|
||||
@ -75,9 +75,9 @@ The '''chain ID''' of a chain is the block hash of the corresponding genesis blo
|
||||
|
||||
So, for example:
|
||||
<pre>
|
||||
Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||
Bitcoin main : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||
Bitcoin test : 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
|
||||
Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206
|
||||
Bitcoin regtest: 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206
|
||||
</pre>
|
||||
|
||||
An example of forked chain (Feathercoin, that forked Litecoin):
|
||||
@ -87,7 +87,7 @@ An example of forked chain (Feathercoin, that forked Litecoin):
|
||||
<pre>
|
||||
Litecoin : 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
|
||||
Feathercoin: fdbe99b90c90bae7505796461471d89ae8388ab953997aa06a355bbda8d915cb
|
||||
</pre>
|
||||
</pre>
|
||||
|
||||
|
||||
==Examples==
|
||||
|
||||
@ -72,7 +72,7 @@ There's room at this layer to allow for competing standards without breaking bas
|
||||
|
||||
===4. Applications Layer===
|
||||
|
||||
The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.
|
||||
The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.
|
||||
|
||||
==Classification of existing BIPs==
|
||||
|
||||
|
||||
@ -95,7 +95,7 @@ The Signer is any software or hardware that controls the private keys and can si
|
||||
* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
|
||||
* If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record.
|
||||
* The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a descriptor or a descriptor template. The third line must be a comma-separated list of derivation path restrictions. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction.
|
||||
* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption..
|
||||
* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption..
|
||||
* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
|
||||
* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
|
||||
* The Coordinator sends the encrypted descriptor record to all participating Signers.
|
||||
@ -110,7 +110,7 @@ The Signer is any software or hardware that controls the private keys and can si
|
||||
* The Signer checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
|
||||
* The Signer verifies that it is compatible with the derivation path restrictions.
|
||||
* The Signer verifies that the wallet's first address is valid.
|
||||
* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request.
|
||||
* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor or descriptor template must also be available for review upon user request.
|
||||
* Parties must check with each other that all Signers have the same confirmation (except for the <tt>KEY</tt> positions).
|
||||
* If all checks pass, the Signer must persist the descriptor record in its storage.
|
||||
|
||||
@ -126,8 +126,8 @@ We define three modes of encryption.
|
||||
# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
|
||||
|
||||
The <tt>TOKEN</tt> can be converted to one of these formats:
|
||||
* A decimal number (recommended). The number must not exceed the maximum value of the nonce.
|
||||
* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics.
|
||||
* A decimal number (recommended). The number must not exceed the maximum value of the nonce.
|
||||
* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics.
|
||||
* A QR code.
|
||||
* Other formats.
|
||||
|
||||
|
||||
@ -83,7 +83,7 @@ The author doesn't believe this is a problem because a BIP cannot be forced on c
|
||||
** User communities
|
||||
* A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment.
|
||||
|
||||
'''Committee Declarations.'''
|
||||
'''Committee Declarations.'''
|
||||
* At any point, a Committee Declaration can be posted.
|
||||
* This Declaration must contain details about:
|
||||
** The segment the Committee is representing
|
||||
|
||||
@ -58,7 +58,7 @@ various decades ago with the XML format. The idea is that we give each
|
||||
field a name and this means that new fields can be added or optional fields
|
||||
can be omitted from individual transactions. Some other ideas are the
|
||||
standardization of data-formats (like integer and string encoding) so
|
||||
we create a more consistent system.
|
||||
we create a more consistent system.
|
||||
One thing we shall not inherit from XML is its text-based format. Instead
|
||||
we use the [https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md Compact Message Format]
|
||||
(CMF) which is optimized to keep the size small and fast to parse.
|
||||
|
||||
@ -43,13 +43,13 @@ By removing this data from the transaction structure committed to the transactio
|
||||
A new data structure, <code>witness</code>, is defined. Each transaction will have 2 IDs.
|
||||
|
||||
Definition of <code>txid</code> remains unchanged: the double SHA256 of the traditional serialization format:
|
||||
|
||||
|
||||
[nVersion][txins][txouts][nLockTime]
|
||||
|
||||
|
||||
A new <code>wtxid</code> is defined: the double SHA256 of the new serialization with witness data:
|
||||
|
||||
|
||||
[nVersion][marker][flag][txins][txouts][witness][nLockTime]
|
||||
|
||||
|
||||
Format of <code>nVersion</code>, <code>txins</code>, <code>txouts</code>, and <code>nLockTime</code> are same as traditional serialization.
|
||||
|
||||
The <code>marker</code> MUST be a 1-byte zero value: <code>0x00</code>.
|
||||
@ -67,14 +67,14 @@ A new block rule is added which requires a commitment to the <code>wtxid</code>.
|
||||
A <code>witness root hash</code> is calculated with all those <code>wtxid</code> as leaves, in a way similar to the <code>hashMerkleRoot</code> in the block header.
|
||||
|
||||
The commitment is recorded in a <code>scriptPubKey</code> of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is:
|
||||
|
||||
|
||||
1-byte - OP_RETURN (0x6a)
|
||||
1-byte - Push the following 36 bytes (0x24)
|
||||
4-byte - Commitment header (0xaa21a9ed)
|
||||
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)
|
||||
|
||||
|
||||
39th byte onwards: Optional data with no consensus meaning
|
||||
|
||||
|
||||
and the coinbase's input's witness must consist of a single 32-byte array for the <code>witness reserved value</code>.
|
||||
|
||||
If there are more than one <code>scriptPubKey</code> matching the pattern, the one with highest output index is assumed to be the commitment.
|
||||
|
||||
@ -24,14 +24,14 @@ To define standard payment address for native segregated witness (segwit) transa
|
||||
The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH).
|
||||
|
||||
The new address is encoded in a way similar to existing address formats:
|
||||
|
||||
|
||||
base58-encode:
|
||||
[1-byte address version]
|
||||
[1-byte witness program version]
|
||||
[0x00]
|
||||
[20/32-byte-hash]
|
||||
[4-byte checksum]
|
||||
|
||||
|
||||
For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address.
|
||||
|
||||
For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address.
|
||||
@ -123,25 +123,25 @@ This proposal is forward-compatible with future versions of witness programs of
|
||||
== Example ==
|
||||
|
||||
The following public key,
|
||||
|
||||
|
||||
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
|
||||
|
||||
|
||||
when encoded as a P2PKH template, would become:
|
||||
|
||||
|
||||
DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
|
||||
|
||||
With the corresponding version 1 Bitcoin address being:
|
||||
|
||||
|
||||
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
|
||||
|
||||
When the same public key is encoded as P2WPKH, the scriptPubKey becomes:
|
||||
|
||||
|
||||
When the same public key is encoded as P2WPKH, the scriptPubKey becomes:
|
||||
|
||||
OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
|
||||
|
||||
Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
|
||||
|
||||
|
||||
p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
|
||||
|
||||
|
||||
== Reference implementation ==
|
||||
|
||||
https://github.com/theuni/bitcoin/commit/ede1b57058ac8efdefe61f67395affb48f2c0d80
|
||||
|
||||
@ -31,7 +31,7 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
|
||||
1. nVersion of the transaction (4-byte little endian)
|
||||
2. hashPrevouts (32-byte hash)
|
||||
3. hashSequence (32-byte hash)
|
||||
4. outpoint (32-byte hash + 4-byte little endian)
|
||||
4. outpoint (32-byte hash + 4-byte little endian)
|
||||
5. scriptCode of the input (serialized as scripts inside CTxOuts)
|
||||
6. value of the output spent by this input (8-byte little endian)
|
||||
7. nSequence of the input (4-byte little endian)
|
||||
@ -77,7 +77,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
|
||||
uint256 hashPrevouts;
|
||||
uint256 hashSequence;
|
||||
uint256 hashOutputs;
|
||||
|
||||
|
||||
if (!(nHashType & SIGHASH_ANYONECANPAY)) {
|
||||
CHashWriter ss(SER_GETHASH, 0);
|
||||
for (unsigned int n = 0; n < txTo.vin.size(); n++) {
|
||||
@ -85,7 +85,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
|
||||
}
|
||||
hashPrevouts = ss.GetHash();
|
||||
}
|
||||
|
||||
|
||||
if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
|
||||
CHashWriter ss(SER_GETHASH, 0);
|
||||
for (unsigned int n = 0; n < txTo.vin.size(); n++) {
|
||||
@ -93,7 +93,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
|
||||
}
|
||||
hashSequence = ss.GetHash();
|
||||
}
|
||||
|
||||
|
||||
if ((nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
|
||||
CHashWriter ss(SER_GETHASH, 0);
|
||||
for (unsigned int n = 0; n < txTo.vout.size(); n++) {
|
||||
@ -105,7 +105,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
|
||||
ss << txTo.vout[nIn];
|
||||
hashOutputs = ss.GetHash();
|
||||
}
|
||||
|
||||
|
||||
CHashWriter ss(SER_GETHASH, 0);
|
||||
// Version
|
||||
ss << txTo.nVersion;
|
||||
@ -125,7 +125,7 @@ Refer to the reference implementation, reproduced below, for the precise algorit
|
||||
ss << txTo.nLockTime;
|
||||
// Sighash type
|
||||
ss << nHashType;
|
||||
|
||||
|
||||
return ss.GetHash();
|
||||
</source>
|
||||
|
||||
@ -139,42 +139,42 @@ Since this policy is preparation for a future softfork proposal, to avoid potent
|
||||
To ensure consistency in consensus-critical behaviour, developers should test their implementations against all the tests below. More tests related to this proposal could be found under https://github.com/bitcoin/bitcoin/tree/master/src/test/data .
|
||||
|
||||
=== Native P2WPKH ===
|
||||
|
||||
|
||||
The following is an unsigned transaction:
|
||||
0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
txin: 02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff
|
||||
ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
|
||||
txout: 02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
|
||||
9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
|
||||
nLockTime: 11000000
|
||||
|
||||
|
||||
The first input comes from an ordinary P2PK:
|
||||
scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
|
||||
private key : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866
|
||||
|
||||
|
||||
The second input comes from a P2WPKH witness program:
|
||||
scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6
|
||||
private key : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9
|
||||
public key : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
|
||||
|
||||
|
||||
To sign it with a nHashType of 1 (SIGHASH_ALL):
|
||||
|
||||
|
||||
hashPrevouts:
|
||||
dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
|
||||
= 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
|
||||
|
||||
|
||||
hashSequence:
|
||||
dSHA256(eeffffffffffffff)
|
||||
= 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
|
||||
|
||||
|
||||
hashOutputs:
|
||||
dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac)
|
||||
= 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
|
||||
|
||||
|
||||
hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
|
||||
hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
|
||||
@ -185,12 +185,12 @@ To ensure consistency in consensus-critical behaviour, developers should test th
|
||||
hashOutputs: 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
|
||||
nLockTime: 11000000
|
||||
nHashType: 01000000
|
||||
|
||||
|
||||
sigHash: c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670
|
||||
signature: 304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01
|
||||
|
||||
|
||||
The serialized signed transaction is: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
marker: 00
|
||||
flag: 01
|
||||
@ -203,38 +203,38 @@ To ensure consistency in consensus-critical behaviour, developers should test th
|
||||
nLockTime: 11000000
|
||||
|
||||
=== P2SH-P2WPKH ===
|
||||
|
||||
|
||||
|
||||
|
||||
The following is an unsigned transaction: 0100000001db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a54770100000000feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac92040000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
txin: 01 db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477 01000000 00 feffffff
|
||||
txout: 02 b8b4eb0b00000000 1976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac
|
||||
0008af2f00000000 1976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac
|
||||
nLockTime: 92040000
|
||||
|
||||
|
||||
The input comes from a P2SH-P2WPKH witness program:
|
||||
scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10
|
||||
redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089
|
||||
private key : eb696a065ef48a2192da5b28b694f87544b30fae8327c4510137a922f32c6dcf
|
||||
public key : 03ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a26873
|
||||
|
||||
|
||||
To sign it with a nHashType of 1 (SIGHASH_ALL):
|
||||
|
||||
|
||||
hashPrevouts:
|
||||
dSHA256(db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a547701000000)
|
||||
= b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a
|
||||
|
||||
|
||||
hashSequence:
|
||||
dSHA256(feffffff)
|
||||
= 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198
|
||||
|
||||
|
||||
hashOutputs:
|
||||
dSHA256(b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac)
|
||||
= de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83
|
||||
|
||||
|
||||
hash preimage: 01000000b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001976a91479091972186c449eb1ded22b78e40d009bdf008988ac00ca9a3b00000000feffffffde984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c839204000001000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
hashPrevouts: b0287b4a252ac05af83d2dcef00ba313af78a3e9c329afa216eb3aa2a7b4613a
|
||||
hashSequence: 18606b350cd8bf565266bc352f0caddcf01e8fa789dd8a15386327cf8cabe198
|
||||
@ -245,10 +245,10 @@ To ensure consistency in consensus-critical behaviour, developers should test th
|
||||
hashOutputs: de984f44532e2173ca0d64314fcefe6d30da6f8cf27bafa706da61df8a226c83
|
||||
nLockTime: 92040000
|
||||
nHashType: 01000000
|
||||
|
||||
|
||||
sigHash: 64f3b0f4dd2bb3aa1ce8566d220cc74dda9df97d8490cc81d89d735c92e59fb6
|
||||
signature: 3044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb01
|
||||
|
||||
|
||||
The serialized signed transaction is: 01000000000101db6b1b20aa0fd7b23880be2ecbd4a98130974cf4748fb66092ac4d3ceb1a5477010000001716001479091972186c449eb1ded22b78e40d009bdf0089feffffff02b8b4eb0b000000001976a914a457b684d7f0d539a46a45bbc043f35b59d0d96388ac0008af2f000000001976a914fd270b1ee6abcaea97fea7ad0402e8bd8ad6d77c88ac02473044022047ac8e878352d3ebbde1c94ce3a10d057c24175747116f8288e5d794d12d482f0220217f36a485cae903c713331d877c1f64677e3622ad4010726870540656fe9dcb012103ad1d8e89212f0b92c74d23bb710c00662ad1470198ac48c43f7d6f93a2a2687392040000
|
||||
nVersion: 01000000
|
||||
marker: 00
|
||||
@ -263,33 +263,33 @@ To ensure consistency in consensus-critical behaviour, developers should test th
|
||||
|
||||
This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGHASH_SINGLE</code> are processed:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following is an unsigned transaction:
|
||||
0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
txin: 02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff
|
||||
0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff
|
||||
txout: 01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac
|
||||
nLockTime: 00000000
|
||||
|
||||
|
||||
The first input comes from an ordinary P2PK:
|
||||
scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
|
||||
private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
|
||||
signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)
|
||||
|
||||
|
||||
The second input comes from a native P2WSH witness program:
|
||||
scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
|
||||
witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
|
||||
<026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG
|
||||
|
||||
|
||||
To sign it with a nHashType of 3 (SIGHASH_SINGLE):
|
||||
|
||||
|
||||
hashPrevouts:
|
||||
dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)
|
||||
= ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
|
||||
hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
|
||||
@ -300,7 +300,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
|
||||
hashOutputs: 0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)
|
||||
nLockTime: 00000000
|
||||
nHashType: 03000000
|
||||
|
||||
|
||||
scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
|
||||
^^
|
||||
(please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
|
||||
@ -309,7 +309,7 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
|
||||
public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
|
||||
private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
|
||||
signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
|
||||
|
||||
|
||||
scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
|
||||
(everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
|
||||
preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
|
||||
@ -317,36 +317,36 @@ This example shows how <code>OP_CODESEPARATOR</code> and out-of-range <code>SIGH
|
||||
public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
|
||||
private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
|
||||
signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
|
||||
|
||||
|
||||
The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000
|
||||
|
||||
|
||||
This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, and <code>SINGLE|ANYONECANPAY</code> does not commit to the input index:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following is an unsigned transaction:
|
||||
0100000002e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac00000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
txin: 02 e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc001 00000000 00 ffffffff
|
||||
80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b 00000000 00 ffffffff
|
||||
txout: 02 8096980000000000 1976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac
|
||||
8096980000000000 1976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac
|
||||
nLockTime: 00000000
|
||||
|
||||
|
||||
The first input comes from a native P2WSH witness program:
|
||||
scriptPubKey: 0020ba468eea561b26301e4cf69fa34bde4ad60c81e70f059f045ca9a79931004a4d value: 0.16777215
|
||||
witnessScript:0063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
|
||||
0 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
|
||||
|
||||
|
||||
The second input comes from a native P2WSH witness program:
|
||||
scriptPubKey: 0020d9bbfbe56af7c4b7f960a70d7ea107156913d9e5a26b0a71429df5e097ca6537 value: 0.16777215
|
||||
witnessScript:5163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
|
||||
1 IF CODESEPARATOR ENDIF <0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98> CHECKSIG
|
||||
|
||||
|
||||
To sign it with a nHashType of 0x83 (SINGLE|ANYONECANPAY):
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
|
||||
hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
|
||||
@ -357,7 +357,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
|
||||
hashOutputs: (see below)
|
||||
nLockTime: 00000000
|
||||
nHashType: 83000000
|
||||
|
||||
|
||||
outpoint: e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc00100000000
|
||||
scriptCode: 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
|
||||
(since the OP_CODESEPARATOR is not executed, nothing is removed from the scriptCode)
|
||||
@ -367,7 +367,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
|
||||
public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98
|
||||
private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d
|
||||
signature: 3045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683
|
||||
|
||||
|
||||
outpoint: 80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b00000000
|
||||
scriptCode: 2468210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
|
||||
(everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
|
||||
@ -377,7 +377,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
|
||||
public key: 0392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98
|
||||
private key: f52b3484edd96598e02a9c89c4492e9c1e2031f471c49fd721fe68b3ce37780d
|
||||
signature: 30440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83
|
||||
|
||||
|
||||
The serialized signed transaction is:
|
||||
01000000000102e9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff80e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffff0280969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac80969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
|
||||
nVersion: 01000000
|
||||
@ -390,7 +390,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
|
||||
witness 02 483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683 270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
|
||||
02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac
|
||||
nLockTime: 00000000
|
||||
|
||||
|
||||
Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped:
|
||||
0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000
|
||||
nVersion: 01000000
|
||||
@ -408,37 +408,37 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an
|
||||
|
||||
This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 different <code>SIGHASH</code> types.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following is an unsigned transaction: 010000000136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000000ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac00000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
txin: 01 36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e 01000000 00 ffffffff
|
||||
txout: 02 00e9a43500000000 1976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac
|
||||
c0832f0500000000 1976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac
|
||||
nLockTime: 00000000
|
||||
|
||||
|
||||
The input comes from a P2SH-P2WSH 6-of-6 multisig witness program:
|
||||
scriptPubKey : a9149993a429037b5d912407a71c252019287b8d27a587, value: 9.87654321
|
||||
redeemScript : 0020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54
|
||||
witnessScript: 56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae
|
||||
|
||||
|
||||
hashPrevouts:
|
||||
dSHA256(36641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000)
|
||||
= 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
|
||||
|
||||
|
||||
hashSequence:
|
||||
dSHA256(ffffffff)
|
||||
= 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
|
||||
|
||||
|
||||
hashOutputs for ALL:
|
||||
dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac)
|
||||
= bc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc
|
||||
|
||||
|
||||
hashOutputs for SINGLE:
|
||||
dSHA256(00e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688ac)
|
||||
= 9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f708
|
||||
|
||||
|
||||
hash preimage for ALL: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa03bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504436641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000001000000
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
|
||||
@ -454,7 +454,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
public key: 0307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba3
|
||||
private key: 730fff80e1413068a05b57d6a58261f07551163369787f349438ea38ca80fac6
|
||||
signature: 304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01
|
||||
|
||||
|
||||
hash preimage for NONE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000002000000
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
|
||||
@ -470,7 +470,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
public key: 03b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b
|
||||
private key: 11fa3d25a17cbc22b29c44a484ba552b5a53149d106d3d853e22fdd05a2d8bb3
|
||||
signature: 3044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502
|
||||
|
||||
|
||||
hash preimage for SINGLE: 0100000074afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000003000000
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 74afdc312af5183c4198a40ca3c1a275b485496dd3929bca388c4b5e31f7aaa0
|
||||
@ -486,7 +486,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
public key: 034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a
|
||||
private key: 77bf4141a87d55bdd7f3cd0bdccf6e9e642935fec45f2f30047be7b799120661
|
||||
signature: 3044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403
|
||||
|
||||
|
||||
hash preimage for ALL|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffffbc4d309071414bed932f98832b27b4d76dad7e6c1346f487a8fdbb8eb90307cc0000000081000000
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
|
||||
@ -502,7 +502,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
public key: 033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f4
|
||||
private key: 14af36970f5025ea3e8b5542c0f8ebe7763e674838d08808896b63c3351ffe49
|
||||
signature: 3045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381
|
||||
|
||||
|
||||
hash preimage for NONE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000082000000
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
|
||||
@ -518,7 +518,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
public key: 03a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac16
|
||||
private key: fe9a95c19eef81dde2b95c1284ef39be497d128e2aa46916fb02d552485e0323
|
||||
signature: 3045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a0882
|
||||
|
||||
|
||||
hash preimage for SINGLE|ANYONECANPAY: 010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000036641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e01000000cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56aeb168de3a00000000ffffffff9efe0c13a6b16c14a41b04ebe6a63f419bdacb2f8705b494a43063ca3cd4f7080000000083000000
|
||||
nVersion: 01000000
|
||||
hashPrevouts: 0000000000000000000000000000000000000000000000000000000000000000
|
||||
@ -534,7 +534,7 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
public key: 02d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b
|
||||
private key: 428a7aee9f0c2af0cd19af3cf1c78149951ea528726989b2e83e4778d2c3f890
|
||||
signature: 30440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783
|
||||
|
||||
|
||||
The serialized signed transaction is: 0100000000010136641869ca081e70f394c6948e8af409e18b619df2ed74aa106c1ca29787b96e0100000023220020a16b5755f7f6f96dbd65f5f0d6ab9418b89af4b1f14a1bb8a09062c35f0dcb54ffffffff0200e9a435000000001976a914389ffce9cd9ae88dcc0631e88a821ffdbe9bfe2688acc0832f05000000001976a9147480a33f950689af511e6e84c138dbbd3c3ee41588ac080047304402206ac44d672dac41f9b00e28f4df20c52eeb087207e8d758d76d92c6fab3b73e2b0220367750dbbe19290069cba53d096f44530e4f98acaa594810388cf7409a1870ce01473044022068c7946a43232757cbdf9176f009a928e1cd9a1a8c212f15c1e11ac9f2925d9002205b75f937ff2f9f3c1246e547e54f62e027f64eefa2695578cc6432cdabce271502473044022059ebf56d98010a932cf8ecfec54c48e6139ed6adb0728c09cbe1e4fa0915302e022007cd986c8fa870ff5d2b3a89139c9fe7e499259875357e20fcbb15571c76795403483045022100fbefd94bd0a488d50b79102b5dad4ab6ced30c4069f1eaa69a4b5a763414067e02203156c6a5c9cf88f91265f5a942e96213afae16d83321c8b31bb342142a14d16381483045022100a5263ea0553ba89221984bd7f0b13613db16e7a70c549a86de0cc0444141a407022005c360ef0ae5a5d4f9f2f87a56c1546cc8268cab08c73501d6b3be2e1e1a8a08824730440220525406a1482936d5a21888260dc165497a90a15669636d8edca6b9fe490d309c022032af0c646a34a44d1f4576bf6a4a74b67940f8faa84c7df9abe12a01a11e2b4783cf56210307b8ae49ac90a048e9b53357a2354b3334e9c8bee813ecb98e99a7e07e8c3ba32103b28f0c28bfab54554ae8c658ac5c3e0ce6e79ad336331f78c428dd43eea8449b21034b8113d703413d57761b8b9781957b8c0ac1dfe69f492580ca4195f50376ba4a21033400f6afecb833092a9a21cfdf1ed1376e58c5d1f47de74683123987e967a8f42103a6d48b1131e94ba04d9737d61acdaa1322008af9602b3b14862c07a1789aac162102d8b661b0b3302ee2f162b09e07a55ad5dfbe673a9f01d9f0c19617681024306b56ae00000000
|
||||
|
||||
|
||||
@ -542,35 +542,35 @@ This example is a P2SH-P2WSH 6-of-6 multisig witness program signed with 6 diffe
|
||||
|
||||
These examples show that <code>FindAndDelete</code> for the signature is not applied. The transactions are generated in an unconventional way. Instead of signing using a private key, the signatures are pre-determined as part of <code>witnessScript</code>. The public keys are generated with key recovery, using the fixed signatures and the <code>sighash</code> defined in this proposal. Therefore, the private keys are unknown.
|
||||
|
||||
|
||||
|
||||
The following is an unsigned transaction: 010000000169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff0101000000000000000000000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
txin: 01 69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f1 4c1d0000 00 ffffffff
|
||||
txout: 01 0100000000000000 00
|
||||
nLockTime: 00000000
|
||||
|
||||
|
||||
The input comes from a P2WSH witness program:
|
||||
scriptPubKey : 00209e1be07558ea5cc8e02ed1d80c0911048afad949affa36d5c3951e3159dbea19, value: 0.00200000
|
||||
redeemScript : OP_CHECKSIGVERIFY <0x30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01>
|
||||
ad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
|
||||
|
||||
|
||||
To sign it with a nHashType of 1 (SIGHASH_ALL):
|
||||
|
||||
|
||||
hashPrevouts:
|
||||
dSHA256(69c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d0000)
|
||||
= b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
|
||||
|
||||
|
||||
hashSequence:
|
||||
dSHA256(ffffffff)
|
||||
= 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
|
||||
|
||||
|
||||
hashOutputs:
|
||||
dSHA256(010000000000000000)
|
||||
= e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
|
||||
|
||||
|
||||
hash preimage: 01000000b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504469c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d00004aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
|
||||
|
||||
|
||||
nVersion: 01000000
|
||||
hashPrevouts: b67c76d200c6ce72962d919dc107884b9d5d0e26f2aea7474b46a1904c53359f
|
||||
hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
|
||||
@ -581,11 +581,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app
|
||||
hashOutputs: e5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b934228
|
||||
nLockTime: 00000000
|
||||
nHashType: 01000000
|
||||
|
||||
|
||||
sigHash: 71c9cd9b2869b9c70b01b1f0360c148f42dee72297db312638df136f43311f23
|
||||
signature: 30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e 01
|
||||
pubkey: 02a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
|
||||
|
||||
|
||||
The serialized signed transaction is: 0100000000010169c12106097dc2e0526493ef67f21269fe888ef05c7a3a5dacab38e1ac8387f14c1d000000ffffffff01010000000000000000034830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e012102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0100000000
|
||||
|
||||
nVersion: 01000000
|
||||
@ -597,11 +597,11 @@ These examples show that <code>FindAndDelete</code> for the signature is not app
|
||||
2102a9781d66b61fb5a7ef00ac5ad5bc6ffc78be7b44a566e3c87870e1079368df4c
|
||||
4aad4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01
|
||||
nLockTime: 00000000
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following transaction is a <code>OP_CHECKMULTISIGVERIFY</code> version of the <code>FindAndDelete</code> examples: 010000000001019275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d000000ffffffff0101000000000000000007004830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960101022102966f109c54e85d3aee8321301136cedeb9fc710fdef58a9de8a73942f8e567c021034ffc99dd9a79dd3cb31e2ab3e0b09e0e67db41ac068c625cd1f491576016c84e9552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c039596017500000000
|
||||
|
||||
|
||||
redeemScript: OP_2 OP_CHECKMULTISIGVERIFY <30450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e01> <304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c03959601>
|
||||
hash preimage: 0100000039283953eb1e26994dde57b7f9362a79a8c523e2f8deba943c27e826a005f1e63bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449275cb8d4a485ce95741c013f7c0d28722160008021bb469a11982d47a6628964c1d00009552af4830450220487fb382c4974de3f7d834c1b617fe15860828c7f96454490edd6d891556dcc9022100baf95feb48f845d5bfc9882eb6aeefa1bc3790e39f59eaa46ff7f15ae626c53e0148304502205286f726690b2e9b0207f0345711e63fa7012045b9eb0f19c2458ce1db90cf43022100e89f17f86abc5b149eba4115d4f128bcf45d77fb3ecdd34f594091340c0395960175400d030000000000ffffffffe5d196bfb21caca9dbd654cafb3b4dc0c4882c8927d2eb300d9539dd0b9342280000000001000000
|
||||
sighash: c1628a1e7c67f14ca0c27c06e4fdeec2e6d1a73c7a91d7c046ff83e835aebb72
|
||||
@ -618,7 +618,7 @@ The new serialization format is described in BIP144 <ref>[[bip-0144.mediawiki|BI
|
||||
|
||||
== Deployment ==
|
||||
|
||||
This proposal is deployed with Segregated Witness softfork (BIP 141)
|
||||
This proposal is deployed with Segregated Witness softfork (BIP 141)
|
||||
|
||||
== Backward compatibility ==
|
||||
|
||||
|
||||
@ -79,7 +79,7 @@ The serialization has the following structure:
|
||||
|
||||
Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.
|
||||
|
||||
If the witness is empty, the old serialization format must be used.
|
||||
If the witness is empty, the old serialization format must be used.
|
||||
|
||||
Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins.
|
||||
|
||||
|
||||
@ -71,7 +71,7 @@ solve the challenge and reconnect, or discard it and find a different peer (or w
|
||||
|
||||
There are two POW identifiers currently. When a new identifier is introduced, it should be added with an increment of 1
|
||||
to the last identifier in the list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should
|
||||
retain its place in the list indefinitely.
|
||||
retain its place in the list indefinitely.
|
||||
|
||||
{|class="wikitable"
|
||||
! ID !! Algorithm Name !! Work !! Param size !! Solution size !! Provably Secure !! SPH Resistance !! Status
|
||||
@ -173,7 +173,7 @@ Additional notes:
|
||||
There is only one Purpose Identifier currently. In the future, more Purpose Identifiers could be added for at-DoS-risk operations,
|
||||
such as bloom filters. When a new identifier is introduced, it should be added with an increment of 1 to the last identifier in the
|
||||
list. When an identifier is deprecated, its status should be changed to <code>Deprecated</code> but it should retain its place in
|
||||
the list indefinitely.
|
||||
the list indefinitely.
|
||||
|
||||
{|class="wikitable"
|
||||
! ID !! Purpose Name !! Description !! Status
|
||||
@ -236,7 +236,7 @@ Normally mid-layer (all but the last) POW algorithms have a zero-length input. E
|
||||
|-
|
||||
| 1..4 || pow-id || 1 || sha256
|
||||
|-
|
||||
| 5 || pow-params (config_length) || 9 ||
|
||||
| 5 || pow-params (config_length) || 9 ||
|
||||
|-
|
||||
| 6..9 || pow-params (target) || 0x207fffff || Resulting hash must be <= the compact hash 0x207fffff*
|
||||
|-
|
||||
@ -248,7 +248,7 @@ Normally mid-layer (all but the last) POW algorithms have a zero-length input. E
|
||||
|-
|
||||
| 19..22 || pow-id || 2 || cuckoo-cycle
|
||||
|-
|
||||
| 23 || pow-params (config_length) || 8 ||
|
||||
| 23 || pow-params (config_length) || 8 ||
|
||||
|-
|
||||
| 24 || pow-params (sizeshift) || 28
|
||||
|-
|
||||
|
||||
@ -44,7 +44,7 @@ interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RF
|
||||
|
||||
The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>.
|
||||
It is serialized in the standard encoding for P2P messages.
|
||||
Its format is similar to the current <code>addr</code> message format, with the difference that the
|
||||
Its format is similar to the current <code>addr</code> message format, with the difference that the
|
||||
fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
|
||||
|
||||
This means that the message contains a serialized <code>std::vector</code> of the following structure:
|
||||
|
||||
@ -109,7 +109,7 @@ Figure 3
|
||||
|
||||
To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound peer is
|
||||
assigned a particular Dandelion destination. Each Dandelion transaction that
|
||||
arrives via this peer is forwarded to the same Dandelion destination.
|
||||
arrives via this peer is forwarded to the same Dandelion destination.
|
||||
Per-inbound-edge routing breaks the described attack by blocking an adversary's
|
||||
ability to construct useful fingerprints. Fingerprints arise when routing
|
||||
decisions are made independently per transaction at each node. In this case, two
|
||||
|
||||
@ -50,7 +50,7 @@ Pruned peers following this BIP may consume more outbound bandwidth.
|
||||
|
||||
Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
|
||||
|
||||
== Compatibility ==
|
||||
== Compatibility ==
|
||||
|
||||
This proposal is backward compatible.
|
||||
|
||||
|
||||
@ -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.
|
||||
Although some PSBT version 0 implementations encode types as uint8_t rather than compact size,
|
||||
it is still safe to add >0xFD fields to PSBT 0, because these old parsers ignore
|
||||
unknown fields, and <keytype> is prefixed by its length.
|
||||
unknown fields, and <keytype> is prefixed by its length.
|
||||
|
||||
===Procedure For New Versions===
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ The term "bit" has many different definitions, but the ones of particular note a
|
||||
* bit meaning some amount of data (e.g., the first bit of the version field is 0)
|
||||
* bit meaning strength of a cryptographic algorithm (e.g., 256-bit ECDSA is used in Bitcoin)
|
||||
|
||||
The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means.
|
||||
The first is a bit dated and isn't likely to confuse people dealing with Bitcoin. The second and third are computer science terms and context should be sufficient to figure out what the user of the word means.
|
||||
|
||||
== Copyright ==
|
||||
This BIP is licensed under the BSD 2-clause license.
|
||||
|
||||
@ -19,13 +19,13 @@ This BIP describes a script for generalized off-chain contract negotiation.
|
||||
|
||||
==Summary==
|
||||
|
||||
A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits
|
||||
A Hashed Time-Locked Contract (HTLC) is a script that permits a designated party (the "seller") to spend funds by disclosing the preimage of a hash. It also permits
|
||||
a second party (the "buyer") to spend the funds after a timeout is reached, in a refund situation.
|
||||
|
||||
The script takes the following form:
|
||||
|
||||
OP_IF
|
||||
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
|
||||
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
|
||||
OP_ELSE
|
||||
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
|
||||
OP_ENDIF
|
||||
@ -44,28 +44,28 @@ The script takes the following form:
|
||||
** Peggy spends the funds, and in doing so, reveals the preimage to Victor in the transaction; OR
|
||||
** Victor recovers the funds after the timeout threshold.
|
||||
|
||||
Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is
|
||||
interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does
|
||||
Victor is interested in a lower timeout to reduce the amount of time that his funds are encumbered in the event that Peggy does not reveal the preimage. Peggy is
|
||||
interested in a higher timeout to reduce the risk that she is unable to spend the funds before the threshold, or worse, that her transaction spending the funds does
|
||||
not enter the blockchain before Victor's but does reveal the preimage to Victor anyway.
|
||||
|
||||
==Motivation==
|
||||
|
||||
In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are
|
||||
a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the
|
||||
In many off-chain protocols, secret disclosure is used as part of a settlement mechanism. In some others, the secrets themselves are valuable. HTLC transactions are
|
||||
a safe and cheap method of exchanging secrets for money over the blockchain, due to the ability to recover funds from an uncooperative counterparty, and the
|
||||
opportunity that the possessor of a secret has to receive the funds before such a refund can occur.
|
||||
|
||||
===Lightning network===
|
||||
|
||||
In the lightning network, HTLC scripts are used to perform atomic swaps between payment channels.
|
||||
|
||||
Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and
|
||||
amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If
|
||||
Alice constructs K and hashes it to produce L. She sends an HTLC payment to Bob for the preimage of L. Bob sends an HTLC payment to Carol for the same preimage and
|
||||
amount. Only when Alice releases the preimage K does any exchange of value occur, and because the secret is divulged for each hop, all parties are compensated. If
|
||||
at any point some parties become uncooperative, the process can be aborted via the refund conditions.
|
||||
|
||||
===Zero-knowledge contingent payments===
|
||||
|
||||
Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a
|
||||
zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See
|
||||
Various practical zero-knowledge proving systems exist which can be used to guarantee that a hash preimage derives valuable information. As an example, a
|
||||
zero-knowledge proof can be used to prove that a hash preimage acts as a decryption key for an encrypted sudoku puzzle solution. (See
|
||||
[https://github.com/zcash/pay-to-sudoku pay-to-sudoku] for a concrete example of such a protocol.)
|
||||
|
||||
HTLC transactions can be used to exchange such decryption keys for money without risk, and they do not require large or expensive-to-validate transactions.
|
||||
|
||||
@ -213,7 +213,7 @@ M2 is invalid if:
|
||||
* An M2 is already in this block.
|
||||
* It tries to ACK two different M1s for the same slot.
|
||||
|
||||
Otherwise:
|
||||
Otherwise:
|
||||
|
||||
* The sidechain is "ACK"ed and does NOT get a "fail" for this block. (As it otherwise would.)
|
||||
|
||||
@ -242,7 +242,7 @@ Sidechain withdrawals take the form of "Bundles" -- named because they "bundle u
|
||||
|
||||
Sidechain full nodes aggregate the withdrawal-requests into a big set. The sidechain calculates what M6 would have to look like, to pay all of these withdrawal-requests out. Finally, the sidechain calculates what the hash of this M6 would be. This 32-byte hash identifies the Bundle.
|
||||
|
||||
This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).
|
||||
This 32-byte hash is what miners will be slowly ACKing over 3-6 months, not the M6 itself (nor any sidechain data, of course).
|
||||
|
||||
A bundle either pays all its withdrawals out (via M6), or else it fails (and pays nothing out).
|
||||
|
||||
@ -283,7 +283,7 @@ M4 is a coinbase OP Return output containing the following:
|
||||
1-byte - Version
|
||||
n-byte - The "upvote vector" -- describes which bundle-choice is "upvoted", for each sidechain.
|
||||
|
||||
The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted".
|
||||
The upvote vector will code "abstain" as 0xFF (or 0xFFFF); it will code "alarm" as 0xFE (or 0xFFFE). Otherwise it simply indicates which withdrawal-bundle in the list, is the one to be "upvoted".
|
||||
|
||||
For example: if there are two sidechains, and we wish to upvote the 7th bundle on sidechain #1 plus the 4th bundle on sidechain #2, then the upvote vector would be { 07, 04 }. And M4 would be [0x6A,D77D1776,00,0006,0003].
|
||||
|
||||
@ -313,7 +313,7 @@ Important: Within a sidechain-group, upvoting one Bundle ("+1") automatically do
|
||||
|
||||
For example:
|
||||
|
||||
{| class="wikitable"
|
||||
{| class="wikitable"
|
||||
|-
|
||||
! SC#
|
||||
! Bundle Hash
|
||||
@ -350,7 +350,7 @@ For example:
|
||||
...in block 900,000 could become...
|
||||
|
||||
|
||||
{| class="wikitable"
|
||||
{| class="wikitable"
|
||||
|-
|
||||
! SC#
|
||||
! Bundle Hash
|
||||
@ -414,7 +414,7 @@ M6 is invalid if:
|
||||
* The txn fee of M6 is NOT exactly equal to the amount of the previous bullet point.
|
||||
* There are additional OP_DRIVECHAIN outputs after the first one.
|
||||
|
||||
Else, M6 is valid.
|
||||
Else, M6 is valid.
|
||||
|
||||
(The point of the latter two bullet points, is to allow the bundle hash to cover the L1 transaction fee.)
|
||||
|
||||
@ -485,7 +485,7 @@ As a soft fork, older software will continue to operate without modification. No
|
||||
|
||||
==Deployment==
|
||||
|
||||
This BIP will be deployed via UASF-style block height activation. Block height TBD.
|
||||
This BIP will be deployed via UASF-style block height activation. Block height TBD.
|
||||
|
||||
|
||||
==Reference Implementation==
|
||||
|
||||
@ -89,7 +89,7 @@ So we will discuss:
|
||||
|
||||
=== h* ===
|
||||
|
||||
h* ("h star") is the sidechain's Merkle Root hash.
|
||||
h* ("h star") is the sidechain's Merkle Root hash.
|
||||
|
||||
In Bip301, a sidechain's coinbase txn acts as a header (it contains the hash of the previous side:block, and previous main:block). Thus, the MerkleRoot contains everything important.
|
||||
|
||||
|
||||
@ -39,8 +39,8 @@ The Electrum wallet imports and exports address and transaction labels in a JSON
|
||||
|
||||
==Specification==
|
||||
|
||||
In order to be lightweight, human readable and well structured, this BIP uses a JSON format.
|
||||
Further, the JSON Lines format is used (also called newline-delimited JSON)<ref>[https://jsonlines.org/ jsonlines.org]</ref>.
|
||||
In order to be lightweight, human readable and well structured, this BIP uses a JSON format.
|
||||
Further, the JSON Lines format is used (also called newline-delimited JSON)<ref>[https://jsonlines.org/ jsonlines.org]</ref>.
|
||||
This allows a document to be split, streamed, or incrementally added to, and limits the potential for formatting errors to invalidate an entire import.
|
||||
It is also a convenient format for command-line processing, which is often line-oriented.
|
||||
|
||||
@ -48,7 +48,7 @@ Further to the JSON Lines specification, an export of labels from a wallet must
|
||||
Lines are separated by <tt>\n</tt>. Multiline values are not permitted.
|
||||
Each JSON object must contain 3 or 4 key/value pairs, defined as follows:
|
||||
|
||||
{| class="wikitable"
|
||||
{| class="wikitable"
|
||||
|-
|
||||
! Key
|
||||
! Description
|
||||
@ -71,7 +71,7 @@ Each JSON object must contain 3 or 4 key/value pairs, defined as follows:
|
||||
|
||||
The reference is defined for each <tt>type</tt> as follows:
|
||||
|
||||
{| class="wikitable"
|
||||
{| class="wikitable"
|
||||
|-
|
||||
! Type
|
||||
! Description
|
||||
@ -107,7 +107,7 @@ Each JSON object must contain both <tt>type</tt> and <tt>ref</tt> properties. Th
|
||||
If present, the optional <tt>origin</tt> property must contain an abbreviated output descriptor (as defined by BIP380<ref>[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]</ref>) describing a BIP32 compatible originating wallet, including all key origin information but excluding any actual keys, any child path elements, or a checksum.
|
||||
This property should be used to disambiguate transaction labels from different wallets contained in the same export, particularly when exporting multiple accounts derived from the same seed.
|
||||
|
||||
Care should be taken when exporting due to the privacy sensitive nature of the data.
|
||||
Care should be taken when exporting due to the privacy sensitive nature of the data.
|
||||
Encryption in transit over untrusted networks is highly recommended, and encryption at rest should also be considered.
|
||||
Unencrypted exports should be deleted as soon as possible.
|
||||
For security reasons no private key types are defined.
|
||||
@ -120,7 +120,7 @@ For security reasons no private key types are defined.
|
||||
|
||||
==Backwards Compatibility==
|
||||
|
||||
The nature of this format makes it naturally extensible to handle other record types.
|
||||
The nature of this format makes it naturally extensible to handle other record types.
|
||||
However, importing wallets complying to this specification may ignore types not defined here.
|
||||
|
||||
==Test Vectors==
|
||||
|
||||
@ -58,7 +58,7 @@ encodings and operations.
|
||||
# Signatures are pairs ''(e, s)'' that satisfy ''e = hash(s⋅G - e⋅P || m)''. This variant avoids minor complexity introduced by the encoding of the point ''R'' in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing ''e'' instead of ''R'' allows for potentially shorter signatures: Whereas an encoding of ''R'' inherently needs about 32 bytes, the hash ''e'' can be tuned to be shorter than 32 bytes, and [http://www.neven.org/papers/schnorr.pdf a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits]. However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intend to sign.
|
||||
# Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.<ref>The speedup that results from batch verification can be demonstrated with the cryptography library [https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md libsecp256k1].</ref>
|
||||
|
||||
Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification.
|
||||
Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification.
|
||||
|
||||
'''Key prefixing''' Using the verification rule above directly makes Schnorr signatures vulnerable to "related-key attacks" in which a third party can convert a signature ''(R, s)'' for public key ''P'' into a signature ''(R, s + a⋅hash(R || m))'' for public key ''P + a⋅G'' and the same message ''m'', for any given additive tweak ''a'' to the signing key. This would render signatures insecure when keys are generated using [[bip-0032.mediawiki#public-parent-key--public-child-key|BIP32's unhardened derivation]] and other methods that rely on additive tweaks to existing keys such as Taproot.
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ This document specifies a BIP8 (LOT=true) deployment to activate taproot.
|
||||
|
||||
==Motivation==
|
||||
|
||||
The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus.
|
||||
The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus.
|
||||
|
||||
==Specification==
|
||||
|
||||
|
||||
@ -52,23 +52,23 @@ A common configuration for an individual custodying Bitcoin is "single
|
||||
signature and passphrase" using a hardware wallet. A user with such a
|
||||
configuration might be concerned about the risk associated with relying on a
|
||||
single manufacturer for key management, as well as physical access to the
|
||||
hardware.
|
||||
hardware.
|
||||
|
||||
This individual can use <code>OP_VAULT</code> to make use of a highly secure
|
||||
key as the unlikely recovery path, while using their existing signing procedure
|
||||
as the withdrawal trigger key with a configured spend delay of e.g. 1 day.
|
||||
as the withdrawal trigger key with a configured spend delay of e.g. 1 day.
|
||||
|
||||
The recovery path key can be of a highly secure nature that might otherwise
|
||||
make it impractical for daily use. For example, the key could be generated in
|
||||
some analog fashion, or on an old computer that is then destroyed, with the
|
||||
private key replicated only in paper form. Or the key could be a 2-of-3
|
||||
multisig using devices from different manufacturers. Perhaps the key is
|
||||
geographically or socially distributed.
|
||||
geographically or socially distributed.
|
||||
|
||||
Since it can be any Bitcoin script policy, the recovery key can include a
|
||||
number of spending conditions, e.g. a time-delayed fallback to an "easier"
|
||||
recovery method, in case the highly secure key winds up being ''too'' highly
|
||||
secure.
|
||||
secure.
|
||||
|
||||
The user can run software on their mobile device that monitors the blockchain
|
||||
for spends of the vault outpoints. If the vaulted coins move in an unexpected
|
||||
@ -80,7 +80,7 @@ Institutional custodians of Bitcoin may use vaults in similar fashion.
|
||||
|
||||
===== Provable timelocks =====
|
||||
|
||||
This proposal provides a mitigation to the
|
||||
This proposal provides a mitigation to the
|
||||
[https://web.archive.org/web/20230210123933/https://xkcd.com/538/ "$5 wrench attack."] By
|
||||
setting the spend delay to, say, a week, and using as the recovery path a
|
||||
script that enforces a longer relative timelock, the owner of the vault can
|
||||
@ -95,7 +95,7 @@ timelocked coins for perpetuity or relying on a trusted third party.
|
||||
Vaults in Bitcoin have been discussed formally since 2016
|
||||
([http://fc16.ifca.ai/bitcoin/papers/MES16.pdf MES16]) and informally since [https://web.archive.org/web/20160220215151/https://bitcointalk.org/index.php?topic=511881.0 2014]. The value of
|
||||
having a configurable delay period with recovery capability in light of an
|
||||
unexpected spend has been widely recognized.
|
||||
unexpected spend has been widely recognized.
|
||||
|
||||
The only way to implement vaults given the existing consensus rules, aside from
|
||||
[https://github.com/revault emulating vaults with large multisig
|
||||
@ -114,7 +114,7 @@ Unfortunately, this approach has a number of practical shortcomings:
|
||||
|
||||
The deployment of a "precomputed" covenant mechanism like
|
||||
[https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki OP_CHECKTEMPLATEVERIFY] or
|
||||
[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT]
|
||||
[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT]
|
||||
would both remove the necessity to use an ephemeral key, since the
|
||||
covenant is enforced on-chain, and lessen the burden of sensitive data storage,
|
||||
since the necessary transactions can be generated from a set of compact
|
||||
@ -141,7 +141,7 @@ operational overhead using a specialized covenant.
|
||||
|
||||
The design goals of the proposal are:
|
||||
|
||||
* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits.
|
||||
* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits.
|
||||
|
||||
* '''batched operations''' for recovery and withdrawal to allow managing multiple vault coins efficiently.
|
||||
|
||||
@ -163,7 +163,7 @@ In typical usage, a vault is created by encumbering coins under a
|
||||
taptree [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki (BIP-341)]
|
||||
containing at least two leaves: one with an <code>OP_VAULT</code>-containing script that
|
||||
facilitates the expected withdrawal process, and another leaf with
|
||||
<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered
|
||||
<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered
|
||||
at any time prior to withdrawal finalization.
|
||||
|
||||
The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible
|
||||
@ -172,7 +172,7 @@ withdrawal by allowing a spending transaction to replace the
|
||||
some parameters to be set at spend (trigger) time. All other leaves in the
|
||||
taptree must be unchanged in the destination output, which preserves the recovery path as well as any
|
||||
other spending conditions originally included in the vault. This is similar to
|
||||
the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed
|
||||
the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed
|
||||
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021].
|
||||
|
||||
These tapleaf replacement rules, described more precisely below, ensure a
|
||||
@ -205,14 +205,14 @@ The vault has a number of stages, some of them optional:
|
||||
=== Fee management ===
|
||||
|
||||
A primary consideration of this proposal is how fee management is handled.
|
||||
Providing dynamic fee management is critical to the operation of a vault, since
|
||||
Providing dynamic fee management is critical to the operation of a vault, since
|
||||
|
||||
* precalculated fees are prone to making transactions unconfirmable in high fee environments, and
|
||||
* a fee wallet that is prespecified might be compromised or lost before use.
|
||||
|
||||
But dynamic fee management can introduce
|
||||
[https://bitcoinops.org/en/topics/transaction-pinning/ pinning vectors]. Care
|
||||
has been taken to avoid unnecessarily introducing these vectors when using the new
|
||||
has been taken to avoid unnecessarily introducing these vectors when using the new
|
||||
destination-based spending policies that this proposal introduces.
|
||||
|
||||
Originally, this proposal had a hard dependency on reformed transaction
|
||||
@ -237,7 +237,7 @@ When evaluating <code>OP_VAULT</code> (<code>OP_SUCCESS187</code>,
|
||||
<leaf-update-script-body>
|
||||
<push-count>
|
||||
[ <push-count> leaf-update script data items ... ]
|
||||
<trigger-vout-idx>
|
||||
<trigger-vout-idx>
|
||||
<revault-vout-idx>
|
||||
<revault-amount>
|
||||
</source>
|
||||
@ -413,10 +413,10 @@ that contains a taptree of the form
|
||||
<source>
|
||||
tr(<internal-pubkey>,
|
||||
leaves = {
|
||||
recover:
|
||||
recover:
|
||||
<recovery-sPK-hash> OP_VAULT_RECOVER,
|
||||
|
||||
trigger:
|
||||
trigger:
|
||||
<trigger-auth-pubkey> OP_CHECKSIGVERIFY (i)
|
||||
<spend-delay> 2 $leaf-update-script-body OP_VAULT, (ii)
|
||||
|
||||
@ -434,7 +434,7 @@ Typically, the internal key for the vault taproot output will be specified so
|
||||
that it is controlled by the same descriptor as the recovery path, which
|
||||
facilitates another (though probably unused) means of recovering the vault
|
||||
output to the recovery path. This has the potential advantage of recovering the
|
||||
coin without ever revealing it was a vault.
|
||||
coin without ever revealing it was a vault.
|
||||
|
||||
Otherwise, the internal key can be chosen to be an unspendable NUMS point to
|
||||
force execution of the taptree contents.
|
||||
@ -442,7 +442,7 @@ force execution of the taptree contents.
|
||||
=== Triggering a withdrawal ===
|
||||
|
||||
To make use of the vault, and spend it towards some output, we construct a spend
|
||||
of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the
|
||||
of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the
|
||||
full leaf-update script (in this case, a timelocked CTV script):
|
||||
|
||||
<source>
|
||||
@ -461,17 +461,17 @@ Output scripts:
|
||||
[
|
||||
tr(<internal-pubkey>,
|
||||
leaves = {
|
||||
recover:
|
||||
recover:
|
||||
<recovery-sPK-hash> OP_VAULT_RECOVER, <-- unchanged
|
||||
|
||||
trigger:
|
||||
<target-CTV-hash> <spend-delay>
|
||||
OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the
|
||||
<target-CTV-hash> <spend-delay>
|
||||
OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the
|
||||
leaf-update
|
||||
rules of OP_VAULT
|
||||
... [ possibly other leaves ]
|
||||
}
|
||||
),
|
||||
),
|
||||
|
||||
[ optional revault output with the
|
||||
same sPK as the original vault output ],
|
||||
@ -499,7 +499,7 @@ entails trade-offs.
|
||||
|
||||
==== Unauthorized recovery ====
|
||||
|
||||
Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>.
|
||||
Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>.
|
||||
|
||||
But because this reveal is the only authorization necessary to spend the vault coins to recovery, the user must expect to recover all such vaults at once, since an observer can replay this recovery (provided they know the outpoints).
|
||||
|
||||
@ -513,7 +513,7 @@ These limitations are to avoid pinning attacks.
|
||||
|
||||
==== Authorized recovery ====
|
||||
|
||||
With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required.
|
||||
With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required.
|
||||
|
||||
If this key is lost, the user will be unable to initiate the recovery process for their coins. If an attacker obtains the recovery key, they may grief the user during the recovery process by constructing a low fee rate recovery transaction and broadcasting it (though they will not be able to pin because of the replaceability requirement on recovery transactions).
|
||||
|
||||
@ -521,7 +521,7 @@ However, authorized recovery configurations have significant benefits. Batched r
|
||||
|
||||
==== Recommendation: use a simple, offline recovery authorization key seed ====
|
||||
|
||||
The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated.
|
||||
The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated.
|
||||
|
||||
Note that the recovery authorization key '''is not''' the recovery path key, and
|
||||
this is '''much different''' than any recommendation on how to generate the
|
||||
@ -542,7 +542,7 @@ the trigger authorization pubkeys.
|
||||
Note that when using unauthorized recovery, the reveal of the
|
||||
recovery scriptPubKey will allow any observer to initiate the recovery process
|
||||
for any vault with matching recovery params, provided they are able to locate
|
||||
the vault outpoints. As a result, it is recommended to expect that
|
||||
the vault outpoints. As a result, it is recommended to expect that
|
||||
'''all outputs sharing an identical unauthorized <code><recovery-sPK-hash></code> should be recovered together'''.
|
||||
|
||||
This situation can be avoided with a comparable key management model by varying
|
||||
@ -589,7 +589,7 @@ are essentially dependent on v3 transaction relay policy being deployed.
|
||||
|
||||
<code>OP_VAULT</code> outputs with the same taptree, aside from slightly
|
||||
different trigger leaves, can be batched together in the same withdrawal
|
||||
process. Two "trigger" leaves are compatible if they have the same
|
||||
process. Two "trigger" leaves are compatible if they have the same
|
||||
<code>OP_VAULT</code> arguments.
|
||||
|
||||
Note that this allows the trigger authorization -- the script prefixing the
|
||||
@ -617,7 +617,7 @@ can be recovered into the same output.
|
||||
|
||||
Recovery-incompatible vaults which have authorized recovery can be recovered in
|
||||
the same transaction, so long as each set (grouped by
|
||||
<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows
|
||||
<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows
|
||||
unrelated recoveries to share common fee management.
|
||||
|
||||
=== Watchtowers ===
|
||||
|
||||
@ -44,7 +44,7 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
|
||||
* Vaults <ref>M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf</ref> which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in <ref>A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html</ref> OP_CAT is sufficient to build vaults in Bitcoin.
|
||||
* Replicating CheckSigFromStack <ref>A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298</ref> which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures <ref>R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md</ref>.
|
||||
|
||||
OP_CAT was available in early versions of Bitcoin.
|
||||
OP_CAT was available in early versions of Bitcoin.
|
||||
In 2010, a single commit disabled OP_CAT, along with another 15 opcodes.
|
||||
Folklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
|
||||
For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes.
|
||||
@ -109,5 +109,5 @@ An alternative implementation of OP_CAT can be found in Elements <ref>Roose S.,
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill,
|
||||
We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill,
|
||||
Tim Ruffing and Johan T. Halseth for their feedback, review and helpful comments.
|
||||
|
||||
@ -212,7 +212,7 @@ The following tests cover the checksum and character set:
|
||||
* Error in checksum: <tt>raw(deedbeef)##9f8spxm</tt>
|
||||
* Invalid characters in payload: <tt>raw(Ü)#00000000</tt>
|
||||
|
||||
The following tests cover key expressions:
|
||||
The following tests cover key expressions:
|
||||
|
||||
Valid expressions:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user