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..
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 6741Currently, 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 lengthBased 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.
Good info, thank you.