Return-Path: Received: from smtp2.linuxfoundation.org (smtp2.linux-foundation.org [172.17.192.36]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EC2F8B8F for ; 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 ; 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 ; 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 ; 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 ; Wed, 13 Nov 2019 17:49:14 +0000 (UTC) From: EE 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: To: Bitcoin Protocol Discussion In-Reply-To: Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 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=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--