[bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets

[bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets

[James Hilliard]

Recently a large merchant payment processor has decided to drop
support for BIP21 payment URI's in favor of accepting exclusively
BIP70 payments which has brought to light a number of problems with
BIP70:

1. Many wallets do not support BIP70 and have no near term intention
of doing so.
2. BIP70 requires large complex PKI dependencies such as X.509 and TLS
support(usually via openssl) which have a large attack surface and
poor track record when it comes to vulnerabilities.
3. Signing transactions with keys resident in the same application as
that which handles TLS greatly increases the possibility of keys being
leaked due to vulnerabilities in TLS libraries such as
openssl(heartbleed etc).
4. Sending payments first to a BIP70 compatible wallet before sending
to the merchant increases fees and uses more block space than sending
directly since it is often not feasible for users to fully migrate
funds to a BIP70 compatible wallet.
5. Paying a BIP70 invoice with an incompatible wallet currently
requires manual non-user-friendly workarounds such as
https://github.com/achow101/payment-proto-interface

I propose that we move the BIP70 protocol implementation into a
browser extension that can communicate with wallets over a simple IPC
mechanism such as
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
in addition to acting as a translation layer that can convert BIP70
URL's into standard BIP21 URI's for wallets that do not wish to
support BIP70 or other custom schemes.

This will provide a number of advantages over the current method of
implementing BIP70 directly within wallets:

1. It removes complex/risky dependencies from wallets and moves them
into the browser which already has to implement full PKI support.
2. It re-enables payment support for wallets that only support
BIP21/normal addresses.
3. It makes offline/custom signing schemes easier to use with BIP70.

Re: [bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets

[Ryan Grant]

On Mon, Jan 1, 2018 at 1:50 PM, James Hilliard via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I propose that we move the BIP70 protocol implementation into a
> browser extension that can communicate with wallets over a simple IPC
> mechanism [...]

As a reminder, there is a W3C Payments API, currently proceeding along
the W3C Recommendation track, which registers "payment handlers" in
the browser, and selects one to complete a transaction:

  https://w3c.github.io/payment-handler/

The purpose of the payments API is to automate all data entry and
handle choices related to common transactions on the Web.  Payment
requests will often ask for information that Bitcoin wallets have no
current need to provide, such as a shipping address.  If shipping
options or other personally identifying information (such as an email
address and a return payment address) are involved, then it is the
chosen payment type's *handler* that is tasked with negotiating with
the user how to reveal the supposedly necessary information.

  https://www.w3.org/TR/payment-request/#the-options-argument

Although it may seem early for wallet makers to consider integration
with a mere W3C Recommendation, it would not be early to choose the
right architecture to build code on, given that this is in the works
for the major browsers.  Development can proceed even in browsers that
have not implemented anything, through an HTML5 Javascript polyfill.
A demonstration which includes payment in bitcoins is already
available, although it leaves as an exercise for the reader exactly
how the txid would be made known to the handler (whether manually
input by paste buffer after copying from an external app, or returned
through IPC):

  https://web-payments.io/
  https://github.com/digitalbazaar/payment-handler-polyfill

From my brief inspection: not bad.  I don't see anything in this spec
that would preclude the workflow of a Bitcoin transaction, whether
on-chain (with the seller's backend marking off confirmations) or
using the Lightning Network.  It even allows the seller to offer a
discount on certain payment methods:

  https://www.w3.org/TR/payment-request/#dom-paymentdetailsmodifier