diff options
| -rw-r--r-- | bip-0075.mediawiki | 5 | ||||
| -rw-r--r-- | bip-0075/paymentrequest.proto | 17 |
2 files changed, 14 insertions, 8 deletions
diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index cdb2f63..e71058f 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -425,6 +425,10 @@ When a Store & Forward server is in use during the Payment Protocol exchange, an Store & Forward servers MAY accept and/or overwrite EncryptedPayment messages until an EncryptedPaymentACK message with matching identifier and valid Receiver signature is received, after which the server MAY reject all further EncryptedPayment messages matching that identifier. This feature SHOULD be used for updating Payment metadata or replacing invalid transactions with valid ones. 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== +* Each EC public key (sender_public_key, receiver_public_key) included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded. +* Each ECC signature included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded. + ==Implementation== A reference implementation for a Store & Forward server supporting this proposal can be found here: @@ -492,3 +496,4 @@ message PaymentDetails { * [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG] * [https://tools.ietf.org/html/rfc6979 RFC6979] * [https://en.bitcoin.it/wiki/Address_reuse Address Reuse] +* [http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf FIPS 180-4 (Secure Hash Standard)] diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto index 149dc97..d1c9e4f 100644 --- a/bip-0075/paymentrequest.proto +++ b/bip-0075/paymentrequest.proto @@ -17,14 +17,15 @@ message Output { } 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 - optional bool subtract_fee = 1000; // Allow SubtractableFee - //optional bool replace_by_fee = 1001; // Force RBF true or false (version: 2) + 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 + optional uint64 subtractable_fee = 1000; // How many Satoshis can be subtracted from the requested amount and instead applied towards the fee + optional uint64 fee_per_kb = 1001; // Minimum transaction fee that must be included with the transaction in order for it to be accepted with zero confirmations. + optional bool replace_by_fee = 1002; // Indicates the sender can enable the Replace By Fee flag for this transaction and the receiver will still consider it accepted with zero confirmations. Otherwise, RBF transactions will not be accepted by the receiver until they are confirmed. } message PaymentRequest { optional uint32 payment_details_version = 1 [default = 1]; |