Join and earn Bitcoin Cash for participation

CashAccounts Report: may2020

9 196
Avatar for JonathanSilverblood
Written by   52
2 weeks ago

Yesterday, I was contacted by a user on discord who was having problems with the Bitcoin.com REST API they were using, and later a developer of a wallet having similar problems. The wallet developer was using a feature of the Bitcoin.com REST API that was not available under the api.cashaccount.info API.

I asked them to file a bug report on gitlab and this morning I pushed out an update to the indexing server that provides the missing functionality and they are now looking into changing what backend they use for their data.

This reminded me that it has been quite a while since the launch of CashAccounts, and so I decided to take a look at some statistics..

Sponsors of JonathanSilverblood
empty

Disclaimer: Not all data is good data.

At first, I just started collecting number and sharing on our discord server, but for this article I wanted to make sure that the data was at least reasonable, so I've decided to exclude the following from the data set as I feel that it severaly skews the statistics in an unreasonable way:

  • bitcoincash: qrdk...3erp (creating one account per block to gather statistics).

  • bitcoincash:qqrr...xy5p (testing and vast majority of names are ytest).

  • bitcoincash:qzvm...w4qs (testing and vast majority of names ate testXX).

  • bitcoincash:qztp...dxe2 (programmatically created and likely test/spam).

  • bitcoincash:qqrw...2ghc (strong outliers with systematic name luckyXX or forumXX).

  • bitcoincash:qpeu...d2ds (strong outliers with systematic name pancakeXX).

  • bitcoincash:qqy9...tgx2 (strong outliers with systematic name ectest).

  • bitcoincash:qz3x...6x7c (strong outliers with systematic name testse).

This list is not exhaustive and I know that there's still a some amount of test/experiment related data include, but I believe we get rid of ~90% of the non-user data this way.

Current usage and how we got here.

accounts    unique_names  unique_payloads
----------  ------------  ---------------
7882        5241          6741

Currently, we have almost 8,000 accounts using a bit over 5,000 unique accounts names and almost 7,000 unique payment information. This means that there is a significant overlap of names and that some users have more than one name for the same payment information. What we can't know though, is how many actual users there are, or how many accounts they each have on average.

week after release  unique_names  unique payloads
------------------  ------------  ---------------
1                   1064          1092           
2                   171           148            
3                   45            52             
4                   21            21             
5                   247           228            
6                   53            45             
7                   43            42             
8                   18            17             
9                   10            11             
10                  5             5           

Looking at the first 10 weeks are release, we can clearly see that there was a lot of early activity but that it tapered off over time, from having more than 1,000 accounts in the first week, to settling down in the tens of accounts per week at the end.

week after release  unique_names  unique payloads
------------------  ------------  ---------------
11                  16            8              
12                  11            11             
13                  141           131            
14                  73            70             
15                  86            84             
16                  129           140            
17                  130           111            
18                  55            58             
19                  167           175            
20                  80            81             

Numbers did pick up in the following 10 weeks, but then settled in and stayed at around 50 registrations per week for the coming 40 weeks:

week after release  unique_names  unique payloads
------------------  ------------  ---------------
21                  48            54             
22                  60            62             
23                  37            32             
24                  34            37             
25                  25            25             
26                  44            45             
27                  42            44             
28                  37            43             
29                  87            106            
30                  50            45             
31                  54            53             
32                  23            31             
33                  29            33             
34                  10            15             
35                  42            49             
36                  54            61             
37                  40            48             
38                  46            52             
39                  25            23             
40                  34            37             
41                  22            24             
42                  31            29             
43                  28            34             
44                  51            59             
45                  38            44             
46                  23            27             
47                  38            45             
48                  41            46             
49                  27            35             
50                  30            36             
51                  63            75             
52                  51            67             
53                  52            63             
54                  37            44             
55                  72            83             
56                  54            57             
57                  58            70             
58                  43            43             
59                  68            74             
60                  64            73             

After 60 weeks since release however, with more wallets opting to automatically create cashaccounts for their users, the number have increased significantly:

week after release  unique_names  unique payloads
------------------  ------------  ---------------
61                  64            80             
62                  80            124            
63                  49            76             
64                  97            113            
65                  577           593            
66                  438           500            
67                  94            147            
68                  97            177            
69                  187           323            
70                  83            134            
71                  98            148            

This shows something that most of us knew from the start, that success of any naming system is going to come down to wallet support, and specifically strong wallet integration.

How has the user experience panned out?

One of the concerns of the CashAccount protocol is that multiple users registering their names at the same time will get longer and longer account identifiers and the value of the system would gradually erode.

Now that we have well over a year worth of data, we can take a look to see how common this is, and how strong of an impact it has had.

accounts    percent     account_collision_count  unique_names  unique_payloads
----------  ----------  -----------------------  ------------  ---------------
354         4.5         2                        186           222            
77          1.0         3                        27            44             
37          0.5         4                        9             28             
35          0.4         5                        8             10             
6           0.1         6                        1             1              
10          0.1         10                       2             4              
18          0.2         17                       2             17             

With a total of around 6.5% of registered accounts having had collisions, it is clear that this is more common than originally anticipated. With such a large number of accounts experiencing degraded quality, it makes sense to quantify how strongly affected they were, which can be seen here:

accounts    percent     account_collision_length  unique_names  unique_payloads
----------  ----------  ------------------------  ------------  ---------------
462         5.9         1                         204           277            
64          0.8         2                         24            43             
9           0.1         3                         5             7              
2           0.0         4                         1             1              

about 5.9% of the accounts need to use a single extra number in order to ensure uniqueness and 0.8% need to use two digits extra. There are a few cases that need to use 3 or 4 digits, but on they seem to be either strong outliers, or testing accounts:

account_collision_length  name_list                      
------------------------  -------------------------------
3                         Jordan,a,test,vikram,toytekin01
4                         aap                            

Based on manual inspection of a bunch of randomly selected cases though, I would say that a large portion of the accounts that have collisions are the result of testing and experimentation and this is consistent with the fact that there has been virtually no user complaints or user support the last year.

There is still room for errors

There has been some failed registrations on the blockchain where the party trying to register an account has properly indicated that they want to register a CashAccount by using the CashAccount protocol identifier, but have then failed to follow the specification.

errors      error_description   
----------  ----------------------
6           Invalid account name
55          Missing payload data
5           Invalid payload length

Based on my communication with wallets working on implementations, I believe practically all of these errors come from the initial development processes and should not be seen as users failing to understand the protocol.

Where do we go from here?

After well over a year of usage I haven't found any significant problem with the CashAccount protocol and I still believe that user experience and user interface is one of the hard problems to overcome in order to gain mainsteam adoption.

To move forward and get CashAccounts more widely used and supported I believe that we need to start asking for it from the wallets we use. When people ask us where they should send us money, tell them your CashAccount identifier as well as your address.

We also need to lower the barriers that wallet developers have and make it easier for them to implement support for it. BitBox with the Bitcoin.com rest API worked great for a while, but what we really need is stronger integration into the infrastructure itself, like BUIP118.

Want to get involved? reach out to me on discord, twitter or just write a comment below.

11
$ 1.82
$ 0.50 from @pchandle
$ 0.50 from @emergent_reasons
$ 0.25 from @Koush
+ 6
Avatar for JonathanSilverblood
Written by   52
2 weeks ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

To move forward and get CashAccounts more widely used and supported I believe that we need to start asking for it from the wallets we use.

@JonathanSilverblood, i agree 100% that implementation into more (or all) wallets would do wonders. am really impressed that Crescent handles this effortlessly..

another thing that Crescent recently added was Re-usable Payment Addresses, which imo would be a game changer for the protocol, as currently its very similar to an Ethereum address, which has ZERO privacy consideration..

i remember taking a look at the Crescent source at some point, but it wasn't clear where this functionality is handled; and ideally I would be looking for a formal spec .. could either you or @pokkst provide some insight (direction) as to how other wallets could go about implementing this??

$ 0.00
1 week ago

The reusable payment code specification (BIP47) is linked to from the cashaccount specification. If that is not enough to understand how it works, then wallet source code or wallet devs for those who have implemented it is pretty much all there's left to go on.

https://github.com/OpenBitcoinPrivacyProject/bips/blob/master/bip-0047.mediawiki

There is also a new specification for the type4 addresses that provides privacy but scales significantly better and has different tradeoffs. I will be updating the spec with a link to it soon.

$ 0.25
1 week ago

There is also a new specification for the type4 addresses that provides privacy but scales significantly better and has different tradeoffs.

thanks for the info! I've read imaginary's spec before, but I didn't realize it had been implemented.

so is type4 what @pokkst is using in Crescent (aka Pokket)? now that there's a wallet that actually uses it, I'd like to support it in causes.cash, just want to make sure I'm implementing the right spec..

$ 0.00
1 week ago

Crescent Cash / Pokket currently uses BIP47 payment codes (type 3 cashaccounts). @pokkst have started to implement type4 as well, but that work is not completed yet.

Note that type4 have been prototyped / partially implemented for Electron Cash and was created to address the shortcomings of type3 - on the long term I believe it is going to be significantly more important.

$ 0.25
1 week ago

Crescent Cash / Pokket currently uses BIP47 payment codes (type 3 cashaccounts).

okay, thanks for confirming..

Note that type4 have been prototyped / partially implemented for Electron Cash

i've been diggin' thru EC's code for weeks now, so that would definitely be my goto as a reference..

thanks again for all info! 😁

$ 0.00
1 week ago

The link to the reusable address spec (not BIP47 payment codes, but type4 address in cashaccounts):

https://github.com/imaginaryusername/Reusable_specs/blob/master/reusable_addresses.md

$ 0.00
1 week ago

Good info, thank you.

$ 0.00
2 weeks ago

This is a good technical applications in solving peoples problems. Though there could still be bugs, but with time and series of corrections they'll be fixed.

$ 0.00
2 weeks ago
About us Rules What is Bitcoin Cash? Roadmap Affiliate program Get sponsored Self-host
hello@read.cash (PGP key) Reddit