BUIP118: (passed) Implement CashAccount lookup features

Jonathan Silverblood

Active Member
Nov 21, 2018
100
73
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
 
Last edited:

imaginary_username

Active Member
Aug 19, 2015
101
174
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

Active Member
Nov 21, 2018
100
73
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

Active Member
Nov 21, 2018
100
73
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.
 
  • Like
Reactions: imaginary_username

Jonathan Silverblood

Active Member
Nov 21, 2018
100
73
@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

Active Member
Jun 5, 2017
188
157
Thanks for the added link. A reference implementation was what i was looking for. I will take a look
 

Roy Badami

Active Member
Dec 27, 2015
140
203
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

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@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

Active Member
Nov 21, 2018
100
73
@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

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@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.