diff options
| -rw-r--r-- | README.mediawiki | 14 | ||||
| -rw-r--r-- | bip-0032.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0037.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 50 | ||||
| -rw-r--r-- | bip-0044.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0062.mediawiki | 66 | ||||
| -rw-r--r-- | bip-0070.mediawiki | 2 |
7 files changed, 81 insertions, 57 deletions
diff --git a/README.mediawiki b/README.mediawiki index d5e3fb1..2d2a0c0 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -53,13 +53,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Aliases | Amir Taaki | Standard -| Withdrawn +| Deferred |- style="background-color: #cfffcf" | [[bip-0016.mediawiki|16]] | Pay To Script Hash | Gavin Andresen | Standard -| Accepted +| Final |- style="background-color: #ffcfcf" | [[bip-0017.mediawiki|17]] | OP_CHECKHASHVERIFY (CHV) @@ -107,7 +107,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Duplicate transactions | Pieter Wuille | Standard -| Accepted +| Final |- style="background-color: #cfffcf" | [[bip-0031.mediawiki|31]] | Pong message @@ -210,7 +210,7 @@ Those proposing changes should consider that ultimately consent may rest with th | "reject" P2P message | Gavin Andresen | Standard -| Draft +| Final |- | [[bip-0062.mediawiki|62]] | Dealing with malleability @@ -234,19 +234,19 @@ Those proposing changes should consider that ultimately consent may rest with th | Payment protocol | Gavin Andresen | Standard -| Draft +| Final |- | [[bip-0071.mediawiki|71]] | Payment protocol MIME types | Gavin Andresen | Standard -| Draft +| Final |- | [[bip-0072.mediawiki|72]] | Payment protocol URIs | Gavin Andresen | Standard -| Draft +| Final |- | [[bip-0073.mediawiki|73]] | Use "Accept" header with Payment Request URLs diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 3ef2d9e..db13b06 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -275,6 +275,8 @@ A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey) +A Haskell implementation is available at https://github.com/haskoin/haskoin + ==Acknowledgements== * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it. diff --git a/bip-0037.mediawiki b/bip-0037.mediawiki index 8179393..f1561be 100644 --- a/bip-0037.mediawiki +++ b/bip-0037.mediawiki @@ -195,7 +195,7 @@ When loading a filter with the <code>filterload</code> command, there are two pa Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable. -The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%). +The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%). The number of hash functions required is given by <code>S * 8 / N * log(2)</code>. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index eb60fff..6460921 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -26,25 +26,25 @@ A mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexidecimal representations of a wallet seed. The sentence could be written on paper or spoken over the telephone. -This guide meant to be as a way to transport computer-generated randomness over -human readable transcription. It's not a way how to process user-created -sentences (also known as brainwallet) to wallet seed. +This guide is meant to be a way to transport computer-generated randomness with +a human readable transcription. It's not a way to process user-created +sentences (also known as brainwallets) into a wallet seed. ==Generating the mnemonic== -The mnemonic must encode entropy in any multiple of 32 bits. With larger entropy -security is improved but the sentence length increases. We can refer to the +The mnemonic must encode entropy in a multiple of 32 bits. With more entropy +security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The recommended size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first <pre>ENT / 32</pre> bits of its SHA256 hash. This checksum is -appended to the end of the initial entropy. Next, these concatenated bits are +appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving -as an index to a wordlist. Later, we will convert these numbers into words and +as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence. The following table describes the relation between the initial entropy -length (ENT), the checksum length (CS) and length of the generated mnemonic +length (ENT), the checksum length (CS) and the length of the generated mnemonic sentence (MS) in words. <pre> @@ -65,7 +65,7 @@ MS = (ENT + CS) / 11 An ideal wordlist has the following characteristics: a) smart selection of words - - wordlist is created in such way that it's enough to type the first four + - the wordlist is created in such way that it's enough to type the first four letters to unambiguously identify the word b) similar words avoided @@ -74,39 +74,39 @@ b) similar words avoided prone and more difficult to guess c) sorted wordlists - - wordlist is sorted which allows for more efficient lookup of the code words - (i.e. implementation can use binary search instead of linear search) - - this also allows trie (prefix tree) to be used, e.g. for better compression + - the wordlist is sorted which allows for more efficient lookup of the code words + (i.e. implementations can use binary search instead of linear search) + - this also allows trie (a prefix tree) to be used, e.g. for better compression -The wordlist can contain native characters, but they have to be encoded in UTF-8 +The wordlist can contain native characters, but they must be encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD). ==From mnemonic to seed== -A user may decide to protect their mnemonic by passphrase. If a passphrase is not +A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead. -To create a binary seed from the mnemonic, we use PBKDF2 function with a mnemonic -sentence (in UTF-8 NFKD) used as a password and string "mnemonic" + passphrase (again -in UTF-8 NFKD) used as a salt. Iteration count is set to 2048 and HMAC-SHA512 is used as -a pseudo-random function. Desired length of the derived key is 512 bits (= 64 bytes). +To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic +sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again +in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as +the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes). This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods. -The conversion of the mnemonic sentence to binary seed is completely independent +The conversion of the mnemonic sentence to a binary seed is completely independent from generating the sentence. This results in rather simple code; there are no constraints on sentence structure and clients are free to implement their own wordlists or even whole sentence generators, allowing for flexibility in wordlists for typo detection or other purposes. -Although using mnemonic not generated by algorithm described in "Generating the -mnemonic" section is possible, this is not advised and software must compute -checksum of the mnemonic sentence using wordlist and issue a warning if it is +Although using a mnemonic not generated by the algorithm described in "Generating the +mnemonic" section is possible, this is not advised and software must compute a +checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid. -Described method also provides plausible deniability, because every passphrase -generates a valid seed (and thus deterministic wallet) but only the correct one +The described method also provides plausible deniability, because every passphrase +generates a valid seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available. ==Wordlists== @@ -127,3 +127,5 @@ http://github.com/trezor/python-mnemonic Objective-C - https://github.com/nybex/NYMnemonic +Haskell - https://github.com/haskoin/haskoin + diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index e9d6e38..540c3a4 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -147,7 +147,7 @@ All these constants are used as hardened derivation. |} This BIP is not a central directory for the registered coin types, please -visit Satoshi Labs that maintains the full list: +visit SatoshiLabs that maintains the full list: [[http://doc.satoshilabs.com/slips/slip-0044.html|SLIP-0044 : Registered coin types for BIP-0044]] diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 3f11050..9d5bfe5 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -22,29 +22,38 @@ This is a problem for multiple reasons: Several sources of malleability are known: -# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it. # '''Non-DER encoded ECDSA signatures''' Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already. -# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability. # '''Non-push operations in scriptSig''' Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity. # '''Push operations in scriptSig of non-standard size type''' The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities. # '''Zero-padded number pushes''' In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded. +# '''Inherent ECDSA signature malleability''' ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it. +# '''Superfluous scriptSig operations''' Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability. # '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored. # '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing. # '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs. -The first six and part of the seventh can be fixed by extra consensus rules. The last three can't, but are always under control of the (original) sender. +The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself). ==Specification== ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). To convert another signature, simply take the complement of the S value (modulo the curve order). -# '''Non-DER encoded ECDSA signatures''' All ECDSA signatures must be encoded using strict DER encoding. -# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the result is invalid. -# '''Non-push operations in scriptSig''' Any non-push operation in a scriptSig invalidates it. -# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation (including OP_0 for an empty byte vector, or the direct pushes of a single byte) must be used when possible. Using any push operation that could be encoded in a shorter way invalidates it. -# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. -# '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script invalid. +# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. +# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. +# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. +# '''Inherent ECDSA signature malleability''' We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]]. +# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. +# '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false. + +===Block validity=== + +To introduce these new rules in the network, we add both v3 blocks and v3 transactions. v2 is skipped for transactions to keep the version numbers between transaction and block rules in sync. v2 transactions are treated identically to v1 transactions. +The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated: +* All transactions in v3 blocks are required to follow rules #1-#2. +* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well. + +When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 (and v2) transactions remain valid forever. ===References=== @@ -70,22 +79,33 @@ This is already enforced by the reference client as of version 0.8.0 (only as re This rule, combined with the low S requirement above, results in S-length being at most 32 (and R-length at most 33), and the total signature size being at most 72 bytes (and on average 71.494 bytes). -====Shortest possible data pushes==== -For reference: -* Pushing an empty byte sequence (or the number 0) must use OP_0. -* Pushing a single byte sequence of byte 0x01 through 0x10 (or the numbers 1 through 16) must use OP_n. -* Pushing the byte 0x81 (or the number -1) must use OP_1NEGATE. +====Push operators==== + +* Pushing an empty byte sequence must use OP_0. +* Pushing a 1-byte sequence of byte 0x01 through 0x10 must use OP_n. +* Pushing the byte 0x81 must use OP_1NEGATE. * Pushing any other byte sequence up to 75 bytes must use the normal data push (opcode byte n, with n the number of bytes, followed n bytes of data being pushed). -* Only pushes of more than 75 bytes can use OP_PUSHDATA1. -* Only pushes of more than 255 bytes can use OP_PUSHDATA2. -* OP_PUSHDATA4 can never be used, as pushes over 520 bytes are not allowed, and those below can be done using OP_PUSHDATA2. +* Pushing 76 to 255 bytes must use OP_PUSHDATA1. +* Pushing 256 to 520 bytes must use OP_PUSHDATA2. +* OP_PUSHDATA4 can never be used, as pushes over 520 bytes are not allowed, and those below can be done using other operators. +* Any other operation is not considered to be a push. -==Compatibility== +====Numbers==== -'''Version 3 blocks and transactions''' To introduce these new rules in the network, we add both nVersion=3 blocks and nVersion=3 transactions (nVersion=2 transactions are skipped in order to keep the version numbers synchronized). +The native data type of stack elements is byte arrays, but some operations interpret arguments as integers. The used encoding is little endian with an explicit sign bit (the highest bit of the last byte). The shortest encodings for numbers are (with the range boundaries encodings given in hex between ()). +* 0: OP_0; (00) +* 1..16: OP_1..OP_16; (51)..(60) +* -1: OP_1NEGATE; (79) +* -127..-2 and 17..127: normal 1-byte data push; (01 FF)..(01 82) and (01 11)..(01 7F) +* -32767..-128 and 128..32767: normal 2-byte data push; (02 FF FF)..(02 80 80) and (02 80 00)..(02 FF 7F) +* -8388607..-32768 and 32768..8388607: normal 3-byte data push; (03 FF FF FF)..(03 00 80 80) and (03 00 80 00)..(03 FF FF 7F) +* -2147483647..-8388608 and 8388608..2147483647: normal 4-byte data push; (04 FF FF FF FF)..(04 00 00 80 80) and (04 00 00 80 00)..(04 FF FF FF 7F) +* Any other numbers cannot be encoded. -'''Relay of transactions''' A new node software version is released which makes nVersion=3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of nVersion=1 transactions is unaffected. An nVersion=1 transaction spending an output created by an nVersion=3 transaction is also unaffected. +In particular, note that zero could be encoded as (01 80) (negative zero) if using the non-shortest form is allowed. + +==Compatibility== -'''Block validity''' In addition, the same mechanism as in BIP 0034 is reused to introduce nVersion=3 blocks. When 75% of the past 1000 blocks are nVersion=3, a new consensus rule is activated which requires nVersion>=3 transactions in nVersion>=3 blocks (and only that combination) to follow the above rules. An nVersion>=3 block with an nVersion>=3 transaction whose scriptSig does not follow the new rules, becomes invalid. When 95% of the past blocks are nVersion>=3, nVersion=2 blocks become invalid entirely. Note however that nVersion=1 transactions remain valid forever. +'''Relay of transactions''' A new node software version is released which makes v3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v3 transaction is also unaffected. -'''Wallet updates''' As nVersion=3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but setting nVersion=3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software. +'''Wallet updates''' As v3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software. diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 03baf5b..c2f7725 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -126,7 +126,7 @@ A PaymentRequest is PaymentDetails optionally tied to a merchant's identity: |- | signature || digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, with all serialized fields serialized in numerical order (all current protocol buffer implementations serialize -fields in numerical order) and signed using the public key in pki_data. Optional fields that are not set +fields in numerical order) and signed using the private key that corresponds to the public key in pki_data. Optional fields that are not set are not serialized (however, setting a field to its default value will cause it to be serialized and will affect the signature). Before serialization, the signature field must be set to an empty value so that the field is included in the signed PaymentRequest hash but contains no data. |} |