BIP 0070 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/6545b81022212a9f/bip-0070.mediawiki

2022-10-01T00:27:27Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/6545b81022212a9f/bip-0070.mediawiki

← Older revision		Revision as of 00:27, 1 October 2022
Line 318:		Line 318:
	especially the list of Electronic Invoice standards		especially the list of Electronic Invoice standards

	sipa's payment protocol proposal: https://gist.github.com/1237788		sipa's payment protocol proposal: https://gist.github.com/sipa/1237788

	ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html		ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html

2019-09-24T18:00:25Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0070.mediawiki

2015-12-29T13:47:12Z

Removing redundant parameter.

2015-06-13T15:04:31Z

updated status

← Older revision		Revision as of 15:04, 13 June 2015
Line 5:		Line 5:
	Title: Payment Protocol		Title: Payment Protocol
	Author: Gavin Andresen <gavinandresen@gmail.com>		Author: Gavin Andresen <gavinandresen@gmail.com>
	Status: ~~Draft~~		Status: Final
	Type: Standards Track		Type: Standards Track
	Created: 29-07-2013		Created: 29-07-2013

2013-12-06T08:19:59Z

Github move

2013-08-28T01:46:51Z

Require Accept: and Content-Type headers in Payment->PaymentACK round trip.

← Older revision		Revision as of 01:46, 28 August 2013
Line 161:		Line 161:
	attacks that might alter Payment.refund_to (if using HTTP, it must be		attacks that might alter Payment.refund_to (if using HTTP, it must be
	TLS-protected).		TLS-protected).

			Wallet software sending Payment messages via HTTP must set appropriate
			Content-Type and Accept headers, as specified in BIP 71:
			<pre>Content-Type: application/bitcoin-payment
			Accept: application/bitcoin-paymentack
			</pre>

	When the merchant's server receives the Payment message, it must		When the merchant's server receives the Payment message, it must

2013-07-31T11:17:43Z

PaymentACK

← Older revision		Revision as of 11:17, 31 July 2013
Line 180:		Line 180:
	{\|		{\|
	\| payment \|\| Copy of the Payment message that triggered this PaymentACK. Clients may ignore this if they implement another way of associating Payments with PaymentACKs.		\| payment \|\| Copy of the Payment message that triggered this PaymentACK. Clients may ignore this if they implement another way of associating Payments with PaymentACKs.
			\|-
	\| memo \|\| UTF-8 encoded note that should be displayed to the customer giving the status of the transaction (e.g. "Payment of 1 BTC for eleven tribbles accepted for processing.")		\| memo \|\| UTF-8 encoded note that should be displayed to the customer giving the status of the transaction (e.g. "Payment of 1 BTC for eleven tribbles accepted for processing.")
	\|}		\|}

2013-07-31T11:10:38Z

Added explict text about root certificates

← Older revision		Revision as of 11:10, 31 July 2013
Line 215:		Line 215:
	Each certificate is a DER [ITU.X690.1994] PKIX certificate value. The		Each certificate is a DER [ITU.X690.1994] PKIX certificate value. The
	certificate containing the public key of the entity that digitally		certificate containing the public key of the entity that digitally
	signed the PaymentRequest ~~MUST~~ be the first certificate. This MAY be		signed the PaymentRequest must be the first certificate. This MAY be
	followed by additional certificates, with each subsequent certificate		followed by additional certificates, with each subsequent certificate
	being the one used to certify the previous one. The recipient ~~MUST~~		being the one used to certify the previous one, up to a trusted root
	verify the certificate chain according to [RFC5280] and reject the		authority. The recipient must verify the certificate chain according to
	PaymentRequest if any validation failure occurs.		[RFC5280] and reject the PaymentRequest if any validation failure
			occurs.

			Trusted root certificates may be obtained from the operating system;
			if validation is done on a device without an operating system, the
			[http://www.mozilla.org/projects/security/certs/included/index.html Mozilla root store] is recommended.

	==Extensibility==		==Extensibility==

2013-07-31T11:04:54Z

Add description of payment field.

← Older revision		Revision as of 11:04, 31 July 2013
Line 179:		Line 179:
	</pre>		</pre>
	{\|		{\|
			\| payment \|\| Copy of the Payment message that triggered this PaymentACK. Clients may ignore this if they implement another way of associating Payments with PaymentACKs.
	\| memo \|\| UTF-8 encoded note that should be displayed to the customer giving the status of the transaction (e.g. "Payment of 1 BTC for eleven tribbles accepted for processing.")		\| memo \|\| UTF-8 encoded note that should be displayed to the customer giving the status of the transaction (e.g. "Payment of 1 BTC for eleven tribbles accepted for processing.")
	\|}		\|}

2013-07-31T10:59:05Z

Suggest authenticating Payment.merchant_data, and payment_url "should" be MITM secure

← Older revision		Revision as of 10:59, 31 July 2013
Line 142:		Line 142:
	</pre>		</pre>
	{\|		{\|
	\| merchant_data \|\| copied from PaymentDetails.merchant_data. Merchants may use invoice numbers or any other data they require to match Payments to PaymentRequests.		\| merchant_data \|\| copied from PaymentDetails.merchant_data. Merchants may use invoice numbers or any other data they require to match Payments to PaymentRequests. Note that malicious clients may modify the merchant_data, so should be authenticated in some way (for example, signed with a merchant-only key).
	\|-		\|-
	\| transactions \|\| One or more valid, signed Bitcoin transactions that fully pay the PaymentRequest		\| transactions \|\| One or more valid, signed Bitcoin transactions that fully pay the PaymentRequest
Line 158:		Line 158:
	Errors communicating with the payment_url server should be communicated to the user.		Errors communicating with the payment_url server should be communicated to the user.

	PaymentDetails.payment_url ~~must~~ be secure against man-in-the-middle		PaymentDetails.payment_url should be secure against man-in-the-middle
	attacks that might alter Payment.refund_to (if using HTTP, it must be		attacks that might alter Payment.refund_to (if using HTTP, it must be
	TLS-protected).		TLS-protected).