Should the WPWG develop a cryptocurrency payment method specification about webpayments

[adrianhopebailie]

Using crypto-currencies with the API is a matter of writing a payment method spec and getting implementations if that in wallets.

One of the challenges with crypto is there is now a proliferation of coins so support would be very fragmented.

One of the goals of the Interledger work is to provide a standard interaction that could overlay this and be currency agnostic.

The other benefit of using Interledger is that there is a built in concept of a "proof of payment" which works well with the PR API flow.

We foresee the flow working as follows:

1. PR is called with "interledger" as a supported method. (Note this is not a URL-type payment method identifier as there is no manifest allowing anyone to control the payment method. Support is already built into Chrome and we hope others will follow when the WG takes up the Payment Method spec)
2. An "interledger" capable wallet gets the ILP Address of the receiver, the amount that must be delivered and the condition to use from the PR.
3. It sends the ILP payment (source of funds being any account that can send to an ILP connector on the payment route)
4. It returns the fulfillment (from the completed payment) to the merchant website

This could be either a payment in a single currency or one where the sending currency is different to the receiving account.

My expectation is that even for single currency payments ILP is useful because it provides a standard interaction that wallets and websites can implement once and use for any currency.

We're busy doing some experiments with payment channels as this seems like the only viable way to do retail payments using crypto-currencies otherwise the payment takes too long to complete. Expect a few prototypes using Lightning and microRaiden over the coming months.

If you are interested in building an implementation or working with us on this we'd love to work together.

[adrianhopebailie]

One thing to note here is that Lightning and similar networks already natively support in-network currency exchanges, e.g., having a payment start in one currency and the recipient receiving another currency.

That's not entirely true. Lightning has intentions of being cross-currency but that is a long way off at this point and the complexity of doing cross-currency hasn't begun to be explored in detail.

Lightning is a great advance for Bitcoin and Litecoin and any chain that can implement it but cross-chain is hard (and technically impossible with Lightning if the destination/source is not Lightning compatible).

[buhrmi]

Yes, please work on this. This will be especially interesting on mobile.
Is this the main communications channel for integration of crypto currency and Payment Request API? It seems like such an obvious marriage of technologies to me, so it's a bit confusing that there is not more discussion/activity. If there already is an effort underway, please let me know. Otherwise I'd like to take this on....

[ianbjacobs]

Yes, you can continue to discuss here. Thanks!
Ian

cc @jmacwhyte

[stan-stripe]

@ianbjacobs would you mind expanding a bit on which features you see missing to the Payment Request API (as mentioned in [0]) to support cryptocurrencies in general? I presume this brings us back to all the questions about asynchronous payment methods in general?

Also we already have interledger whitelisted right? But they're going towards "synchronous" payment experience as far as I can tell.

[0 ]w3c/payment-request#627

[ianbjacobs]

Hi @stan-stripe,

My understanding of the question today is: can we create a bitcoin (or other cryptocurrency) payment method?

I have not put any thought into what features may be needed in PR API beyond what we have today. In the past, we added the (transaction) id to PR API for push payments or other methods that might require reconciliation. I don't know whether that suffices; work on a payment method would help us determine that.

Regarding interledger, @adrianhopebailie has indicated he will be bringing a payment method spec to the Working Group. We are not yet officially working on that but we intend to.
Ian

[webpayments]

Hi Guys! @stan-stripe <https://github.com/stan-stripe> This is something we (Bread) really want to work on. Unfortunately, we are launching a token sale starting this weekend which is currently consuming all of our time. But if you are interested to work on this together, I would love to collaborate. Perhaps starting in January as soon as the holidays are over? Downloading all the relevant info from Ian and Adrian is a good start! Thanks, James

…

On Tue, Dec 12, 2017 at 1:18 PM, Adrian Hope-Bailie < ***@***.***> wrote: Using crypto-currencies with the API is a matter of writing a payment method spec and getting implementations if that in wallets. One of the challenges with crypto is there is now a proliferation of coins so support would be very fragmented. One of the goals of the Interledger work is to provide a standard interaction that could overlay this and be currency agnostic. The other benefit of using Interledger is that there is a built in concept of a "proof of payment" which works well with the PR API flow. We foresee the flow working as follows: 1. PR is called with "interledger" as a supported method. (Note this is not a URL-type payment method identifier as there is no manifest allowing anyone to control the payment method. Support is already built into Chrome and we hope others will follow when the WG takes up the Payment Method spec) 2. An "interledger" capable wallet gets the ILP Address of the receiver, the amount that must be delivered and the condition to use from the PR. 3. It sends the ILP payment (source of funds being any account that can send to an ILP connector on the payment route) 4. It returns the fulfillment (from the completed payment) to the merchant website This could be either a payment in a single currency or one where the sending currency is different to the receiving account. My expectation is that even for single currency payments ILP is useful because it provides a standard interaction that wallets and websites can implement once and use for any currency. We're busy doing some experiments with payment channels as this seems like the only viable way to do retail payments using crypto-currencies otherwise the payment takes too long to complete. Expect a few prototypes using Lightning and microRaiden over the coming months. If you are interested in building an implementation or working with us on this we'd love to work together. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#232 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APFrHOXILJmt1juh1x6TJmSgvoQg0BaNks5s_u2tgaJpZM4Pcukp> .

[cdecker]

One thing to note here is that Lightning and similar networks already natively support in-network currency exchanges, e.g., having a payment start in one currency and the recipient receiving another currency.

[webpayments]

Hi Chris Did you know if there are some documents or point of view about "Lightning" integration with money payment based networks? Best Regards Carlos Arturo Quiroga Quiroga. From: Christian Decker <[email protected]> To: w3c/webpayments <[email protected]> Cc: webpayments <[email protected]>, Comment <[email protected]> Date: 12/13/2017 08:02 AM Subject: Re: [w3c/webpayments] Should the WPWG develop a cryptocurrency payment method specification (#232) One thing to note here is that Lightning and similar networks already natively support in-network currency exchanges, e.g., having a payment start in one currency and the recipient receiving another currency. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[cdecker]

Did you know if there are some documents or point of view about "Lightning" integration with money payment based networks?

You mean having Lightning integrate with a fiat based payment handlers? I'm not aware of any, though that might be an interesting extension. Let's maybe spin this off somewhere else in order not to hijack this issue.

[marcoscaceres]

@webpayments, can you kindly trim your email responses when you reply? Otherwise, our comment history gets all screwed up every time you respond.

[ianbjacobs]

Closing (no change though a spec is still welcome).

[Sjors]

@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 payer 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 payer 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 and BOLT-11 URIs. Ideally it lets the user pick from all wallets, rather than open the default.

[webpayments]

Je suis absent(e) du bureau jusqu'au 17/09/2018 Please kindly note my absence for the period mentioned above. You can reach Béatrice Cocozza at [phone] Remarque : ceci est une réponse automatique à votre message "Re: [w3c/webpayments] Should the WPWG develop a cryptocurrency payment method specification (#232)" envoyé le 10/09/2018 13:14:07. C'est la seule notification que vous recevrez pendant l'absence de cette personne.

…

-------------------------------------------------------------------------------------------------------------------------------------------- Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. Le Groupement des Cartes Bancaires "CB" décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. This message and any attachments are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Groupement des Cartes bancaires "CB" shall not be liable for the message if altered, changed or falsified.