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

[Ben Dewaal <b.dewaal@northernbitcoin.com>]

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