A Mechanism For A Bitcoin Web Service To Prove That It Is Not Running A Fractional Reserve System (v0.2b)

Version 0.2b (26 May 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 have liquidity over 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 users 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 publicly prove at
regular intervals that it is still in possession of all user funds (=Bitcoins) - a monthly interval is
recommended. Also between these publication times the web service can show in a plausible
manner that it does not lend/share its funds to/with other web services.
Thereby, such web services can create substantial trust and credibility with their clients and get a
significant competitive advantage over similar web services that do not implement this 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: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD [1 of 13]
Version 0.2b (26 May 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/publication_file.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), and we will
refer to this published list of funds as the publication file.
The publication file essentially comprises a list of all user names (more precisely: nicknames, see
next chapter) with their respective balances, as of 02:00 am GMT (=one hour before publication
time), and the sum of these individual balances. It further discloses a short list (preferably 1 to 10)
of Bitcoin addresses carrying the provider's funds as of Sunday 03:00 am (=publication time).
These addresses are referred to as publication addresses.
Plain text format of the publication file is recommended to ease parsing by automated scripts.
The publication file publication_file.txt would look like this, here assuming for simplicity
that only five user nicknames exist:
=================================================================
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:
Nickname Balance
* alphaBuilder 71.06760005 BTC
* bitfish 50.02030000 BTC
* penguin1971 100.00000000 BTC
* redNora91 138.43306900 BTC
* teadrinker 5.72127870 BTC
-----------------------------------------------------------------
Total User Funds: 365.24220000 BTC
=================================================================
Next publication date: Sun 2 Jun 2013, 03:00 GMT.
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 nickname 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) Is the stated balance for the published Bitcoin addresses the same as what the public Bitcoin
blockchain says, as of the indicated publication time?
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 nickname, list this
nickname 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 publication file cannot include his latest funds as of 3:00 am. Hence, the publication file
shall reflect the user funds as of 1 hour back in time. Note that the web service provider could
theoretically run a small 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 could 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 inhibit withdrawals 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.
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
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 Bitcoin addresses in the published list (=publication addresses) are
really owned by this web provider and by nobody 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.: All this is ensured if the provider abides by the process described in chapter 4.
Q.: Ok, but how can the provider prove that he does not move the funds to another provider's
publication address, whose publication time is on a different day (e.g. every 3
rd
instead of every 1
st
Sunday of each month)?
A.: This is ensured if the provider abides by the process described in chapter 5.
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 or silver
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 nickname, not the login name)
with their respective gold shares.
The former corresponds to the Bitcoin addresses (A), (B) and (C) in the publication file, the latter
corresponds to the list of secret nicknames (see next chapter) with associated Bitcoin balances.
2. Adding Anonymity: Secret Nickname for Publication
Depending on the kind of web service that the provider is running, the normal 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 nickname. This name has the sole purpose of being listed in the publication file as a secret
alias for this user account.
This nickname, 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 nickname with the real identity (or public user name or login name) of the user.
Furthermore, the user is allowed to change his/her secret nickname at any time, such that another
alias (=secret nickname) will then show up in the next publication file.
The web platform has to make sure that not any two users choose the same secret nickname, and
should demand that it is sufficiently different from the publicly visible user name.
It is also strongly recommended that no secret nickname is identical to the public user 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 nickname, 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 nickname. For example, one
such web service could be a Bitcoin online wallet were users can send Bitcoins directly to 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 an odd amount such as 0.12345678 Bitcoins to User
V, or User A receives 0.12345678 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 file (from 4 or 5 weeks ago in this example). If he is lucky, User V is not a very active
user on this platform such that this was his only transaction 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 a secret nickname who's balance has changed by exactly 0.12345678 Bitcoins, he has disclosed
User V's secret nickname with high probability.
Here is a defense mechanisms that the provider can offer to his users to prevent such identity theft
via the publication file:
Each users shall have the possibility to specify not just one secret nickname, but several (e.g.
two or three). In the next publication file, the user's balance will be split between the
different secret nicknames that all belong to the same user. The split ratio could be set by
the user in the account settings and could also optionally be modified, within certain limits,
by a random function from one publication date to the next.
Note that only non-negative balances can be listed per each secret nickname, according to
the split ratio defined by the user! For example, assume that a certain user has a balance of 3
Bitcoins and has defined three secret nicknames, snick1, snick2 and snick3, with a split ratio
of
snick1 : snick2 : snick3 = 50% : 20% : 30% (must always add up to 100%).
In this case, his/her part of the balance in the publication file would appear as:
Nickname Balance
* snick1 1.50000000 BTC
* snick2 0.60000000 BTC
* snick3 0.90000000 BTC
Next publication date, if the balance is still 3 Bitcoins and the split ratio was changed to
snick1 : snick2 : snick3 = 23% : 67% : 10%, the following balances get published:
Nickname Balance
* snick1 0.69000000 BTC
* snick2 2.01000000 BTC
* snick3 0.30000000 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, publicly and 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
characteristic) and therefore cannot be re-used by another web service.
Moreover, the new Bitcoin addresses should be a function of a future event that cannot be
predicted but whose outcome can be checked easily by everyone. In this best practice
example this future event is 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). It is recommended 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 it is assumed 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! To be replaced by 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 extract the first four digits from this string
and add the pre-fix 1 (one):
12a0e
4.) We turn it into base58 alphabet by replacing all 0 (zero) with 1 (one):

12a1e
5.) We will generate a random Bitcoin address starting with these characters:
(A) 12a1e.............................
At latest 1 week after the block chain has reached block 234500, our
full Bitcoin addresses to be published in the next publication file will
be disclosed at this place. The addresses are: <to be indicated here!>
5. Plausibility of Ownership between Publication Dates
According to previous chapter, the provider is proving that the funds he is publishing under his
publication address(es) are really under his control and used exclusively by him.
After the publication was done, i.e. after the provider has transferred the funds to his publication
address(es), he may immediately transfer the funds back to other addresses of his wallet as used for
normal operation of his service. Here comes a risk: Theoretically, the provider could now lend
these funds to another provider who's publication date is at a different time. In this way one set of
Bitcoin funds would be used for two (or more) different web service providers (possibly offering
different kinds of services but belonging to the same owner) to prove their full ownership of user
funds. This way the providers could run a fractional reserve system without their clients taking
notice of it.
Hence it is necessary that the addresses that the provider uses in between two publication times are
also trackable publicly. In this way, the outlined fraud cannot be performed.
Therefore we introduce the concept of permanent addresses. The provider needs to make these
addresses public in the same way as his publication addresses. Also, the permanent addresses
should be updated from one publication interval to the next in the same way as outlined in chapter
4 for the publication addresses. Only then it is ensured that the permanent addresses are not shared
with another provider.
'The following figure illustrates this scheme whereas each grey rectangle represents one (or a
small set of) bitcoin address(es):
Fig. 5-1: General principle of publication addresses and permanent addresses,
both of which are published by the provider well in advance.
n+2
Semi-
Permanent
Address(es):
time
Publication
Address(es)
n
Publication
Address(es)
n+l
Users' own
address for
withdrawals
or deposits,
or provider's
further
addresses
associated to
user accounts
or used for
anonymization
services
Publi-
cation
time
n
Flow of
Bitcoin
funds
Publi-
cation
time
n+l
n
n+l
Now everybody can monitor the balances of the permanent addresses in between two publication
times. Generally, these balances should on average not be lower than the balances of the publication
addresses. Of course, strictly speaking, many users can legally withdraw funds in between
publication dates, and thereby the permanent addresses' balances would get smaller. The same
would happen if the provider commits a fraud as outlined above in this chapter. So strictly speaking
an outside observer cannot tell 100% for sure if a certain reduction of the permanent addresses'
balances is due to fraud or due to normal user withdrawal activity. However, by monitoring the
balances and making long-term statistics, one could determine if the variations of the balances are
plausible or a sign of fraud.
Above concept of handling public and permanent addresses can be simplified in that public and
permanent addresses become the same, as illustrated in the following figure.
Fig. 5-2: Simplified (recommended) scheme where the permanent addresses for interval n
are identical with the publication addresses at time n.
n+2
Semi-
Permanent
Publication
Address(es):
time
Users' own
address for
withdrawals
or deposits,
or provider's
further
addresses
associated to
user accounts
or used for
anonymization
services
Publi-
cation
time
n
Flow of
Bitcoin
funds
Publi-
cation
time
n+l
n
n+l
Fig. 5-2 illustrates the recommended scheme. At publication time n all funds of the provider are
residing in the addresses n. Immediately after the publication time, these addresses are flushed
to zero by transferring the funds to the next publication addresses n+1. The reason why all these
addresses are recommended to be flushed at once has practical relevance: By investigating the
blockchain (e.g. via blockexplorer), one can easily look at the last transaction of the Addresses n
and can thereby easily determine the balance at publication time n at a glance without any hassle.
Fig. 5-3 summarizes the publication life cycle, and together with the table below it is specified
when which piece of information is published in the provider's publication file:
Fig. 5-3: The publication life cycle - when is what piece of information
published in the publication file.
t_p(n+l): A new cylcle starts...
n+2
time
t_p(n): Announce block nb.
Publi-
cation
time
n+l
n
n+l
Publi-
cation
time
n
t_b(n+l): Block "Nc(n+l)" is mined
t_a(n+l) = t_b(n+l) + l week:
Latest time to announce
Nc(n+l) = current block+500
(ca. t_p(n) + 3.5 days)
time
Publication_Addresses(n+2)
Semi-
Permanent
Publication
Address(es):
Point in time ...is defined by What happens now:
t_p(n) First Sunday of a month,
3:00 am GMT.
All provider's funds are in
Publication_Addresses(n) now.
The publication file is updated with the
balances of these addresses, in agreement
with the blockchain's data, compare ch. 1.
The publication file is updated with the latest
list of user funds associated to the secret
nicknames, as of 1 hour before t_p(n),
compare ch. 1.
Bitcoin transfer of all funds of
Publication_Addresses(n) to
Publication_Addresses(n+1) gets initiated.
The value of block number Nc(n+1) is
announced in the publication file. This is
normally equal to 500 plus the number of the
last block mined until t_p(n).
t_b(n+1) The point in time when block
number Nc(n+1) gets mined.
Exactly 500 blocks or roughly
3.5 days after t_p(n).
The total transaction fees of block Nc(n+1) is
now known, so the provider shall now start
calculation of the
Publication_Addresses(n+2), as outlined in
ch. 4.
t_a(n+1) Exactly 1 week after t_b(n+1) This is the latest point in time until the new
next Publication_Addresses(n+2) must have
been calculated and announced in the
publication file.
In fact, the new publication addresses will be
announced at any time between t_b(n+1)
and t_a(n+1), i.e. within a 1 week interval.
t_p(n+1) First Sunday of the next month,
3:00 am GMT.
This is 4 or 5 weeks after
t_p(n), or roughly 2.5 or 3.5
weeks after t_a(n+1).
The next cycle starts here...
6. Checklist for Trustworthiness of a Web Service Provider
We summarize important points that serve as a checklist for customers 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 of these points:
Every user is mandated to create at least one secret nickname 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 nickname to the user! The user must not be influenced in his choice of the secret
nickname 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 nicknames that are unlikely to
be used by other users, and the provider's web server shall check and reject any secret nickname
that is already existing for another user (be it as a secret nickname or login/user name).
If users are allowed to create several secret nicknames, 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
blockchain of course).
The provider shall list all user balances in the publication file, associating the balances with the
secret nicknames, 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 for the new publication addresses shall remain the same for
several publication intervals.
The publication interval shall not be greater than 6 months and is recommended to be not
shorter than 1 week. Recommended interval = 1 month.
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: exact accuracy).
At each publication time, the provider shall move the funds from his old to the new
publication addresses, in a single transaction per publication address, as outlined in ch. 5 and
Fig. 5-2.
Between two publication times n and n+1, the vast majority (>95%) of provider's fund shall
always reside on the publication addresses n+1 at an moment in time, such that it can be
considered plausible from observing the provider's total balance over time in the blockchain,
that he does not lend out his funds to another web service provider at any point in time.
Version History of this Document
0.1 24 April 2013 First version
0.2 26 May 2013 Terminology: Replaced secret user name by secret nickname
Addition of the concept of permanent addresses on top of the
publication addresses, to provide plausible prove of Bitcoin ownership
also between publication dates.
Further, minor, changes.
0.2b 26 May 2013 Chapter 3: Correction: All nicknames' balances must be non-negative
(else provider could easily misuse it to run a fractional reserve system).

A Mechanism For A Bitcoin Web Service To Prove That It Is Not Running A Fractional Reserve System (v0.2b)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Mechanism For A Bitcoin Web Service To Prove That It Is Not Running A Fractional Reserve System (v0.2b)

Hochgeladen von

Copyright:

Verfügbare Formate

Version 0.2b (26 May 2013) by Michael_S (bitcointalk.

org) OpenPGP KeyID=0xCC7E7C99

Das könnte Ihnen auch gefallen