diff options
| -rw-r--r-- | bip-0002.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0075.mediawiki | 19 | ||||
| -rw-r--r-- | bip-0075/paymentrequest.proto | 4 |
3 files changed, 18 insertions, 13 deletions
diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index 43a5ce6..4796771 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -74,6 +74,7 @@ For each new BIP that comes in an editor does the following: * The title should accurately describe the content. * The BIP draft must have been sent to the Bitcoin development mailing list for discussion. * Motivation and backward compatibility (when applicable) must be addressed. +* The defined Layer header must be correctly assigned for the given specification. * Licensing terms must be acceptable for BIPs. If the BIP isn't ready, the editor will send it back to the author for revision, with specific instructions. @@ -120,6 +121,7 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe <pre> BIP: <BIP number, or "?" before being assigned> +* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications> Title: <BIP title; maximum 44 characters> Author: <list of authors' real names and email addrs> * Discussions-To: <email address> @@ -137,6 +139,9 @@ Each BIP must begin with an RFC 822 style header preamble. The headers must appe * Superseded-By: <BIP number> </pre> +The Layer header (only for Standards Track BIPs) documents which layer of Bitcoin the BIP applies to. +See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123. + The Author header lists the names and email addresses of all the authors/owners of the BIP. The format of the Author header value must be @@ -191,8 +196,6 @@ A process BIP may change status from Draft to Active when it achieves rough cons ====Progression to Final status==== -See [[bip-0123.mediawiki|BIP 123]] for definitions of the various BIP layers. Activation of this BIP implies activation of BIP 123. - A soft-fork BIP strictly requires a clear miner majority expressed by blockchain voting (eg, using BIP 9). In addition, if the economy seems willing to make a "no confidence" hard-fork (such as a change in proof-of-work algorithm), the soft-fork does not become Final for as long as such a hard-fork might have majority support, or at most three months. Soft-fork BIPs may also set additional requirements for their adoption. Because of the possibility of changes to miner dynamics, especially in light of delegated voting (mining pools), it is highly recommended that a supermajority vote around 95% be required by the BIP itself, unless rationale is given for a lower threshold. A hard-fork BIP requires adoption from the entire Bitcoin economy, particularly including those selling desirable goods and services in exchange for bitcoin payments, as well as Bitcoin holders who wish to spend or would spend their bitcoins (including selling for other currencies) differently in the event of such a hard-fork. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support, although that is a good step to establish agreement before adoption of the BIP). This economic adoption cannot be established merely by a super-majority, except by literally forcing the minority to accept the hard-fork (whether this is viable or not is outside the scope of this document). @@ -395,6 +398,7 @@ Why is Public Domain no longer acceptable for new BIPs? * An implementation is now required (when applicable) before BIPs can proceed to Proposed Status. * BIP Comments are newly introduced. * The License preamble headers have been added. +* The Layer header is included from BIP 123. * Non-image auxiliary files are permitted in the bip-XXXX subdirectory. * Email addresses are now required for authors. * The Post-History header may be provided as a link instead of a simple date. diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index 11fa43b..878d708 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -105,7 +105,7 @@ message InvoiceRequest { {| class="wikitable" ! Field Name !! Description |- -| sender_public_key || Sender's EC public key +| sender_public_key || Sender's SEC-encoded EC public key |- | amount || amount is integer-number-of-satoshis (default: 0) |- @@ -141,7 +141,7 @@ message ProtocolMessage { required ProtocolMessageType message_type = 3; required bytes serialized_message = 4; optional string status_message = 5; - optional bytes identifier = 6; + required bytes identifier = 6; } </pre> @@ -158,7 +158,7 @@ message ProtocolMessage { |- |status_message || Human-readable Payment Protocol status message |- -|identifier || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default +|identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) |} ===Versioning=== @@ -177,7 +177,7 @@ message EncryptedProtocolMessage { required bytes receiver_public_key = 5; required bytes sender_public_key = 6; required uint64 nonce = 7; - optional bytes identifier = 8; + required bytes identifier = 8; optional string status_message = 9; optional bytes signature = 10; } @@ -193,13 +193,13 @@ message EncryptedProtocolMessage { |- | encrypted_message || AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message |- -| receiver_public_key || Receiver's DER-encoded EC Public Key +| receiver_public_key || Receiver's SEC-encoded EC Public Key |- -| sender_public_key || Sender's DER-encoded EC Public Key +| sender_public_key || Sender's SEC-encoded EC Public Key |- | nonce || Microseconds since epoch |- -| identifier || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default +| identifier || Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) |- | status_message || Human-readable Payment Protocol status message |- @@ -362,7 +362,7 @@ When either '''status_code''' OR '''status_message''' are present, the AES-256 G 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: # Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] # Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] -# QR Code - Use of QR-code to encode DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] +# QR Code - Use of QR-code to encode SEC-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480] # Address Service Public Key Exposure ==Payment / PaymentACK Messages with a HTTP Store & Forward Server== @@ -376,7 +376,8 @@ If a Store & Forward server wishes to protect themselves from spam or abuse, the Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a Payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice. ==Public Key & Signature Encoding== -* All EC public keys ('''sender_public_key''', '''receiver_public_key''') or x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. +* All x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. +* All EC public keys ('''sender_public_key''', '''receiver_public_key''') in any message defined in this BIP MUST be [[SECP256k1|http://www.secg.org/sec2-v2.pdf]] ECDSA Public Key ECPoints encoded using [[SEC 2.3.3 Encoding|http://www.secg.org/sec1-v2.pdf]]. Encoding MAY be compressed. * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded. * All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1. diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto index 5a08192..5097abb 100644 --- a/bip-0075/paymentrequest.proto +++ b/bip-0075/paymentrequest.proto @@ -70,7 +70,7 @@ message ProtocolMessage { required ProtocolMessageType message_type = 3; // Message Type of serialized_message required bytes serialized_message = 4; // Serialized Payment Protocol Message optional string status_message = 5; // Human-readable Payment Protocol status message - optional bytes identifier = 6; // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default + required bytes identifier = 6; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) } message EncryptedProtocolMessage { @@ -81,7 +81,7 @@ message EncryptedProtocolMessage { required bytes receiver_public_key = 5; // Receiver's DER-encoded EC Public Key required bytes sender_public_key = 6; // Sender's DER-encoded EC Public Key required uint64 nonce = 7; // Microseconds since epoch - optional bytes identifier = 8; // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default + required bytes identifier = 8; // Unique key to identify this entire exchange on the server. Default value SHOULD be SHA256(Serialized Initial InvoiceRequest + Current Epoch Time in Seconds as a String) optional string status_message = 9; // Human-readable Payment Protocol status message optional bytes signature = 10; // Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively }
\ No newline at end of file |