From: Ben Dewaal <b.dewaal@northernbitcoin.com>
To: EE via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Towards a singular payment protocol
Thread-Index: AQHVmbm45ePWoU1fUEKN/UAwnLQawKeIxyiggACarICAATDRpQ==
Date: Thu, 14 Nov 2019 12:31:44 +0000
Message-ID: <FRXPR01MB0454349170173F4A05B14E4C81710@FRXPR01MB0454.DEUPRD01.PROD.OUTLOOK.DE>
References: <D5859AF5-CA49-42DF-8FAE-5BBBE2DF6699@cypherpunk.org>
	<FRXPR01MB04543D16EA2749E6900E8C5B81760@FRXPR01MB0454.DEUPRD01.PROD.OUTLOOK.DE>,
	<FE599986-C494-4473-8AFE-4250BB2533B3@cypherpunk.org>
In-Reply-To: <FE599986-C494-4473-8AFE-4250BB2533B3@cypherpunk.org>
Accept-Language: en-CA, en-DE, en-NZ, en-US
Content-Language: en-CA
received-spf: None (protection.outlook.com: northernbitcoin.com does not
	designate permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5bc602b3-9f58-443a-b39f-08d768fe9c5d
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2019 12:31:44.9833 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c0b5a774-f061-4411-9d7b-16ec8f6deb96
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vRNNKI6nsotgTLCkyzpRJx5CmPSqdfO3D6o5X030NL4vGdVD44wFIXhxnMS1XiDyNAHnHPV2R11HqpcTEhON9tz1+x93GAeNfeA0csFAAgE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB1064
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 14 Nov 2019 18:29:51 +0000
Subject: Re: [bitcoin-dev] Towards a singular payment protocol
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2019 12:31:49 -0000

On 13 Nov 2019, at 18:49, EE wrote:=0A=
=0A=
> To be fully realized, clearly it would be best to have the others depreci=
ated.=0A=
=0A=
And I'd argue that others won't be deprecated without a strong reason to sw=
itch. Bitcoin is an open protocol and no individual gets to dictate "the ri=
ght way".  Just because something makes it in to a draft BIP, it doesn't me=
an it's going to be agreed or implemented.=0A=
=0A=
>  I would argue almost no existing standard is fully implemented in any wa=
llet.=0A=
=0A=
This may be the case, but for Bitcoin at least, BIP-21 is relatively well s=
tandardised even if not fully implemented by everyone.  That said, I think =
most wallet developers - including myself and my team - would rather keep t=
hings simple until we see a clear way to proceed.  My current expectation i=
s to support BOLT11 with BIP-21 fallback, plus BIP-21 standalone.  We're bu=
ilding 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.=0A=
=0A=
> BIP-70 was just depreciated by Bitcoin Core=0A=
=0A=
Just to nitpick: BIP-70 was just deprecated *in* Bitcoin Core.  Again, see =
above where no individual gets to dictate those sorts of things.=0A=
=0A=
> Part of the problem here is that these are under supported, and because t=
hey are different, it takes longer for wallet developers to implement.=0A=
=0A=
This works on the assumption of people building cryptocurrency wallets rath=
er 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 an=
ything 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 Bitc=
oin simply seems like a waste of time.=0A=
=0A=
> I think it=92s 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.=0A=
=0A=
Here, we agree.  Payments are indeed separate to the underlying technology.=
  The Lightning Network is a payment network and can be used with other blo=
ckchains (assuming you're willing to trust their fundamentally flawed secur=
ity models).  With this in mind, why define a new standard when those other=
 projects could just start using Lightning and take advantage of its invoic=
e standard?=0A=
=0A=
> 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).=0A=
=0A=
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 merch=
ant will quote a price in euro and their system will ask me to pay in Bitco=
in.  My wallet will then display this to me with an equivalent euro value. =
 It may differ slightly due to different exchange rate providers being call=
ed, but I am clear on what I need to pay and have an idea of whether it acc=
ords to the listed price of the item.=0A=
If however as you suggest, the merchant were to provide a payment request f=
or =805.00 in BTC, then they'd be reliant on my exchange rate provider to p=
ay 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 curre=
nt behaviour is superior to that.=0A=
=0A=
> I don=92t think this is too difficult to define.=0A=
> A well written spec should be able to foresee issues of conflict and desi=
gn around them.=0A=
=0A=
I don't have that level of optimism.  You're talking about a very broad arr=
ay 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 p=
ossible worlds as the result.=0A=
=0A=
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 enh=
ancements and improvements in them are more than sufficient to cover our ne=
eds for the foreseeable future and beyond that I'd prefer solutions built o=
n top of that than something built with complexity that I see as entirely u=
nnecessary.=0A=
=0A=
Regards,=0A=
Ben=0A=
-- =