Version 0.

1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

A Mechanism for a Bitcoin Web Service to Prove that it is not Running a Fractional Reserve System
A Whitepaper and Recommendation for Trustworthy Bitcoin Web Services

Abstract
Many Bitcoin related web services, like Bitcoin exchanges, online wallets and many others, allow their users to open accounts and store Bitcoins with them. The question arises whether these web services always own all the funds that users have deposited, or whether they have withdrawn (i.e. embezzled) some user funds for other purposes like investment, speculation or straight fraud. Such unauthorized withdrawal of a certain percentage of the user funds would remain undiscovered as long as the users keep their funds with the web service. However, as soon as they start to withdraw their funds at large scale, the fraud would become evident. This paper suggests a mechanism by which a Bitcoin-based web service can prove at regular intervals that it is still in possession of all user funds (=Bitcoins) - a monthly interval is recommended. Thereby, such web services can provide substantial trust and credible security to their clients and can get a significant competitive advantage over similar web services not implementing that mechanism. In the long run it is desired that the outlined mechanism becomes a quasi-standard amongst all reputable Bitcoin web service providers that hold user accounts with Bitcoin funds.

Bitcoin donations welcome:

14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR

[1 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

1. The Working Principle

We consider a web service provider, shortly referred to as provider, who offers user accounts that can be funded with Bitcoins. While each user can log-in to his/her private account to view the own Bitcoin balance at any point in time, the provider publishes a list of funds of each user (readable by the open public) e.g. at http://your-bitcoin-webservice.org/bitcoin_fundlist.txt at regular intervals. In the following we will assume an update of this list on every first Sunday of the month at 03:00 am GMT as best practice example. We will refer to this date as the publication date/publication time (the publication interval will hence be 4 or 5 weeks here), and we will refer to this published list of funds as the publication file. The publication file comprises a list of all user names with their respective balances, as of 02:00 am GMT (=one hour before the publication time), and the sum of all these individual user balances. It further discloses a short list of Bitcoin addresses (preferable 1 to 10 addresses) that together contain these user funds as of Sunday 03:00 am (publication time). Plain text format of the publication file is recommended to ease parsing by automated scripts. The publication file bitcoin_fundlist.txt would look like this, here assuming for simplicity that there exist only four user accounts:
================================================================= your-bitcoin-webservice.org --------------------------Our funds acc. to blockchain, as of Sun 5 May 2013, 03:00 am GMT: Bitcoin Address Balance (A) 1AB2Cde3fGHjk4LMno5PQ6RsT7UV8Wx9yz 201.12345678 BTC (B) 1Xyz262mnb3463zuiopqfsb5783576d352 54.22990000 BTC (C) 1qwertyasdfgzxcvb12345HJKLuiopBNM 109.88888888 BTC ----------------------------------------------------------------Total Website Funds: 365.24220000 BTC ================================================================= Our users' funds as of Sun 5 May 2013, 02:00 pm GMT: Username Balance * alphaBuilder 71.06760005 BTC * penguin1971 100.00000000 BTC * redNora91 188.45336900 BTC * teadrinker 5.72127870 BTC ----------------------------------------------------------------Total User Funds: 365.24220000 BTC ================================================================= Next publication date: Sun 2 Jun 2013, 03:00 GMT.

Bitcoin donations welcome:

14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR

[2 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

Every registered user can verify integrity of the web service provider by checking the following questions. The provider is only trustworthy if all questions can be answered with yes: (1) Is my user name listed in the publication file and is the indicated balance exactly correct (not too low and not to high)? (2) Do the individual users' balances add up to no more than the website's funds? (3) Do the published Bitcoin addresses show the indicated balance as of the indicated date, acc. to the public blockchain/blockexplorer? In this way, the provider proves to his users that he is trustworthy and is not running on fractional reserves. FAQs: Q.: It is clear that a user's balance displayed in the publication file should not show a lower value than the actual balance. But why is it also important that the published balance is not higher than the user's actual balance? A.: Because otherwise the provider could assign two users the same user name, list this user name only once in the publication file and associate it with the higher of the two balances of these users, thereby running a fractional reserve system by not publishing the actual balance of one of the users. Q.: Why is there a 1 hour difference between the two reference times in the example above? A.: A user may deposit Bitcoins to his account (to his individual address, unequal to (A), (B) or (C)) at 2:55 am on 5 May 2013. These Bitcoins yet need to be transferred to one of the public addresses (A), (B) or (C), but this cannot be achieved by 3:00 am due to the Bitcoin block generation speed. Hence, the published list cannot include his latest funds as of 3:00 am. Hence, the published list shall reflect the user funds as of 1 hour back in time. Note that the web service provider could theoretically run a fractional reserve system by the amount that users fund their accounts between 2:00 and 3:00 am. However, practically this cannot be exploited, since the amount of inflows within this short time interval is expected to be very low and anyway unpredictable. Q.: What if many users withdraw a lot of funds between 2:00 and 3:00 am? The web service provider would then run out of reserves, since he must prove that he owns at 3:00 am as many Bitcoins as the user base owned 1 hour before. A.: The service provider should therefore establish a service&maintenance window one hour before the publication time (here from 2:00 to 3:00 am) during which Bitcoin withdrawals by the users are disabled or limited. This is expected to be of limited annoyance for the users as it only happens for a 1 hour period every few weeks and is perfectly predictable. Alternatively, the web provider may slightly OVERFUND his reserves, thereby allowing the users to perform withdrawals even during one hour before the publication time. Then, only in the unlikely event that the sum of withdrawals within this short time window exceeds the overfundings, the provider has to temporarily reject a withdrawal for some users for a short time (max. 1 hour). Yet another alternative is that the next publication time is not fixed exactly by the minute, but instead specified to occur within a limited [max. 24 hours] time interval. This may allow the provider to slightly delay the originally intended publication time in case that there are more fund withdrawals than expected during a certain one hour period. This would further reduce the likelihood that fund withdrawals have to be rejected for a certain user on the publication day. Q.: What if not all users check the publication file for their own balance every time (question (1) above)? In this case the web provider may state a too low balance for these users and will get away with it, because only this user can check if the published balance is correct. So the provider can still run a fractional reserve system.
Bitcoin donations welcome: 14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR [3 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

A.: Theoretically true, but practically this cannot be exploited by the provider without running enormous risk of getting exposed and loosing trust, because the provider does not know in advance when which user will or will not check the balances of the publication file. The provider could only hope that the user whose balance he intentionally understates in the publication file, will not check it. If this user however does check the balance, the provider is exposed to having stated wrong numbers and is subject to suspicion of running on fractional reserves. Q.: How can I know that the stated Bitcoin addresses in the published list are really owned by this web provider and not anybody else? And how can I know that these addresses are not shared (reused) with another web provider that is possibly owned by the same company? A.: The solution for this is given in chapter 4. Q.: Is there any example of a company that applies a scheme like this already today? A.: Yes, the company BullionVault.com in London enables people to buy real physical gold that is deposited in vaults . Unlike ETFs or certificates, BullionVault sells real gold to their clients, and not only paper gold. To prove ownership of physical gold, BullionVault regularily publishes: Certificates proving ownership of a given amount of gold bullions with bullion numbers, and A complete list of all account owners (identified by a secret name, not the login name) with their respective gold shares. The former corresponds to the Bitcoin addresses (A), (B) and (C) in the publication file, whereas the latter corresponds to the list of secret user names and associated Bitcoin balances.

2. Adding Anonymity: Secret User Name for Publication

Depending on the kind of web service that the provider is running, the user name may be known to other users that the user is interacting with. In this case, it is not desired that the publicly known user name is listed in the publication file. The solution to this problem is very easy: Every user, upon first login, is mandated to create a secret user name. This name has the sole purpose of being listed in the publication file as a secret alias for this user account. This user name, or alias, is secret in that only the user him/herself knows it, while it is publicly listed in the publication file. Hence it is secret and public at the same time. Nobody can associate the secret user name with the real identity (or public user name or login name) of the user. Furthermore, the user is allowed to change his/her secret user name at any time, such that another alias (=secret user name) will then show up in the publication file. The web platform has to make sure that not any two users choose the same secret user name, and should demand that it is sufficiently different from the publicly visible user name. It is also strongly recommended that no secret user name is identical to the public name/login name of another user, to avoid unnecessary confusion of users when reading the publication file.

3. Improving Anonymity: Obfuscation of Identity

For many web services, anonymity is served sufficiently by introduction of the secret user name, as described in the previous chapter. However, for certain kinds of Bitcoin web services it may happen that a user's identity gets disclosed from the publication file even if his/her identity is hidden by the secret user name. For example, one such web service could be a Bitcoin online wallet were users are enabled to send Bitcoins directly to
Bitcoin donations welcome: 14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR [4 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

each other within the platform (i.e. without using the bitcoin network), by just specifying the public user name where to send the Bitcoins to. A concrete example of an identity disclosure attack is the following: We consider User A (the attacker) and User V (the victim). User A sends 1.23456789 Bitcoins to User V , or User A receives 1.23456789 Bitcoins from User V for a certain service that he provided to him. At the next publication date, User A reads the publication file and compares it with the last publication (from 4 or 5 weeks ago in our example). If he is lucky, User V is not a very active user on this platform and this was the only transaction of User V during the last publication interval. In this case, User A can simply compare all balances of all users in the publication file, and when he finds one secret user name who's balance has changed by exactly 1.23456789 Bitcoins, he has disclosed the secret name of User V with high probability. Here is a defense mechanisms that the provider can offer to his users to prevent such identity disclosures via the publication file: The users are enabled to specify not just one secret user name, but several (e.g. two or three). In the next publication file, the user's balance will be split between the different secret user names that all belong to the same user. The split ratio could be set by the user in the account settings and could be modified, within certain limits, by a random function from one publication date to the next. Note that also negative balances could be shown for a secret user name, if the user decides for a corresponding balance split between the secret user names. For example, assume that a user has a balance of 3 Bitcoins and has defined three secret user names s1, s2 and s3 with a split ratio of s1 : s2 : s3 = 50% : +20% : +130% (must always add up to 100%). In this case, his/her part of the balance in the publication file would appear as:
Username s1 s2 s3 Balance -1.50000000 BTC 0.60000000 BTC 3.90000000 BTC

Next publication date, if the balance is still 3 Bitcoins and the split has changed to s1 : s2 : s3 = 23% : +67% : +56%, the following balances get published:
Username s1 s2 s3 Balance -0.69000000 BTC 2.01000000 BTC 1.68000000 BTC

4. Prove of Exclusive Ownership of Bitcoin Addresses

Acc. to chapter 1, the web service provider discloses his own Bitcoin addresses in the publication file that contain the total balance of funds he is administering for his users. To be really trustworthy, the provider needs to prove two things: (1) Prove that he actually owns the keys (2) Prove that he uses them exclusively, i.e. prove that there is no other Bitcoin web service that uses the same keys for the same purpose (which would enable running a 50% fractional reserve system if the users of one service don't know of the other service's existence) The first requirement can be satisfied if the provider announces the Bitcoin addresses (A), (B), (C) ..., that will be used for the next publication time, well in advance. The second requirement can be met if the Bitcoin addresses are a function of something that is unique to this particular web service (preferably the web domain name is the most unique characteristics) and therefore cannot be re-used easily by another web service.
Bitcoin donations welcome: 14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR [5 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

Further trust can be established if, on top of that, the new Bitcoin addresses are a function of a future event that cannot be predicted but whose outcome can be checked easily by everyone. This future event is in our example the transaction fees of a certain future block number in the Bitcoin block chain. This block should be created a few days after the publication file's publication time (5 May 2013 in our example), but also well before the next publication date (2 Jun 2013). We recommend to use block number n+500, where n is the block number at current publication time. 500 Blocks corresponds to roughly 3.5 days. To get a concrete idea, it is recommended that the publication file (compare chapter 1) includes the following text (In this example we assume that the block number at current publication time, 5 May 2013, 3:00 GMT, is equal to 234000):
Next publication date will be Sun 2 Jun 2013, 03:00 GMT. Our next Bitcoin Addresses will be a function * of our current Bitcoin Adresses (A), (B), (C), see above, * of our domain name (your-bitcoin-webservice.org), and * of the transaction fees of block 234500 in the Bitcoin blockchain (expected 8 May 2013, ca. 2:20 pm GMT) Calculation will be as follows, here shown for address (A): 1.) We form a string that is the concatenation of these three substrings: substr1=1AB2Cde3fGHjk4LMno5PQ6RsT7UV8Wx9yz # address (A) from above substr2=your-bitcoin-webservice.org substr3=0.12345080 (Example! Replaced by the actual transaction fees of block 234500, writing out all 8 digits after the comma) totalstring=$substr1$substr2$substr3 # concatenation, Linux bash syntax

2.) We calculate the md5 hash from that string: echo -n $totalstring | md5sum # Linux bash syntax 2a0e721fce4d1c54b3c2dae1f2a605d0 # All letters are lower case! 3.) We turn the hash into base58 alphabet by replacing 0 (zero) with 1 (one): 2a1e721fce4d1c54b3c2dae1f2a615d1 4.) We extract the first four digits from this string and add the pre-fix 1 (one): 12a1e 5.) We will generate a random Bitcoin address starting (A) 12a1e............................. At latest 1 week after the block chain has reached full Bitcoin addresses to be published in the next be disclosed at this place. The addresses are: <to with these characters: block 234500, our publication file will be indicated here!>

Bitcoin donations welcome:

14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR

[6 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

5. Checklist for Trustworthiness

We summarize important points that serve as a checklist for clients to find out if their provider is credible in his attempt to prove that he is not running a fractional reserve system: To be credible, the provider must comply to all these points: Every user is mandated to create at least one secret user name of his own choice, before he is able to transfer any Bitcoins to his account. It is important that the provider does NOT suggest any default secret user name to the user! The user must not be influenced in his choice of the secret user name in a way that may enable the provider to assign the same secret name to many different users. The provider shall ask the user to choose secret user names that are unlikely to be used by other users, and the provider's web server shall still check and reject any secret user name that is already existing for another user (be it as a public or secret user name or login name). If users are allowed to create several secret user names, the split ratio (ref. ch. 3) shall be defined by the user. (The user may get enabled to add some limited randomness into the calculation of split ratios, to improve obfuscation.) The provider shall list his own private keys and their balances in the publication file and state what time stamp (=publication time) these balances refer to (must be consistent with the block chain of course). The provider shall list all user balances in the publication file, associating the balances with the secret user names, and indicate what time stamp these balances refer to. The user balances must be perfectly correct, and the time stamp shall be maximum 3 hours before the publication time (see previous bullet; recommended: max. 1 hour). The sum of all user balances in the publication file must not exceed the listed funds of the provider's own Bitcoin addresses. If on the other hand the provider's own Bitcoin addresses show more funds than the total user funds, this is a good sign as it indicates some overfunding (i.e. the opposite of a fractional reserve system = underfunding). The provider must prove that he actually owns the published Bitcoin addresses, and that he is the exclusive owner, by employing a mechanism and publication policy as specified in chapter 4. The applied calculation method of the new addresses shall remain the same between several publication dates. The publication interval shall not be greater than 6 months and is recommended to be not shorter than 1 week. Recommended interval = 1 or 3 months. In each publication file, the publication date and time for the next publication file shall already be announced, with an accuracy of +/- 12 hours or better. Recommended practices for the provider: After the publication time, the provider will at some point move the funds from his published Bitcoin addresses to other (own) Bitcoin addresses. We call this unloading the published bitcoin address. The provider shall unload each of his published Bitcoin address in a single transaction, and not in many small incremental transactions. This shall greatly facilitate the lookup and check of these addresses' balances in the blockchain by just searching for the address in the blockchain and looking at the last or last but one transaction of this address. On the other hand, if the published addresses are unloaded in many small steps, this may be interpreted as an attempt of the provider to conceal the actual balance of the published addresses, because it would be more cumbersome by a normal user to find out the addresses' balances as of the last publication time.

Bitcoin donations welcome:

14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR

[7 of 8]

Version 0.1 (24 April 2013)

by Michael_S (bitcointalk.org)

OpenPGP KeyID=0xCC7E7C99

Version History of this Document

0.1 24 April 2013 First version

Bitcoin donations welcome:

14ajM1BHY7E8GJ4DGGvtFFGmE15hSSSRJR

[8 of 8]