@JonathanSilverblood 16 May 2020

CashAccounts Report: may2020

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] 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. https://bitco.in/forum/threads/buip118-passed-implement-cashaccount-lookup-features.23749/ *Want to get involved? reach out to me on* *discord**,* *twitter* *or just write a comment below.* https://discord.gg/9kACN9t https://twitter.com/monsterbitar