[bitcoin-dev] Towards a singular payment protocol

[bitcoin-dev] Towards a singular payment protocol

[ee]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

A proposal for a new blockchain-agnostic payment protocol:

https://cypherpunk.org/2019/11/10/towards-a-singular-payment-protocol/

Includes the following characteristics:

- can be used with crypto or fiat currencies
- multiple currency options for a single transaction
- multiple payments in a single transaction
- allow a payment in one currency, but the value to be referenced from a second currency
- fee payment by sender or recipient
- calculation of valuation and fees through common trusted third parties

This is a proposal for a new payment protocol that is not linked to a specific blockchain, and could be supported by many of them, as well as fiat currencies. With one system, wallet developers working on multiple currencies could still look to a single payment system, and thus full support for a single protocol would increase.

I understand that some people will oppose something like this simply because it supports other coins, but I ask that it be looked at from the perspective of a) does it offer better functionality for Bitcoin, and b) would increased support by more wallets for a payment protocol be better for Bitcoin? If those are true, and I think they are, then this can be developed to the benefit of everyone.

This is the first section, focused on the actual payments. Other future sections are planned to include a section on smart contracts and tokens, and a transport mechanism for private communications between buyer and seller.

The goal would be to transform this into a BIP, but I think it needs some discussion first. I would appreciate constructive criticism on the proposal. While I’m open to the argument that payment protocols need to be coin-specific, I think at this point it would be more useful to discuss the functionality first.

Nothing in this section is really blockchain-specific, and the goal would be to keep it that way, and offer the same functionality to everyone.

I thank anyone who takes the time to read this proposal, and I hope to see good feedback on it.

Thank you,

EE



[-- Attachment #2: Type: text/html, Size: 6840 bytes --]

Re: [bitcoin-dev] Towards a singular payment protocol

[Ben Dewaal]

I really don't see any merit to this idea.  To keep the reply brief, here's three of the larger problems I see with it:

1. Other schemes will still exist and aren't likely to be deprecated.  All this proposal is doing is adding one /more/ scheme for wallet developers to support.  It doesn't make their lives any easier.

2. Beyond basic payments, these kinds of simple URI scheme aren't going to be enough anyway.  As we build more complex payment systems with more advanced features, we'll find these kinds of schemes less and less suitable as they grow in the number and complexity of attributes we need to include.  It's just not future-proof, even in the short term.

3. I don't see any reasonable way to define the attributes and what developers should do when their software encounters something it doesn't understand.  It'd either be too strict so that no one implements it, or become a nightmare of incompatible and misunderstood implementations that you never trust your wallet is going to interpret how the URI creator intended.

Regards,
Ben
-- 

Re: [bitcoin-dev] Towards a singular payment protocol

[EE]

[-- Attachment #1: Type: text/plain, Size: 4972 bytes --]

Ben,

Thank you for your comments. Let me take a stab.

> On 13 Nov 2019, at 10:52 AM, Ben Dewaal <b.dewaal@northernbitcoin.com> wrote:
> 
> I really don't see any merit to this idea.  To keep the reply brief, here's three of the larger problems I see with it:
> 
> 1. Other schemes will still exist and aren't likely to be deprecated.  All this proposal is doing is adding one /more/ scheme for wallet developers to support.  It doesn't make their lives any easier.

To be fully realized, clearly it would be best to have the others depreciated. I would argue almost no existing standard is fully implemented in any wallet. I’m not even sure that BIP-21 is fully implemented – which wallets include the req- option for example? Most implementations of the Ethereum standards are incomplete, and I haven’t seen anyone implement BUIP-86 for BCH yet (and its creator is working on BSV anyways). BIP-70 was just depreciated by Bitcoin Core, and its future is iffy (perhaps rightly so for having privacy problems). Part of the problem here is that these are under supported, and because they are different, it takes longer for wallet developers to implement. Keeping track of multiple standards is difficult for developers as well. The idea here is to get the major proposed standards (BIP-21, BIP-70-75, ERC-67, EIP-681, EIP-831, BUIP-86, etc. see my background article https://cypherpunk.org/2019/11/02/a-look-at-cryptocurrency-uris/ that goes further into what already exists) to merge into a single standard used by everyone. This helps everyone, and allows efforts to be focused on a single standard. I think it’s a mistake to say that the payment protocol is part of the blockchain and needs to be developed in tandem with it. In almost every way, it is not part of the blockchain, and is a layer above it. This is a chance to step back from what has been done here, take what is good, drop what is not, and move forward with a single protocol. If Bitcoin developers agree, I imagine other blockchain developers will also agree, and a common system can be developed.

> 2. Beyond basic payments, these kinds of simple URI scheme aren't going to be enough anyway.  As we build more complex payment systems with more advanced features, we'll find these kinds of schemes less and less suitable as they grow in the number and complexity of attributes we need to include.  It's just not future-proof, even in the short term.

As mentioned, this is really the first section of a larger system, the basic payments section. This could be thought of as the basis of the first BIP, and then additional BIPs would be added that are dependent on this one. However, getting this right is key to existing payments that use QR and NFC, and the changes described bring a lot of nice functionality (like being able to ask for payment in one currency based on the value of a second one).

> 3. I don't see any reasonable way to define the attributes and what developers should do when their software encounters something it doesn't understand.  It'd either be too strict so that no one implements it, or become a nightmare of incompatible and misunderstood implementations that you never trust your wallet is going to interpret how the URI creator intended.

I don’t think this is too difficult to define. If there are things that are difficult to interpret, then we can fix them before standardizing. Part of the problem with some of the existing efforts is the sparse standard documents that defined them, leaving things open to interpretation. A well written spec should be able to foresee issues of conflict and design around them.

There could also be different levels of support for this proposal, like 'pay: simple' that supports single payments, 'pay: multi' that supports multiple payments, etc. I’m not sure it’s necessary to do that, but this kind of break down would allow wallets and payment processors to explain exactly what they support without the current confusion where no one really knows which parts of which standards are supported. As they add support for other sets of features, they could announce the additional support.

The end-goal would be that wallets and payment systems would fully support this standard, and be able to say something like 'pay:' supported, and perhaps the other sections would be considered add-ons that could also be used. For example, a merchant could have an NFC terminal with a pay: logo on it. Tap your phone and get the pay: URI sent to your phone, to be processed by your wallet. If the section I’m working on that will discuss a private communication method is also supported by the merchant, the logo might show an additional icon to show that support, and the two-way functionality will be supported (allowing you to confirm things interactively). This is the beginning of a process to figure out these issues and develop a plan to address them.

> Regards,
> Ben

Thank you,

EE


[-- Attachment #2: Type: text/html, Size: 10155 bytes --]

Re: [bitcoin-dev] Towards a singular payment protocol

[Ben Dewaal]

On 13 Nov 2019, at 18:49, EE wrote:

> To be fully realized, clearly it would be best to have the others depreciated.

And I'd argue that others won't be deprecated without a strong reason to switch. Bitcoin is an open protocol and no individual gets to dictate "the right way".  Just because something makes it in to a draft BIP, it doesn't mean it's going to be agreed or implemented.

>  I would argue almost no existing standard is fully implemented in any wallet.

This may be the case, but for Bitcoin at least, BIP-21 is relatively well standardised even if not fully implemented by everyone.  That said, I think most wallet developers - including myself and my team - would rather keep things simple until we see a clear way to proceed.  My current expectation is to support BOLT11 with BIP-21 fallback, plus BIP-21 standalone.  We're building a Bitcoin wallet, not a "cryptocurrency" wallet, so the complexities and difficulties that are faced by things other than Bitcoin really aren't a concern to me.

> BIP-70 was just depreciated by Bitcoin Core

Just to nitpick: BIP-70 was just deprecated *in* Bitcoin Core.  Again, see above where no individual gets to dictate those sorts of things.

> Part of the problem here is that these are under supported, and because they are different, it takes longer for wallet developers to implement.

This works on the assumption of people building cryptocurrency wallets rather than Bitcoin wallets.  I reject the idea that that basic assumption has any merit to it since in practical terms I see no push towards adoption of anything other than Bitcoin, and in theoretical terms, I see no way that anything other than Bitcoin will continue to exist over the mid to long term.  Spending effort to add standards to Bitcoin that bring no benefit to Bitcoin simply seems like a waste of time.

> I think it’s a mistake to say that the payment protocol is part of the blockchain and needs to be developed in tandem with it. In almost every way, it is not part of the blockchain, and is a layer above it.

Here, we agree.  Payments are indeed separate to the underlying technology.  The Lightning Network is a payment network and can be used with other blockchains (assuming you're willing to trust their fundamentally flawed security models).  With this in mind, why define a new standard when those other projects could just start using Lightning and take advantage of its invoice standard?

> the changes described bring a lot of nice functionality (like being able to ask for payment in one currency based on the value of a second one).

I don't understand the value of this.  Right now, I use Bitcoin exclusively, but goods are services around me are (usually) priced in euro.  The merchant will quote a price in euro and their system will ask me to pay in Bitcoin.  My wallet will then display this to me with an equivalent euro value.  It may differ slightly due to different exchange rate providers being called, but I am clear on what I need to pay and have an idea of whether it accords to the listed price of the item.
If however as you suggest, the merchant were to provide a payment request for €5.00 in BTC, then they'd be reliant on my exchange rate provider to pay them.  What if they don't accept what my wallet then says?  It's adding confusion and complexity where that's neither needed nor wanted.  The current behaviour is superior to that.

> I don’t think this is too difficult to define.
> A well written spec should be able to foresee issues of conflict and design around them.

I don't have that level of optimism.  You're talking about a very broad array of different systems each with their own unique features, metadata, and expected two-way communication steps.  It feels to me like you're trying to shoehorn too much in to one thing and would end up with the worst of all possible worlds as the result.

I'm sorry for the quite negative-sounding answer here, but as my team is in the process of building a wallet, I'm strongly against proposals that - if adopted - would add complexity to our work without any obvious benefits to us.  I feel like Lightning invoices and the current discussions around enhancements and improvements in them are more than sufficient to cover our needs for the foreseeable future and beyond that I'd prefer solutions built on top of that than something built with complexity that I see as entirely unnecessary.

Regards,
Ben
--