summaryrefslogtreecommitdiff
path: root/bip-0075.mediawiki
diff options
context:
space:
mode:
authorMatt David <matt@netki.com>2016-03-09 18:57:48 -0800
committerMatt David <matt@netki.com>2016-03-09 18:57:48 -0800
commita8c02462951ebbe0c52248aa64a63c7ed547778e (patch)
treed6aad665e3f0276e412789f9d38043d362468396 /bip-0075.mediawiki
parentde42024b1a56ff98de2db3e000f928032c5e55b4 (diff)
downloadbips-a8c02462951ebbe0c52248aa64a63c7ed547778e.tar.xz
- Update optional flags to PaymentDetails definition in paymentrequest.proto
- Add DER encoding requirement for EC public keys and ECC signatures - Add SHA-256 hashing requirement for ECC signatures - Add FIPS 180-4 SHS link
Diffstat (limited to 'bip-0075.mediawiki')
-rw-r--r--bip-0075.mediawiki5
1 files changed, 5 insertions, 0 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)]