Re: [w3c/webpayments] Should the WPWG develop a cryptocurrency payment method specification (#232)

@cdecker wrote on a different [mailinglist]():

> As it stands today the spec should be Bitcoin and Lightning compatible,
with the following considerations:
>
> - A special Payment Method ID [1] must be assigned to Bitcoin and
>   Lightning since we cannot rely on a centralized URL to act as a
>   payment method for these decentralized networks. Currently only the
>   `basic-card` identifier has been assigned, but we can apply for one
>   eventually;
> - As far as I see a local handler can be specified as Payment Handler
>  [2] allowing us to have a Bitcoin or Lightning daemon running locally
>  that is invoked for payment requests;
> - The Payment Request API [3] even mentions XBT as a supported
>  currency, in addition to ISO4217 codes, so if a vendor publishes a
>   Bitcoin amount and a matching Payment Method, we should be able to
>   perform the payment;
> - Since we require special handling for Bitcoin and Lightning
>   w.r.t. the Payment Method, the Payment Method Manifest [4] doesn't
>   apply to us.
>
> So all in all, we should be able to get Bitcoin and Lightning working
> with the spec without any major roadblocks.

I would add that people might have more than one bitcoin wallet, so relying solely on a URI handler to pick the right application isn't ideal.

Bitcoin (and Lightning) wallets are much more involved than just storing a creditcard number in a browser. Particularly the ability of any code involved to change the destination address is something to worry about.

Cryptocurrencies allow significantly more freedom to the payee as to which tool to use to make the payment than most fiat payment methods. It's similar to bank transfers in that the merchant doesn't tell you which bank to use. But it's more interactive than bank transfers because the merchant can provide more details for the wallet to check, and the payee can provide a proof of payment.

Ideally the burden on the (payment processing software of) the merchant should be minimal. Currently they just show an address an amount (or a lightning invoice) and wait for payment.

I don't know what the right architecture is. Even if some browsers come up with built-in wallets, the standard should allow for external wallets.

I'm not too worried about the proliferation of coins. Each Payment Handler can list which coins it supports and behind the scenes it could even trade currencies before making a payment.

Interledger could be a useful tool/standard here, but I would also like a minimalist alternative with fewer moving parts.

The simplest Payment Handler would just open an external wallet and pass some basic stuff (back and) forth. It could just be a wrapper around [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) and [BOLT-11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) URIs. Ideally it lets the user pick from all wallets, rather than open the default.

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/232#issuecomment-419877638