BUIP119: (passed) Implement sending to CashAccount

[Jonathan Silverblood]

BUIP119: Implement sending to CashAccount
Submitted by: Jonathan Silverblood
Date: 2019/03/30

Summary
The purpose of this BUIP is to build native support for sending to CashAccounts in Bitcoin Unlimited's node software. This means that in places where the user can normally enter a Bitcoin Cash address, entering a CashAccount should be supported.

Proposal
This BUIP proposes that we use bitcoin unlimited funds to:

• Add code that parses and recognize when a user has entered a CashAccount
• Add code that looks up and uses the payment data in a CashAccount

Motivation
There already exist a few wallets that support sending to Cash Accounts, and having a consistent and user friendly means to enter who we want to send money to is one of the main pain points for adoption. Adding support in Bitcoin Unlimited helps bring unity across the ecosystem.

Background
Cash Accounts is a protocol for on-chain name-to-payment data, and allows sending money over the Bitcoin Cash network to be less technical and more humane.

Links

• Website: https://www.cashaccount.info/
• Specification: https://gitlab.com/cash-accounts/specification/blob/master/SPECIFICATION.md
• Test data: https://gitlab.com/cash-accounts/specification/blob/master/TEST.md

 

[imaginary_username]

While the vast majority of BCH runs on light wallets, this is not a bad call - given the slower moving nature of full node wallets, though should this be implemented after reusable addresses are in place? Or will that take too long?

 

[Jonathan Silverblood]

I think registration of accounts should be held off for now, until we either have working reusable addresses, or at least have more information and know what to expect.

Being able to send to those that voluntarily choose to use key/script hashes and the loss of privacy that comes with them, I think is a good thing. It also reduces the amount of work that needs to be done when reusable addresses do come and we got stronger adoption.

 

[Roy Badami]

I'd really like to see CashAccount addresses enhanced with some kind of check digits before we start pushing it heavily.

 

[Jonathan Silverblood]

What purpose do you think such check digits would serve?

 

[Roy Badami]

To ensure that mistranscription of a CashAccount address will not result in misdirected funds. This seems to me to be important in any cryptocurrency addressing scheme, given the irreversability of transactions.

Or am I missing some reason why this is not expected to be a concern in normal use?

 

[Jonathan Silverblood]

I understand your concern in theory, but I am not worried about it in practice.

My reasoning is that while it is **very** easy to do mistranscription of a non-meaningful technical address, it is significantly less likely with a meaningful name. Further, it is much more likely to mistranscibe a long technical address than a short identifier.

Then there exist a misentry prevention scheme in the protocol in the form of the emojis that act like confirmation upon correct entry.

So let's look at from a probability perspective.

Here's my identifier: ☯ jonathan#100;

IF you were to misentry it by a single letter in the name, the changes that you would find another valid account is 0% (because the block is mined and there is no other accounts matching such a change in that block).

IF we assume I registered at a high peark after the system has scaled however,it might well be possible that there would be other names that would match the 1-change letter example, but the changes of changing any 1 **random** letter and finding a match should still be fairly low.

If you were to misspell 1 letter in the number, the chances of finding a valid account is also 0% today, but at scale would be the more dangerous misentry case as I'd expect some common names to be registered quite often.

Assume for calculations sake that the worst-case (after full-scale deployment) that there's a significant chance of something like 25% that you could find a valid different account by mistyping your entry - then when that 25% happen, there is a 1% chance that the other account has the same emoji, making the false-positive rate something like 0.25% for misentry.

Now, this rate will be the highest for short, common names (which coincides with those least likely for people to misspell in the first place) and lowest for those with long unique names that doesn't get registered often enough to create a significant collision space.

Now, worst comes to worst, money **does** get permanently sent to the wrong place, and that is bad, but let's not have perfection be the enemy of good here: we are trying to solve the issue of userfriendly non-squattable identifiers in a network.

I think CashAccounts have done a fairly good job trying to balance the https://en.wikipedia.org/wiki/Zooko's_triangle and should either be embraced - or rejected - en-mass across the ecosystem.

The worst outcome for the end-user is "sometimes works, sometimes not".

 

[Roy Badami]

Sorry for the delayed response. I think in my mind it boils down to the fact that if you give users an opportunity to make mistakes, they will; and if you give people an opportunity to profit from other people's mistakes, they will take it.

Let me tell you a story: in the 90's US telephone company AT&T offered a service on the phone number 1-800-OPERATOR. (In the US it's common to advertise phone numbers in this way, using the letters that appear on the telephone keypad.) In response, rival telephone company MCI registered the telephone number corresponding to 1-800-OPERATER, capitalising on the fact that many people are not good at spelling. By all accounts this turned out to be a shrewd business move on MCI's part, and they got many customers calling them on this number.

I would imagine that, under adversarial conditions, the moment the registration for jonathan#100 had been broadcast, it would have been followed by registrations for johnathan#100 and jonathon#100 etc trying to mop up funds sent to mis-spellings. If your handle had been jonathan#145 then I imagine someone would have gone ahead and registered in block 154 to try and mop up any typos there, too. We see people play these kinds of games with domain names; it seems hard to believe this won't happen with CashAccount, too - assuming there is significant adoption.

I confess that when I posted my previous response I had forgotten about the emoji check. I guess it all depends on how well that works in practice. I'm afraid I'm skeptical. Even assuming it is widely implemented, it remains to be seen how consistently payees actually include this non-ASCII element when communicating their handle, and how well understood the use of the emoji is by payers. Personally, if it were my design, I would achieve the desired 1% chance of lost funds due to mistyped addresses by appending a slash and two decimal digits, so the software can reject a mismatch without any action or understanding required by payee and payer.

When all is said and done, though, I'm not dead set against the current design. Maybe my fears will turn out to be unfounded. Everything in crypto is basically a grand experiment, and I certainly agree that we should avoid making the perfect the enemy of the good.

roy