each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.
I still haven't seen the section of the BIP that states this to be true.
[...]
If any of this is wrong, then please tell me and I'd appreciate if you supplied sources.
According to BIP 70, it's a non-mandatory part of the protocol. The behaviour is defined in pki_type in the Payment Request message. If pki_type is not supplied, then the protocol treats the instance as if the lack of PKI specifics means that none is to be used. This means the composer of the message needs to specify this correctly themselves, there is no "send to the CA for a signature whether people like it or not" behaviour.
Take a look at the constituents of the PaymentRequest message in BIP 70:
PaymentDetails/PaymentRequest
Payment requests are split into two messages to support future extensibility. The bulk of the information is contained in the PaymentDetails message. It is wrapped inside a PaymentRequest message, which contains meta-information about the merchant and a digital signature.
message PaymentDetails {
optional string network = 1 [default = "main"];
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional string memo = 5;
optional string payment_url = 6;
optional bytes merchant_data = 7;
}
network either "main" for payments on the production Bitcoin network, or "test" for payments on test network. If a client receives a PaymentRequest for a network it does not support it must reject the request.
outputs one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored).
time Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created.
expires Unix timestamp after which the PaymentRequest should be considered invalid.
memo UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for.
payment_url Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK.
merchant_data Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address.
A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:
message PaymentRequest {
optional uint32 payment_details_version = 1 [default = 1];
optional string pki_type = 2 [default = "none"];
optional bytes pki_data = 3;
required bytes serialized_payment_details = 4;
optional bytes signature = 5;
}
payment_details_version See below for a discussion of versioning/upgrading.
pki_type public-key infrastructure (PKI) system being used to identify the merchant. All implementation should support "none", "x509+sha256" and "x509+sha1".
pki_data PKI-system data that identifies the merchant and can be used to create a digital signature. In the case of X.509 certificates, pki_data one or more X.509 certificates (see Certificates section below).
serialized_payment_details A protocol-buffer serialized PaymentDetails message.
signature digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data.
From this, you can see that the Payment Details message is contained in the overall PaymentRequest message (in the serialized_payment_details variable). What I've tried to highlight is, that:
- your Bitcoin public key (message Payment Details { repeated Output outputs })
- the Merchant's message for details of the request (message Payment Details { optional string memo })
- your IP (message Payment Details { optional string payment_url })
are all contained in the presiding message PaymentRequest variable {required bytes serialized_payment_details}.
If you look at the description in the section for the PaymentsRequest message that describes the composition of the signature, also bolded, you'll see that the PaymentRequest message itself is hashed using the public key (optionally) provided by the merchant.
What concerns me is that I have no idea whether the data in the Payments Details (non-mandatory as some of it is) can be somehow cajoled into something meaningful, given that the nature of the hashing of this information involves using a certificate to authenticate that
some of the contents of the hash are verifiable. The PKI public key of the merchant must be positively identified from within the hash of the information, so is the rest of the hashed information also safe?
What is the necessity of sending the PaymentDetails for the purpose of verifying the merchant key, could something that is not user sensitive be used? Or not? Does it even matter at all?
