PP pki data

A signature is worthless without the public key that checks it, and BIP70 shipped that key inside a certificate rather than on its own. The field held a small protobuf wrapper around a list of raw DER certificates, ordered from the merchant outward. What it contained decided whether a wallet showed a company name or a bare warning.

How it works

Status: historical. PP pki data was field 3 of the five in a PaymentRequest message, and Bitcoin Core deleted the code that read it in version 0.20.0, released June 3, 2020.

Inside the bytes sat a protobuf message named X509Certificates with exactly one repeated field, each entry a complete certificate in binary form. The order was specified rather than left to taste: the merchant's own certificate came first, then whatever intermediates were needed to reach a public root.

The root itself was deliberately absent, and the reasoning generalizes far beyond BIP70. A root you receive from the party you are trying to verify proves nothing, since anyone can generate one and sign anything they like with it. Trust has to arrive from a list your device already holds.

DER, the encoding used, is the canonical binary form of ASN.1: one structure, exactly one legal byte sequence. The familiar PEM format with its BEGIN CERTIFICATE lines is those same bytes in base64, which costs about a third more space, so the wire format is always the raw one.

Certificates dominated the size of a request. Outputs, a timestamp and a note might come to a couple of hundred bytes, while an RSA-2048 certificate alone carries a 256-byte modulus and a 256-byte signature before any names or extensions are counted, and two of them in sequence run into thousands. Where the pki type was "none" the field was simply empty and a wallet had nothing to display but the destination.

Where you see it

The same certificate list, in the same leaf-first order, arrives on every HTTPS connection you make.

A TLS server sends its own certificate first and the intermediates after it, omitting the root for the reason above. You can read the exact list any site sends with one command, openssl s_client -showcerts -connect example.com:443, and what prints is the identical material BIP70 was carrying, shown in PEM rather than binary.

For someone buying bitcoin, the lesson is in what those bytes do not tell you. A valid chain proves that some authority checked control of a domain name at the moment of issuance. It says nothing about who owns the company, whether the page is a clone of an exchange, or whether that exchange can meet withdrawals. Phishing sites carry entirely valid certificates, obtained free and in seconds, and the padlock they produce is indistinguishable from the real one.

So read the domain, not the lock. Reach an exchange through a bookmark you made once rather than through a search advertisement, and treat a certificate warning on a site holding your money as a full stop rather than a prompt.

PP pki data vs certificate chain

PP pki data was a container; the certificate chain is what went in it. Naming pki data only makes sense while reading BIP70 documentation or archived wallet source, because nothing else has ever used the term. A chain, by contrast, is a live thing you depend on daily, and the ordering rule BIP70 wrote down, leaf first with the root omitted, is the rule TLS still follows.