Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how Bitcoin uses the BIP70 payment protocol API. The article is rich and analyzed and described from a professional point of view. I hope you can get something after reading this article.

A payment protocol is a term used to refer to the protocols specified in BIP70,71,72 and 73. The payment protocol aims to add additional functionality to bitcoin by replacing ubiquitous bitcoin addresses with small files that encode more complex parameters. It specifies the format of payment requests, payments, and payment methods that flow directly between the sender and receiver of funds.

The payment protocol is critical to the development of various important functions of Bitcoin, so it is important to understand how it uses Bitcoin. The basic functionality is described below and some sample code for integrating it into the wallet application is shown.

Specifically, version 1 of the agreement provides:

1. The receiver / merchant uses any script to request multiple outputs, not just the output of a single pay key hash type. Multiple separate transactions can satisfy payments, allowing future implementation of privacy technologies based on evading mergers.

two。 Free text memo field, so the merchant can fill in the purchase details stored by the wallet and the user appends a message when paying.

3. At the expiration time, expired payment requests may be considered invalid. This allows the receiver to bind its resource usage on the server side and discard requests that have not been paid for.

4. When it is issued and when the request for payment is made-it is good for record keeping.

5. The binary cookie-esque field, which is simply echoed to the server when a payment transaction is submitted, allows the merchant to implement a stateless backend.

6. The user-specified refund address.

7. The optional feature of signing all of the above using an X.509 digital certificate to bind the payment request to some authenticated identity.

The fact that the payment request itself can be digitally signed can achieve some very important and useful functions. The one in the middle can't rewrite the output and hijack the payment. This is especially important for hardware wallets such as Trezor, because Trezor assumes that the host is damaged, otherwise users will not know that the payment they authorize is the same as the payment requested by the merchant.

In addition, a digitally signed payment request and a transaction that satisfies it on the blockchain create proof of payment that is very similar to a receipt. Receipts are useful for dispute resolution and proof of purchase, and merchants do not have to keep a detailed database of every customer they have ever owned-even if the merchant deletes data about you, just showing the receipt is enough to prove that you have made the purchase.

The protocol buffer is a binary data serialization format that can be easily extended. As a result, we can easily imagine many other features that might be added in the future.

You can read the FAQ of the payment agreement to explain in detail the basic principles behind its design.

Protocol Overview

In normal bitcoin payments, the process begins when the user clicks on the bitcoin URI or copies and pastes the text address into their wallet application and manually specifies the amount.

In payments processed by a payment agreement, the process starts in one of two ways:

The user clicks the bitcoin URI with the new "r" parameter, which contains the (http) URL that parses to the payment request file.

The user opens the payment request file directly.

Then, the user's wallet parses the payment request data as a protocol buffer and starts the process of normal request confirmation. When you click the bitcoin URI, the instructions in the rest of the URI (they are for backward compatibility only) are ignored, and the data found at the given URL takes precedence.

The payment request consists of an external "skin" message that contains (optional) signature and certificate data, as well as an embedded serialization of the internal "core" message containing the details of the requested payment. External PaymentRequest messages are independent of the type of digital signature infrastructure used, but only X.509 bindings are currently defined. This is the same system used in SSL. Internal PaymentDetails messages are stored in binary form and are not embedded like normal protobuf messages to ensure that signature bytes always match.

Once the wallet has created a satisfactory bitcoin transaction set, the payment message is formatted and uploaded to the target URL specified by PaymentDetails, and once the payment is satisfactorily accepted, the wallet receives the PaymentACK message.

Signatures and certificates

The purpose of signing the payment request is to replace such messages in the user's wallet application:

Pay 10mBTC to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?

With such a:

Pay 10mBTC to satoshin@gmx.com?

Pay 20mBTC to overstock.com?

Pay 3 billion bitcoins to Michael Hearn?

Pay 100 BTC to Genius Widgets Company in San Francisco, California

. Of course, the first form is the most useless, because in this case, identity is just a random number that is meaningless or stable. This leads to the question of where the strings in other examples come from.

The answer is that they are included in the X.509 digital certificate, which itself is signed by the certification authority. Despite the name, CA is just any entity that signs a certificate, and the only thing that gives them authority is people's trust in software. There is a competitive market for ID authentication and certification, which means you can get certificates for identity certificates (such as email addresses or domain names) that are very easy to verify for free. More complex identities, such as the legal name of a person or company, require more effort to verify, so you must pay for it.

Technically, a certificate is just a declaration of a public key, so you must first generate the private key, then the certificate signature request (CSR), then select CA and upload the CSR, as well as the identity you want and any information needed for authentication. CA then sends back a signed certificate that can be embedded in the payment request as well as any intermediate certificates needed to reach a set of root certificates. The PaymentDetails message is then signed with the private key, and now other user software can verify all of this and display the authenticated ID in the user interface. It also serves as encrypted proof that you actually made a given payment request at a specified time.

In fact, the above processes such as manually creating keys, creating CSR, and uploading passwords usually automatically cancel the end-user e-mail address certificate: on the contrary, any modern Web browser that supports HTML5 can be used to automate the whole process. After visiting the CA that publishes free certificates such as Comodo, the user enters the requested email address and clicks the button. Then their browser generates a new private key and records it. When the user clicks the verification link that is delivered to their e-mail address, the signing process is complete and the certificate is installed in the local key store where it can be used or exported to another device. The whole process is not much different from registering a website.

Payment Protocol API in bitcoinj

In 0.12, support for payment protocols in bitcoinj is limited. It supports everything you need for basic support in wallet applications for signing and using payment requests. However, it does not support storing them in wallets for future reference. Bitcoinj also did not take advantage of the opportunity to submit multiple separate transactions to the recipient to circumvent the merger.

Still, here is a demonstration of how we can use the new features.

String url = QRCodeScanner.scanFromCamera (.); ListenableFuture future;if (url.startsWith ("http")) {/ / URL may serve either HTML or a payment request depending on how it's fetched. / / Try here to get a payment request. Future = PaymentSession.createFromUrl (url);} else if (url.startsWith ("bitcoin:")) {future = PaymentSession.createFromBitcoinUri (new BitcoinURI (url));} PaymentSession session = future.get (); / / may throw PaymentRequestException.String memo = session.getMemo (); Coin amountWanted = session.getValue (); if (session.isExpired ()) {showUserErrorMessage ();} PaymentSession.PkiVerificationData identity = null;try {identity = session.verifyPki ();} catch (Exception e) {log.error (e) / / Don't show errors that occur during PKI verification to the user! / / Just treat such payment requests as if they were unsigned. This way / / new features and PKI roots can be introduced in future without / / being disruptive.} if (identity! = null) {showUserConfirmation (identity.domainName, identity.orgName);} else {showUserConfirmation ();} / / a bit later when the user has confirmed the paymentSendRequest req = session.getSendRequest (); wallet.completeTx (req); / / may throw InsufficientMoneyException// No refund address specified, no user specified memo field.ListenableFuture ack = session.sendPayment (ImmutableList.of (req.tx), null, null) Futures.addCallback (ack, new FutureCallback () {@ Override public onSuccess (PaymentSession.Ack ack) {wallet.commitTx (req.tx); displayMessage (ack.getMemo ());}}); user interface considerations

It is important to submit payment agreement confirmation in a specific manner.

First of all, if the signed PKI data is available, you should indicate it to the user in some visually meaningful way, so they know that the string being rendered is ID verified by a third party. The name of the third party (that is, CA) should also be visible, although it is acceptable to hide it behind the switch / slider by default.

Second, if signed PKI data is provided but cannot be verified, the payment should be presented in exactly the same way as if the signature data was completely lost. The experience of opening a request with the wrong signature is never worse than opening a request with no signature at all. This gives us the flexibility to introduce new certification authorities or signing systems.

Two-dimensional code

If your application integrates support for scanning QR codes, you should pay attention to BIP 73. It says that if the wallet application scans the QR code and finds HTTP URL instead of bitcoin URI, it should execute HTTP [S] GET to URL with a special HTTP header, which requires the server to provide a payment request.

The purpose of this mechanism is to allow merchants and payment processors to provide QR codes that can work on any type of QR scanner, and if the user does not have a wallet with an integrated scanner, a beautiful HTML invoice page with instructions and a clickable bitcoin link can be displayed.

Operating system integration

If you want to write a wallet application, you should register to handle bitcoin URI, and you should also register files of processing type application/bitcoin-paymentrequest with the extension .bitcoinpaymentrequest.

By doing so, you can ensure that your application can handle payment requests attached to e-mail, sent through IM applications, and so on.

Ideally, you can also allow users to create payment requests. The pki_type of a PaymentRequest message can be "none", so it is valid to create such a file. For a simple user experience, we recommend:

On the desktop, allow the user to drag and drop the payment request file (represent it as an icon). For example, the user can drag it to the email composition window to attach the payment request to the email and manually copy / paste the address and amount. Gmail supports dragging and dropping files into the editor, and other HTML5 applications can also accept drag and drop data.

On mobile devices, users are allowed to "share" payment request files, which will allow users to send through chat applications, attach to e-mail, and share via DropBox/Google Drive, etc.

This is how the bitcoin shared by the editor uses the BIP70 payment protocol API. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.