summaryrefslogtreecommitdiff
path: root/bip-0075.mediawiki
diff options
context:
space:
mode:
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)]