diff options
| -rw-r--r-- | README.mediawiki | 5 | ||||
| -rw-r--r-- | bip-0032.mediawiki | 239 | ||||
| -rw-r--r-- | bip-0062.mediawiki | 91 | ||||
| -rw-r--r-- | bip-0070.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0070/paymentrequest.proto | 46 |
5 files changed, 276 insertions, 107 deletions
diff --git a/README.mediawiki b/README.mediawiki index f8c32c6..6cc42b5 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -201,6 +201,11 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0062.mediawiki|62]] +| Dealing with malleability +| Pieter Wuille +| Draft +|- | [[bip-0070.mediawiki|70]] | Payment protocol | Gavin Andresen diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 619feea..2f59711 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -1,7 +1,8 @@ RECENT CHANGES: -* (16 Apr 2013) Added private derivation for i >= 0x80000000 (less risk of parent private key leakage) -* (30 Apr 2013) Switched from multiplication by I_L to addition of I_L (faster, easier implementation) +* (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) +* (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation) * (25 May 2013) Added test vectors +* (15 Jan 2014) Rename keys with index ≥ 0x8000000 to hardened keys, and add explicit covnersion functions. <pre> BIP: 32 @@ -33,80 +34,98 @@ However, deterministic wallets typically consist of a single "chain" of keypairs ===Conventions=== In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either: -* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first. -* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate. -* byte sequences +* Integers modulo the order of the curve (referred to as n). +* Coordinates of points on the curve. +* Byte sequences. -We shall denote the compressed form of point P by χ(P), which for secp256k1 will always be 33 bytes long. +Addition (+) of two coordinate pair is defined as application of the EC group operation. +Concatenation (||) is the operation of appending one byte sequence onto another. + +As standard conversion functions, we assume: +* point(p): returns the coordinate pair resulting from EC point multiplication (repeated application of the EC group operation) of the secp256k1 base point with the integer p. +* ser<sub>32</sub>(i): serialize a 32-bit unsigned integer i as a 4-byte sequence, most significant byte first. +* ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first. +* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted y coordinate. +* parse<sub>256</sub>(p): interprets a 32-byte sequence as a 256-bit number, most significant byte first. -Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences. ===Extended keys=== In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes. -We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = k*G and c the chain code. +We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code. -===Child key derivation functions=== +Each extended key has 2<sup>31</sup> normal child keys, and 2<sup>31</sup> hardened child keys. Each of these child keys has an index. The normal child keys use indices 0 through 2<sup>31</sup>-1. The hardened child keys use indices 2<sup>31</sup> through 2<sup>32</sup>-1. To ease notation for hardened key indices, a number i<sub>H</sub> represents i+2<sup>31</sup>. -We allow for two different types of derivation: private and public. -* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>. -* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>). +===Child key derivation (CKD) functions=== -We define the private and public child key derivation functions: -* CKD((k<sub>par</sub>, c<sub>par</sub>), i) → (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation. -* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) → (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation. +Given a parent extended key and an index i, it is possible to compute the corresponding child extended key. The algorithm to do so depends on whether the child is a hardened key or not (or, equivalently, whether i ≥ 2<sup>31</sup>), and whether we're talking about private or public keys. -We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation. +====Private parent key → private child key==== -====Private child key derivation==== +The function CKDpriv((k<sub>par</sub>, c<sub>par</sub>), i) → (k<sub>i</sub>, c<sub>i</sub>) computes a child extended private key from the parent extended private key: +* Check whether i ≥ 2<sup>31</sup> (whether the child is a hardened key). +** If so (hardened child): let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || ser<sub>256</sub>(k<sub>par</sub>) || ser<sub>32</sub>(i)). (Note: The 0x00 pads the private key to make it 33 bytes long.) +** If not (normal child): let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = ser<sub>P</sub>(point(k<sub>par</sub>)) || ser<sub>32</sub>(i)). +* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>. +* The returned child key k<sub>i</sub> is parse<sub>256</sub>(I<sub>L</sub>) + k<sub>par</sub> (mod n). +* The returned chain code c<sub>i</sub> is I<sub>R</sub>. +* In case parse<sub>256</sub>(I<sub>L</sub>) ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2<sup>127</sup>.) -To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) → (k<sub>i</sub>, c<sub>i</sub>): -* Check whether the highest bit (0x80000000) of i is set: -** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.] -** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = χ(k<sub>par</sub>*G) || i) -* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>. -* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n). -* c<sub>i</sub> = I<sub>R</sub>. -In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i. -[Note: this has probability lower than 1 in 2<sup>127</sup>.] +The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231]. -====Public child key derivation==== +====Public parent key → public child key==== -To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) → (K<sub>i</sub>, c<sub>i</sub>): -* Check whether the highest bit (0x80000000) of i is set: -** If 1, return error -** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = χ(K<sub>par</sub>) || i) -* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>. -* K<sub>i</sub> = (I<sub>L</sub> + k<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub> -* c<sub>i</sub> = I<sub>R</sub>. -In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i. +The function CKDpub((K<sub>par</sub>, c<sub>par</sub>), i) → (K<sub>i</sub>, c<sub>i</sub>) computes a child extended public key from the parent extended public key. It is only defined for non-hardened child keys. +* Check whether i ≥ 2<sup>31</sup> (whether the child is a hardened key). +** If so (hardened child): return failure +** If not (normal child): let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = ser<sub>P</sub>(K<sub>par</sub>) || ser<sub>32</sub>(i)). +* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>. +* The returned child key K<sub>i</sub> is point(parse<sub>256</sub>(I<sub>L</sub>)) + K<sub>par</sub>. +* The returned chain code c<sub>i</sub> is I<sub>R</sub>. +* In case parse<sub>256</sub>(I<sub>L</sub>) ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i. -Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however. +====Private parent key → public child key==== -The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231]. +The function N((k, c)) → (K, c) computes the extended public key corresponding to an extended private key (the "neutered" version, as it removes the ability to sign transactions). +* The returned key K is point(k). +* The returned chain code c is just the passed chain code. + +To compute the public child key of a parent private key: +* N(CKDpriv((k<sub>par</sub>, c<sub>par</sub>), i)) (works always). +* CKDpub(N(k<sub>par</sub>, c<sub>par</sub>), i) (works only for non-hardened child keys). +The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key), and also what distinguishes them from hardened keys. The reason for not always using non-hardened keys (which are more useful) is security; see further for more information. + +====Public parent key → private child key==== + +This is not possible. ===The key tree=== -The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now. +The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKDpriv(m,i) for several values of i, we get a number of level-1 derived nodes. As each of these is again an extended key, CKDpriv can be applied to those as well. + +To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3<sub>H</sub>),2),5) as m/3<sub>H</sub>/2/5. Equivalently for public keys, we write CKDpub(CKDpub(CKDpub(M,3),2,5) as M/3/2/5. This results in the following identities: +* N(m/a/b/c) = N(m/a/b)/c = N(m/a)/b/c = N(m)/a/b/c = M/a/b/c. +* N(m/a<sub>H</sub>/b/c) = N(m/a<sub>H</sub>/b)/c = N(m/a<sub>H</sub>)/b/c. +However, N(m/a<sub>H</sub>) cannot be rewritten as N(m)/a<sub>H</sub>, as the latter is not possible. -Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant public keys derived using public derivation. +Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys. ===Key identifiers=== Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself). -The first 32 bits of the identifier are called the fingerprint. +The first 32 bits of the identifier are called the key fingerprint. ===Serialization format=== Extended public and private keys are serialized as follows: * 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private) -* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... +* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, .... * 4 bytes: the fingerprint of the parent's key (0x00000000 if master key) -* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key) +* 4 bytes: child number. This is ser<sub>32</sub>(i) for i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. (0x00000000 if master key) * 32 bytes: the chain code -* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys) +* 33 bytes: the public key or private key data (ser<sub>P</sub>(K) for public keys, 0x00 || ser<sub>256</sub>(k) for private keys) This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet. @@ -116,13 +135,13 @@ When importing a serialized extended public key, implementations must verify whe ===Master key generation=== -The total number of possible extended keypairs is almost 2^512, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value. +The total number of possible extended keypairs is almost 2<sup>512</sup>, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value. -* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG. -* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S) +* Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG. +* Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S) * Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>. -* Use I<sub>L</sub> as master secret key, and I<sub>R</sub> as master chain code. -In case I<sub>L</sub> is 0 or >=n, the master key is invalid. +* Use parse<sub>256</sub>(I<sub>L</sub>) as master secret key, and I<sub>R</sub> as master chain code. +In case I<sub>L</sub> is 0 or ≥n, the master key is invalid. <img src=bip-0032/derivation.png></img> @@ -130,12 +149,13 @@ In case I<sub>L</sub> is 0 or >=n, the master key is invalid. The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported. -An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account. +===The default wallet layout=== -Each account is composed of two keypair chains: an internal and an external one. The external [[keychain]] is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything. +An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account. - * m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m. - * m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m. +Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything. +* m/i<sub>H</sub>/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m. +* m/i<sub>H</sub>/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m. ===Use cases=== @@ -143,22 +163,22 @@ Each account is composed of two keypair chains: an internal and an external one. In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain. -====Audits: M==== +====Audits: N(m/*)==== -In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key. +In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public extended keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key. -====Per-office balances: m/i'==== +====Per-office balances: m/i<sub>H</sub>==== When a business has several independent offices, they can all use wallets derived from a single master. This will allow the headquarters to maintain a super-wallet that sees all incoming and outgoing transactions of all offices, and even permit moving money between the offices. -====Recurrent business-to-business transactions: M/i'/0==== +====Recurrent business-to-business transactions: N(m/i<sub>H</sub>/0)==== -In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i'/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment. +In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment. Such a mechanism could also be used by mining pool operators as variable payout address. -====Unsecure money receiver: M/i'/0==== +====Unsecure money receiver: N(m/i<sub>H</sub>/0)==== -When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments, but will not (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones. +When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that are used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments, but will not (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones. ==Compatibility== @@ -170,63 +190,66 @@ In addition to the expectations from the EC public-key cryptography itself: * Given a public key K, an attacker cannot find the corresponding private key more efficiently than by solving the EC discrete logarithm problem (assumed to require 2<sup>128</sup> group operations). the intended security properties of this standard are: * Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. -* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. +* Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. Note however that the following properties does not exist: * Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i. -* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>. +* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>. + +===Implications=== Private and public keys must be kept safe as usual. Leaking a private key means access to coins - leaking a public key can mean loss of privacy. -Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master. +Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. + +One weakness that may not be immediately obvious, is that knowledge of the extended public key + any non-hardened private key descending from it is equivalent to knowing the extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. +It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts. ==Test Vectors== -For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]] - -Test vector 1 - - Master (hex): 000102030405060708090a0b0c0d0e0f - * [Chain m] - * ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8 - * ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi - * [Chain m/0'] - * ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw - * ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7 - * [Chain m/0'/1] - * ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ - * ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs - * [Chain m/0'/1/2'] - * ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5 - * ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM - * [Chain m/0'/1/2'/2] - * ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV - * ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334 - * [Chain m/0'/1/2'/2/1000000000] - * ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy - * ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76 - -Test vector 2 - - Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 - * [Chain m] - * ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB - * ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U - * [Chain m/0] - * ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH - * ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt - * [Chain m/0/2147483647'] - * ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a - * ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9 - * [Chain m/0/2147483647'/1] - * ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon - * ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef - * [Chain m/0/2147483647'/1/2147483646'] - * ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL - * ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc - * [Chain m/0/2147483647'/1/2147483646'/2] - * ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt - * ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j +===Test vector 1=== + +Master (hex): 000102030405060708090a0b0c0d0e0f +* Chain m +** ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8 +** ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi +* Chain m/0<sub>H</sub> +** ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw +** ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7 +* Chain m/0<sub>H</sub>/1 +** ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ +** ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs +* Chain m/0<sub>H</sub>/1/2<sub>H</sub> +** ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5 +** ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM +* Chain m/0<sub>H</sub>/1/2<sub>H</sub>/2 +** ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV +** ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334 +* Chain m/0<sub>H</sub>/1/2<sub>H</sub>/2/1000000000 +** ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy +** ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76 + +===Test vector 2=== + +Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542 +* Chain m +** ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB +** ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U +* Chain m/0 +** ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH +** ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt +* Chain m/0/2147483647<sub>H</sub> +** ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a +** ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9 +* Chain m/0/2147483647<sub>H</sub>/1 +** ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon +** ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef +* Chain m/0/2147483647<sub>H</sub>/1/2147483646<sub>H</sub> +** ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL +** ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc +* Chain m/0/2147483647<sub>H</sub>/1/2147483646<sub>H</sub>/2 +** ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt +** ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j ==Implementations== @@ -246,6 +269,8 @@ A Go implementation is available at https://github.com/WeMeetAgain/go-hdwallet A JavaScript implementation is available at https://github.com/sarchar/brainwallet.github.com/tree/bip32 +A PHP implemetation is available at https://github.com/Bit-Wasp/bitcoin-lib-php + ==Acknowledgements== * Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it. diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki new file mode 100644 index 0000000..dfa4072 --- /dev/null +++ b/bip-0062.mediawiki @@ -0,0 +1,91 @@ +<pre> + BIP: 62 + Title: Dealing with malleability + Author: Pieter Wuille <pieter.wuille@gmail.com> + Status: Draft + Type: Standards Track + Created: 12-03-2014 +</pre> + +==Abstract== + +This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it). + +==Motivation== + +As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys. + +This is a problem for multiple reasons: +* The sender may not recognize his own transaction after being modified. +* The sender may create transactions that spend change created by the original transaction. In case the modified transaction gets mined, this becomes invalid. +* Modified transactions are effectively double-spends which can be created without malicious intent (of the sender), but can be used to make other attacks easier. + +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. +# '''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. + +==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. + +===References=== + +Below is a summary of the effects on signatures, their encoding and data pushes. + +====Low S values in signatures==== + +The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S. + +The constraints on the value R is unchanged w.r.t. ECDSA, and can be between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (inclusive). + +====DER encoding==== +For reference, here is how to encode signatures correctly in DER format. + +0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type] +* total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte. +* R-length: 1-byte length descriptor of the R value that follows. +* R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required. +* S-length: 1-byte length descriptor of the S value that follows. +* S: arbitrary-length big-endian encoded S value. The same rules apply as for R. +* sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed). +This is already enforced by the reference client as of version 0.8.0 (only as relay policy, not as a consensus rule). + +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. +* 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. + +==Compatibility== + +'''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). + +'''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. + +'''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. + +'''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. diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index accd12b..4461118 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -47,6 +47,8 @@ PaymentRequest message: ==Messages== +The Protocol Buffers messages are defined in [[bip-0070/paymentrequest.proto|paymentrequest.proto]]. + ===Output=== Outputs are used in PaymentRequest messages to specify where a payment (or diff --git a/bip-0070/paymentrequest.proto b/bip-0070/paymentrequest.proto new file mode 100644 index 0000000..f83b110 --- /dev/null +++ b/bip-0070/paymentrequest.proto @@ -0,0 +1,46 @@ +// +// Simple Bitcoin Payment Protocol messages +// +// Use fields 100+ for extensions; +// to avoid conflicts, register extensions via pull-req at: +// https://github.com/bitcoin/bips +// + +package payments; +option java_package = "org.bitcoin.protocols.payments"; +option java_outer_classname = "Protos"; + +// Generalized form of "send payment to this/these bitcoin addresses" +message Output { + optional uint64 amount = 1 [default = 0]; // amount is integer-number-of-satoshis + required bytes script = 2; // usually one of the standard Script forms +} +message PaymentDetails { + optional string network = 1 [default = "main"]; // "main" or "test" + repeated Output outputs = 2; // Where payment should be sent + required uint64 time = 3; // Timestamp; when payment request created + optional uint64 expires = 4; // Timestamp; when this request should be considered invalid + optional string memo = 5; // Human-readable description of request for the customer + optional string payment_url = 6; // URL to send Payment and get PaymentACK + optional bytes merchant_data = 7; // Arbitrary data to include in the Payment message +} +message PaymentRequest { + optional uint32 payment_details_version = 1 [default = 1]; + optional string pki_type = 2 [default = "none"]; // none / x509+sha256 / x509+sha1 + optional bytes pki_data = 3; // depends on pki_type + required bytes serialized_payment_details = 4; // PaymentDetails + optional bytes signature = 5; // pki-dependent signature +} +message X509Certificates { + repeated bytes certificate = 1; // DER-encoded X.509 certificate chain +} +message Payment { + optional bytes merchant_data = 1; // From PaymentDetails.merchant_data + repeated bytes transactions = 2; // Signed transactions that satisfy PaymentDetails.outputs + repeated Output refund_to = 3; // Where to send refunds, if a refund is necessary + optional string memo = 4; // Human-readable message for the merchant +} +message PaymentACK { + required Payment payment = 1; // Payment message that triggered this ACK + optional string memo = 2; // human-readable message for customer +} |