Cash Account Integration

[monsterbitar]

I am currently working on a specification for on-chain aliases that look like this: James#577821; to help convey payment information in a more convenient manner, particulary in verbal contexts.

The specification has undergone reasonable peer-review so far (by wallet developers, token developers, coinbase engineeers) but more feedback is always welcome.

Here's a link to the draft spec: https://gitlab.com/cash-accounts/specification/blob/master/SPECIFICATION.md

[cculianu]

I think this is a great idea. I looked quickly at the spec and it's pretty simple and solid (simple is the best, quite often). Thanks for posting this.

I would like EC to support this when it's finalized at some point.

[cculianu]

It would probably need ElectrumX server-side support to be able to refer to people by the short-hand notation.. I think. And to also be able to do reverse lookups of Address -> Label (short or long).

Not a huge deal -- i think the ecosystem needs this. It's 1 step towards easier, more human friendly adoption.

[markblundeberg]

I love the protocol but I'm also not hot on the 'account' terminology. Too easy to misunderstand for normal folks, since bitcoin doesn't have accounts. 'Cash Nick' was an option in your poll, wasn't it?

@cculianu why would reverse lookups be needed, I'm curious? (they wouldn't be unique in general, especially not if I register the same address multiple times)

[cculianu]

Hmm. Yeah "Account" could be misleading since it has baggage as a term in that it means something else in other domains. Whereas a new term like "Cash Nick" that has no baggage might be ideal.

[cculianu]

Oh hey @markblundeberg that second message about ledgers ended up in the wrong issue. Ha ha. I didn't mean it!

[fyookball]

I support the Cash handles idea

[emergent-reasons]

FYI pycashaccount now has reasonably well tested python code for making cash account op return data for p2pkh, p2sh and bip47 payment codes. Anyone working on this issue is welcome to use the library or the code itself.

[imaginaryusername]

It seems prudent to make EC at least pay to cashaccounts now that we have at least two lookup servers at api.cashaccount.info (https://api.cashaccount.info/lookup/100/jonathan and https://api.cashaccount.info/account/100/jonathan) as well as cashacct.imaginary.cash ( try https://cashacct.imaginary.cash/account/100/im_uname ). I wonder if the ifwallet guys would open up their server so we can get a 2-of-3 going - but in the meantime I'd say a 2-of-2 might be good enough as a starting point.

[emergent-reasons]

I also added a big pile of validation / test data for any implementation to work against.

[monsterbitar]

We are now several months into this project, there exist multiple lookup servers (written in javascript, go and c#), there exist a handful of websites around it and a small number of wallets have implemented send-support.

The main issue that is still left to be resolved is creating and agreeing on a resuable address format so that we can retain privacy while still having userfriendly names, but I still feel that implementing sending support is something that should be a higher priority.

I understand if you'd be hestitant to implementing registration support at the time being, given that address reuse is a bad practice - but ematiu from copay is working together with others to create a standardized implementation of peter todds stealth addresses that would allow us to keep the privacy.

Please do not pass up this opportunity to build the user interfaces and send-support so that the electron cash wallet can be ready when the registration support gets implemented elsewhere.

[markblundeberg]

Since Electron Cash has an address book, I think the easiest first step would be to let users to perform cash account lookup and use it to pre-populate an add-entry form for their address book.

Long-term it's probably a good way anyway to use address book. No sense in having users do a server lookup every time they send money to same person ("was it 564 or 654?"), and they can also attach the contextual data that they feel is important rather than relying completely on the frozen on-chain data.

[monsterbitar]

I agree wholeheartedly on the addressbook perspective, just remember to store the account identifier as well, should the situation ever arise where a user wants to share the information with a friend. Best setup I guess is to store the account identifier, parsed payment data and transaction ID so that it can be validated again in the future is needed.

[cculianu]

I agree wholeheartedly on the addressbook perspective, just remember to store the account identifier as well, should the situation ever arise where a user wants to share the information with a friend. Best setup I guess is to store the account identifier, parsed payment data and transaction ID so that it can be validated again in the future is needed.

Sorry didn't reply here. Yes, we do this now 👍