Ben, Thank you for your comments. Let me take a stab.
> On 13 Nov 2019, at 10:52 AM, Ben Dewaal <[email protected]> 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
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
