It has been a year since I followed up on the adoption metrics for the CashAccounts payment aliasing protocol that stores your data on the Bitcoin Cash blockchain.
While there hasn't been any significant recent developments, and users continue to ask on places like twitter and reddit as to why wallet developers haven't adopted the functionality yet, adoption continues to move and shows now signs of slowing down.
Disclaimer: Not all data is good data.
Like last years report, I've decided to exclude the some data that I feel severaly skews the statistics in an unreasonable ways:
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).baby636 (spammy nature across BCH ecosystem)
BABY636 (spammy nature across BCH ecosystem)
BitcoinCash (variation of Bitcoin)
Bitcoincash (variation of Bitcoin)
bitcoincash (variation of Bitcoin)
Bitcoin (variation of Bitcoin)
bch (variation of Bitcoin)
BCH (variation of Bitcoin)
Test (testing oriented name)
test (testing oriented name)
test2 (testing oriented name)
a (testing oriented name)
CashAccount (variation of CashAccount)
Cashaccount (variation of CashAccount)
cashaccount (variation of CashAccount)
50000 (numerical repetition)
30000 (numerical repetition)
25000 (numerical repetition)
20000 (numerical repetition)
10000 (numerical repetition)
5000 (numerical repetition)
4000 (numerical repetition)
3000 (numerical repetition)
2000 (numerical repetition)
1000 (numerical repetition)
500 (numerical repetition)
100 (numerical repetition)
50 (numerical repetition)
20 (numerical repetition)
10 (numerical repetition)
7 (numerical repetition)
5 (numerical repetition)
1 (numerical repetition)
0 (numerical repetition)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 comparison to last year
year accounts unique_names unique_payloads
---------- ---------- ------------ ---------------
2020: 7882 5241 6741
2021: 19418 12574 17435 We now have almost 20,000 accounts with about 17500 unique payloads. There has been some growth (+146%) over the year as the adoption rate continues to increase. As always, we can't know how many actual users there are or how many accounts they have on average.
week after release unique_names unique payloads
------------------ ------------ ---------------
1 1064 1092 The fastest growing week since inception is still the very release week, but on week 90 we hit 970 unique payloads, which is getting close to the same level as the release week.
Looking at the state of the system at the end of the previous report, after the first wallets opted to automatically create cashaccounts for their users, we can see that average new paylods per week is about 220 per week:
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 Looking at the following 42 weeks, we can see a clear growth and only fell back under 100 per week at two occasions:
week after release unique_names unique payloads
------------------ ------------ ---------------
72 199 254
73 118 162
74 468 496
75 74 107
76 428 483
77 88 143
78 135 186
79 171 216
80 233 290
81 126 172
82 107 161
83 428 504
84 148 221
85 143 218
86 168 237
87 160 217
88 132 171
89 355 397
90 924 970
91 219 234
92 331 362
93 159 187
94 94 124
95 114 155
96 113 146
97 129 152
98 155 260
99 163 214
100 61 110
101 39 72
102 64 105
103 55 95
104 77 138
105 99 178
106 80 141
107 156 284
108 180 340
109 353 679
110 138 229
111 127 205
112 267 508
113 314 606
114 252 488 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 yet another 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
-------- ------- ----------------------- ------------ ---------------
653 3.4 2 273 371
116 0.6 3 38 53
48 0.2 4 10 25
45 0.2 5 8 12
6 0.0 6 1 1
10 0.1 10 2 4
1 0.0 17 1 1 With a total of around 4.5% of registered accounts having had collisions, it now looks better than the 6.5% measured last year, but that might come down to better filtering of systematic, spammy and testing accounts. Regardless, we should quantify how strongly affected the accounts were by the collision mechanic:
accounts percent account_collision_length unique_names unique_payloads
-------- ------- ------------------------ ------------ ---------------
758 3.9 1 298 406
105 0.5 2 39 64
14 0.1 3 6 10
2 0.0 4 1 1 about 3.9% of the accounts need to use a single extra number in order to ensure uniqueness and 0.5% need to use two digits extra. The system appears to be working as predicted, which is consistent with the fact that there still hasn't been any user complaints or user support requests on this matter the last year.
What about the error rate?
At the start of the system, there was 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. In the last year, this statistic has not changed as not a single failed registration has been detected since.
Where do we go from here?
With the protocol having been live for years now, I have found that it's convenient to use for the cases where it works out, but that wallet support is still abysmall. Reusable Private Addresses is still being worked on which would allow CashAccounts to function with reasonable privacy.
To get this system used more, what is needed now is probably a matter of user demand. If you are a user, go ask your wallet of choice to support the aliasing scheme you prefer.
If you are a developer, consider providing extra quality to your users - CashAccounts is a very easy to pick up protocol and it should only take you a few days to get it integrated from a technical standpoint.
Want to get involved? reach out to me on discord, twitter or just write a comment below.
Actual site is https://www.cashaccount.info/
(after trying ER's suggestion below and finding it doesn't work)