Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cash Account Integration #1035

Closed
monsterbitar opened this issue Dec 12, 2018 · 13 comments
Closed

Cash Account Integration #1035

monsterbitar opened this issue Dec 12, 2018 · 13 comments

Comments

@monsterbitar
Copy link

@monsterbitar monsterbitar commented Dec 12, 2018

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
Copy link
Collaborator

@cculianu cculianu commented Dec 12, 2018

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
Copy link
Collaborator

@cculianu cculianu commented Dec 12, 2018

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
Copy link
Collaborator

@markblundeberg markblundeberg commented Dec 12, 2018

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
Copy link
Collaborator

@cculianu cculianu commented Dec 12, 2018

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
Copy link
Collaborator

@cculianu cculianu commented Dec 12, 2018

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

@fyookball
Copy link
Collaborator

@fyookball fyookball commented Dec 19, 2018

I support the Cash handles idea

@emergent-reasons
Copy link

@emergent-reasons emergent-reasons commented Feb 9, 2019

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
Copy link

@imaginaryusername imaginaryusername commented Mar 18, 2019

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
Copy link

@emergent-reasons emergent-reasons commented Mar 18, 2019

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

@monsterbitar
Copy link
Author

@monsterbitar monsterbitar commented Mar 22, 2019

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
Copy link
Collaborator

@markblundeberg markblundeberg commented Mar 22, 2019

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
Copy link
Author

@monsterbitar monsterbitar commented Mar 22, 2019

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 added a commit that referenced this issue Jul 8, 2019
Closes #1035 .

The main UI components to it are in:

- **Contacts tab**
- Addresses tab, right click -> Register new.. (to register to a specific address)
- Tools -> Lookup Cash Account
- Receive tab (to register a cash account on the fly to the receive address there in the tab)

What it has:

- *Full verification* -- users are never presented with any results unless they are first SPV verified. They are also warned when a cash account in the contacts tab is no longer verified (due to reorg?) and won't offer it as an option for pay-to.

- Cash Account Registration Auto-Detection™ - Detects cash accounts related to the wallet (that is, registration tx's for the wallet) whenever it "sees" a tx. This can either be a tx that came through the normal wallet "add_transaction" path or if the user explicitly opens a tx, etc.

- The lookup facility is pretty robust and resilient to all sorts of shenanigans.

What it lacks:

- 100% Send tab niceties: Right now the only way to send to a cash account from the send tab is to **first** add it as a contact in the contacts tab.


This last Send Tab bit is a somewhat complex UI flow but I will do it.  I just wanted to get this PR merged in.

As I was working on this I fixed/found/cleaned up a ton of bugs and made the code tighter overall.

This PR includes all of that as well, so I would like to merge it fairly soon and move forward from master with work on Cash Accounts send tab perfection.
@cculianu
Copy link
Collaborator

@cculianu cculianu commented Jul 22, 2019

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 👍

EchterAgo added a commit to EchterAgo/Electron-Cash that referenced this issue Mar 5, 2021
Closes Electron-Cash#1035 .

The main UI components to it are in:

- **Contacts tab**
- Addresses tab, right click -> Register new.. (to register to a specific address)
- Tools -> Lookup Cash Account
- Receive tab (to register a cash account on the fly to the receive address there in the tab)

What it has:

- *Full verification* -- users are never presented with any results unless they are first SPV verified. They are also warned when a cash account in the contacts tab is no longer verified (due to reorg?) and won't offer it as an option for pay-to.

- Cash Account Registration Auto-Detection™ - Detects cash accounts related to the wallet (that is, registration tx's for the wallet) whenever it "sees" a tx. This can either be a tx that came through the normal wallet "add_transaction" path or if the user explicitly opens a tx, etc.

- The lookup facility is pretty robust and resilient to all sorts of shenanigans.

What it lacks:

- 100% Send tab niceties: Right now the only way to send to a cash account from the send tab is to **first** add it as a contact in the contacts tab.

This last Send Tab bit is a somewhat complex UI flow but I will do it.  I just wanted to get this PR merged in.

As I was working on this I fixed/found/cleaned up a ton of bugs and made the code tighter overall.

This PR includes all of that as well, so I would like to merge it fairly soon and move forward from master with work on Cash Accounts send tab perfection.
EchterAgo added a commit to EchterAgo/Electron-Cash that referenced this issue Mar 5, 2021
Closes Electron-Cash#1035 .

The main UI components to it are in:

- **Contacts tab**
- Addresses tab, right click -> Register new.. (to register to a specific address)
- Tools -> Lookup Cash Account
- Receive tab (to register a cash account on the fly to the receive address there in the tab)

What it has:

- *Full verification* -- users are never presented with any results unless they are first SPV verified. They are also warned when a cash account in the contacts tab is no longer verified (due to reorg?) and won't offer it as an option for pay-to.

- Cash Account Registration Auto-Detection™ - Detects cash accounts related to the wallet (that is, registration tx's for the wallet) whenever it "sees" a tx. This can either be a tx that came through the normal wallet "add_transaction" path or if the user explicitly opens a tx, etc.

- The lookup facility is pretty robust and resilient to all sorts of shenanigans.

What it lacks:

- 100% Send tab niceties: Right now the only way to send to a cash account from the send tab is to **first** add it as a contact in the contacts tab.

This last Send Tab bit is a somewhat complex UI flow but I will do it.  I just wanted to get this PR merged in.

As I was working on this I fixed/found/cleaned up a ton of bugs and made the code tighter overall.

This PR includes all of that as well, so I would like to merge it fairly soon and move forward from master with work on Cash Accounts send tab perfection.

includes changes from:

Electron-Cash@e48749a
Electron-Cash@abf8ce3
EchterAgo added a commit to EchterAgo/Electron-Cash that referenced this issue Mar 5, 2021
Closes Electron-Cash#1035 .

The main UI components to it are in:

- **Contacts tab**
- Addresses tab, right click -> Register new.. (to register to a specific address)
- Tools -> Lookup Cash Account
- Receive tab (to register a cash account on the fly to the receive address there in the tab)

What it has:

- *Full verification* -- users are never presented with any results unless they are first SPV verified. They are also warned when a cash account in the contacts tab is no longer verified (due to reorg?) and won't offer it as an option for pay-to.

- Cash Account Registration Auto-Detection™ - Detects cash accounts related to the wallet (that is, registration tx's for the wallet) whenever it "sees" a tx. This can either be a tx that came through the normal wallet "add_transaction" path or if the user explicitly opens a tx, etc.

- The lookup facility is pretty robust and resilient to all sorts of shenanigans.

What it lacks:

- 100% Send tab niceties: Right now the only way to send to a cash account from the send tab is to **first** add it as a contact in the contacts tab.

This last Send Tab bit is a somewhat complex UI flow but I will do it.  I just wanted to get this PR merged in.

As I was working on this I fixed/found/cleaned up a ton of bugs and made the code tighter overall.

This PR includes all of that as well, so I would like to merge it fairly soon and move forward from master with work on Cash Accounts send tab perfection.

includes changes from:

Electron-Cash@e48749a
Electron-Cash@abf8ce3
EchterAgo added a commit to EchterAgo/Electron-Cash that referenced this issue Mar 5, 2021
Closes Electron-Cash#1035 .

The main UI components to it are in:

- **Contacts tab**
- Addresses tab, right click -> Register new.. (to register to a specific address)
- Tools -> Lookup Cash Account
- Receive tab (to register a cash account on the fly to the receive address there in the tab)

What it has:

- *Full verification* -- users are never presented with any results unless they are first SPV verified. They are also warned when a cash account in the contacts tab is no longer verified (due to reorg?) and won't offer it as an option for pay-to.

- Cash Account Registration Auto-Detection™ - Detects cash accounts related to the wallet (that is, registration tx's for the wallet) whenever it "sees" a tx. This can either be a tx that came through the normal wallet "add_transaction" path or if the user explicitly opens a tx, etc.

- The lookup facility is pretty robust and resilient to all sorts of shenanigans.

What it lacks:

- 100% Send tab niceties: Right now the only way to send to a cash account from the send tab is to **first** add it as a contact in the contacts tab.

This last Send Tab bit is a somewhat complex UI flow but I will do it.  I just wanted to get this PR merged in.

As I was working on this I fixed/found/cleaned up a ton of bugs and made the code tighter overall.

This PR includes all of that as well, so I would like to merge it fairly soon and move forward from master with work on Cash Accounts send tab perfection.

includes changes from:

Electron-Cash@e48749a
Electron-Cash@abf8ce3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
@cculianu @fyookball @monsterbitar @emergent-reasons @imaginaryusername @markblundeberg and others