path: root/aa/ca2dbd3ee5009b3db5fee50c0e02c783ffd130

Return-Path: <ee@cypherpunk.org>
Received: from smtp2.linuxfoundation.org (smtp2.linux-foundation.org
	[172.17.192.36])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EC2F8B8F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Nov 2019 17:49:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smtprelay.hostedemail.com (smtprelay0180.hostedemail.com
	[216.40.44.180])
	by smtp2.linuxfoundation.org (Postfix) with ESMTPS id B22381DAA7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Nov 2019 17:49:20 +0000 (UTC)
Received: from smtprelay.hostedemail.com (10.5.19.251.rfc1918.com
	[10.5.19.251])
	by smtpgrave07.hostedemail.com (Postfix) with ESMTP id 7549718029146
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Nov 2019 17:49:18 +0000 (UTC)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net
	[216.40.38.60])
	by smtprelay03.hostedemail.com (Postfix) with ESMTP id D6B90838434C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Nov 2019 17:49:15 +0000 (UTC)
X-Session-Marker: 65654063797068657270756E6B2E6F7267
X-Spam-Summary: 50, 3, 0, , d41d8cd98f00b204, ee@cypherpunk.org, :,
	RULES_HIT:4:41:72:152:355:379:541:599:800:962:967:973:983:988:989:1042:1189:1208:1212:1221:1260:1261:1313:1314:1345:1359:1381:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1730:1776:1792:2068:2069:2194:2198:2199:2200:2525:2527:2553:2561:2564:2636:2682:2685:2688:2692:2693:2859:2891:2909:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3650:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4361:4362:5007:6119:6248:6657:6670:7652:7875:7903:8526:8603:9025:9108:9177:10004:10128:10848:11232:11656:11658:11854:11914:12043:12297:12740:12895:13139:13149:13161:13229:13230:14516:14659:21080:21324:21433:21451:21611:21627:21659:21740:21772:21788:21810:21888:21939:30003:30016:30034:30038:30039:30054:30070:30090,
	0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none,
	DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none,
	Custom_rules:0:0:0, LFtime:2, L UA_SUMMA
X-HE-Tag: snow81_3397d6d870108
X-Filterd-Recvd-Size: 17365
Received: from [10.4.0.9] (unknown [69.36.182.80])
	(Authenticated sender: ee@cypherpunk.org)
	by omf07.hostedemail.com (Postfix) with ESMTPA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Nov 2019 17:49:14 +0000 (UTC)
From: EE <ee@cypherpunk.org>
X-Mailbutler-Message-Id: EEF3A1B5-8753-4451-8EB5-A54A012339EC
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_161F8E97-D0DF-4875-83D0-C5ACB9CDA629"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 13 Nov 2019 19:49:05 +0200
References: <D5859AF5-CA49-42DF-8FAE-5BBBE2DF6699@cypherpunk.org>
	<FRXPR01MB04543D16EA2749E6900E8C5B81760@FRXPR01MB0454.DEUPRD01.PROD.OUTLOOK.DE>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <FRXPR01MB04543D16EA2749E6900E8C5B81760@FRXPR01MB0454.DEUPRD01.PROD.OUTLOOK.DE>
Message-Id: <FE599986-C494-4473-8AFE-4250BB2533B3@cypherpunk.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp2.linux-foundation.org
X-Mailman-Approved-At: Wed, 13 Nov 2019 17:50:03 +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: Wed, 13 Nov 2019 17:49:22 -0000


--Apple-Mail=_161F8E97-D0DF-4875-83D0-C5ACB9CDA629
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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:
>=20
> 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:
>=20
> 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=E2=80=99m not even sure that BIP-21 is =
fully implemented =E2=80=93 which wallets include the req- option for =
example? Most implementations of the Ethereum standards are incomplete, =
and I haven=E2=80=99t 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=E2=80=99s 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=E2=80=99t 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=E2=80=99m not sure it=E2=80=99s 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=E2=80=
=99m 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


--Apple-Mail=_161F8E97-D0DF-4875-83D0-C5ACB9CDA629
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D"">Ben,<div class=3D""><br class=3D""></div><div class=3D"">Thank =
you for your comments. Let me take a stab.<br class=3D""><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 13 =
Nov 2019, at 10:52 AM, Ben Dewaal &lt;<a =
href=3D"mailto:b.dewaal@northernbitcoin.com" =
class=3D"">b.dewaal@northernbitcoin.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">I really don't see any merit to =
this idea. &nbsp;To keep the reply brief, here's three of the larger =
problems I see with it:</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">1. Other schemes will still exist and aren't likely to be =
deprecated. &nbsp;All this proposal is doing is adding one /more/ scheme =
for wallet developers to support. &nbsp;It doesn't make their lives any =
easier.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""></div></blockquote><div><br class=3D""></div><div>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=E2=80=99m not even sure that BIP-21 is =
fully implemented =E2=80=93 which wallets include the req- option for =
example? Most implementations of the Ethereum standards are incomplete, =
and I haven=E2=80=99t 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&nbsp;<a =
href=3D"https://cypherpunk.org/2019/11/02/a-look-at-cryptocurrency-uris/" =
class=3D"">https://cypherpunk.org/2019/11/02/a-look-at-cryptocurrency-uris=
/</a> 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=E2=80=99s 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.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">2. Beyond =
basic payments, these kinds of simple URI scheme aren't going to be =
enough anyway. &nbsp;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. &nbsp;It's just not future-proof, even in the short =
term.</span><br class=3D""></div></blockquote><div><br class=3D""></div>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).<br class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><span style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">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. &nbsp;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.</span><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div><div>I don=E2=80=99t 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.</div><div><br =
class=3D""></div><div>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=E2=80=99m not sure =
it=E2=80=99s 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.</div><div><br class=3D""></div><div>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=E2=80=99m 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.</div><br class=3D""><blockquote=
 type=3D"cite" class=3D""><div class=3D""><span style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">Regards,</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">Ben</span><br class=3D""></div></blockquote><br =
class=3D""></div><div>Thank you,</div><div><br =
class=3D""></div><div>EE</div><br class=3D""><style =
class=3D"">ul[class*=3D'mb-extra__public-links'], =
ul[class*=3D'mb-note__public-links'], ul[class*=3D'mb-task__public-links']=
 { display: none !important; }</style></div></body></html>=

--Apple-Mail=_161F8E97-D0DF-4875-83D0-C5ACB9CDA629--