BUIP118: (passed) Implement CashAccount lookup features

[Jonathan Silverblood]

BUIP118: Implement CashAccount lookup features
Submitted by: Jonathan Silverblood
Date: 2019/03/30

Summary
The purpose of this BUIP is to build native support for CashAccounts in Bitcoin Unlimited's node software. The support includes a registry of established accounts and their payment data and a public API for querying this data from wallets.

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

• Add code that manages a registry of CashAccounts
• Add code that allows wallets to query for CashAccount registrations.
• Add configuration settings to enable/disable public API for wallets.
• Add configuration settings to enable/disable CashAccount management.

Motivation
While there already exist several different CashAccount lookup server implementations already, having a strong redundancy in terms of lookup nodes helps build resilience against various denial of service attacks. Having a CashAccount lookup server built into Bitcoin Unlimited pretty much guarantees that there will always be enough lookup servers in the wild. It also makes it easier to add support for sending to CashAccounts in the wallet as well.

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
• Official lookup server source: https://gitlab.com/cash-accounts/lookup-server/tree/master

 

[imaginary_username]

This will massively increase the robustness of Cashaccounts. One consideration: since an index will need to be built and ideally node operators should be burdened with as few rebuilds as possible, would it be better to index data generally (a la bitdb), a select few "bundled" ( for example, SLPdb and Cashaccount), or separately?

 

[Jonathan Silverblood]

If it's favourable to build the index so that one can make a list of protocol identifiers to enable indexing for, I guess it would be good to build it that way.

I don't know the intricate details of SLP though, so someone else needs to chime in and help me come to a good conclusion on what best way to do this though - or I will leave as is and it will be up to the developer who implements to to choose how to do it.

 

[Jonathan Silverblood]

For clarity, I think these should be set to disabled by default, and be configurable at compile time. The released binaries should probably include the features even if they're turned off, otherwise people can't turn them on without compiling from source.

 

[Griffith]

for easier reference can you add a link to the expected API to be included.

 

[Jonathan Silverblood]

@Griffith While the expected API structure is listed in the specification, in a vague form, an example of an implementation that is used in practice today and that several implementations already adhere to has been added as a link to the gitlab source repository for it.

 

[Griffith]

Thanks for the added link. A reference implementation was what i was looking for. I will take a look

 

[dagurval]

I am working on integrating an electrum server with the Bitcoin Unlimited node software. The thought has earlier crossed my mind that adding a cashaddr index to this server makes sense, as electrum clients could query for cashaddr handles. The server could also provide proof of the transaction that created the handle.

 

[imaginary_username]

@dagurval I do not know that is already going on! Is this based on Electrumx specification 1.4?

 

[Roy Badami]

As I mentioned in the other CashAccounts BUIP, I'd really like to see CashAccount addresses enhanced with some kind of check digits before we start pushing it heavily.

 

[solex]

@Jonathan Silverblood
Please advise when you think your development BUIPs have had such sufficient revision that you would like to bring them forward for voting.

 

[Jonathan Silverblood]

@solex I am new to writing BUIPs and while I've read the articles of federation more times than I'd normally would in any other organization ('cause, drama? -.-), I still feel unsure about their form and what revisions would be needed or not to make them valid, useable proposals.

If they are already written in a shape that they're eligable as BUIPs, then please consider all of them as "ready for voting".

 

[solex]

@Jonathan Silverblood
Thank you. The content of BUIPs is meant to be pitched at a high enough level where the thrust of the change is clear to all members, which these meet. I will include them now and welcome any final feedback from @theZerg, especially if he considers any requires further revision before the 20th.