Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the WPWG develop a cryptocurrency payment method specification #232

Closed
ianbjacobs opened this issue Sep 19, 2017 · 14 comments

Comments

@ianbjacobs
Copy link
Contributor

commented Sep 19, 2017

Hi @AhsanE,

Moved your issue [1] here!

Ian

[1] w3c/payment-request#627

@buhrmi

This comment has been minimized.

Copy link

commented Dec 12, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Dec 12, 2017

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

cc @jmacwhyte

@stan-stripe

This comment has been minimized.

Copy link

commented Dec 12, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Dec 12, 2017

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

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Dec 12, 2017

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.

@webpayments

This comment has been minimized.

Copy link

commented Dec 13, 2017

@cdecker

This comment has been minimized.

Copy link

commented Dec 13, 2017

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.

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Dec 13, 2017

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).

@webpayments

This comment has been minimized.

Copy link

commented Dec 15, 2017

@cdecker

This comment has been minimized.

Copy link

commented Dec 15, 2017

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

This comment has been minimized.

Copy link
Member

commented Dec 20, 2017

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

@ianbjacobs

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2018

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

@ianbjacobs ianbjacobs closed this Apr 25, 2018

@Sjors

This comment has been minimized.

Copy link

commented Sep 10, 2018

@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

This comment was marked as off-topic.

Copy link

commented Sep 10, 2018

@w3c w3c deleted a comment from webpayments Sep 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.