It does not. Decenteralized mixing and joint payments can produce transactions which are indistinguishable at the transaction level from regular common ownership transactions.

You can't even say much about coin selection behavior without knowing in advance the full content of the wallet,

but the accuracy of this guess depends on access to the ground truth on both sides.

I think people who said they did it wrong aren't expecting them to revise the paper, just to let them know that their research is flawed and will always be.

Heck, they can't even be sure they got the real blockchain instead of a fake one fed to them by whatever site they scraped it from.

The errors from making these assumptions are systemic, not random. It would be a methodological error to treat them as random errors.

You can't even give a distribution over the bias without knowing other difficult or impossible to measure cofounding factors (e.g. amount of decenteralized mixing and joint payment transactions, volume on various services, etc).

And in the case of deleted wallets? What will those coins be considered?

It's weak for reasons other than the ones listed. Coin selection tries to minimize change, so it doesn't tend to link much— especially if you use addresses once and in some clients like armory linking is explicitly avoided.  So you can have a bunch of coins in a common wallet and still not that much linkage— witness their enormous underestimation of instawallet.

What you're asking for— reliable identification of common ownership— is not possible in Bitcoin _by design_ because the pseudoanonymity of the participants is how we achieve any privacy at all, and thats diluted by combining addresses.

Unless you get people to tell you, you can't determine common ownership of addresses.

2. The question of how many bitcoins are dormant. Even though this was only one of our many findings, it was the one statistic that caught the attention of most commentators and web journalists. Webelieve that measuring this aspect is extremely important, since it implies some fundamental truths about whether the bitcoin scheme is used mostly to trade in goods or to speculate, and how thescheme will behave if its current users will change their current pattern of behavior. Once again , we have several possible approaches, and I would like to recruit your help in initiating a frank discussionin your community about how to measure this fundamental statistics in the most accurate way. We have spent a lot of time and effort in collecting all the data, but once we have it, it will be easy for us toadapt our measuring methodology based on your suggestions as a service to your community and as a contribution to the scientific study of the bitcoin scheme. However, there is one thing I would like toclarify: I do not want to have a target-shopping experiment, in which once you will see the results you will decide whether you like it or would prefer to change the methodology again in order to geta politically more appealing result. We thus propose to wait until some consensus emerges, and only then run the selected methodology on the data and announce the results.

2.1 In order to start this discussion, I would like to make an initial suggestion: Fortunately, the issue of dormant bitcoins can be made independent of the issue of common ownership of addresses(even though several comments we received argues the politically convenient point  that since our decisions about the later point did not absolutely match the ground truth, our results about dormantbitcoins were completely invalid). Let us thus work entirely at the level of addresses, paying no attention to our attempt to find such common ownerships. We propose to compile the followingstatistics: For every amount of time x (e.g., in units of full months), we will measure how many bitcoins were deposited into addresses in transactions that took place more than x months before ourcutoff date (May 13-th 2012), and were not followed by any later transaction in which the address  was one of the sending addresses.

2.2 Notice that if someone keeps moving his bitcoins every few days from one address to the next (which seems to be a relatively common behavior), we will not count these bitcoins at all as dormant(and in this sense we will underestimate the number of dormant coins) unless that user stopped doing this sometime before the relevant point in time (x months before the cutoff date), and in this casewe will only count these bitcoins once, in the last transfer which he executed (since all the previous transactions had a later outgoing transaction).

2.3. To deal with the issue of coins which were minted at the earliest period, when they had little value and could have been abandoned by early experimenters, we can also consider only transactionthat took place after a certain date.

2.4. To be fair, we will have to take into account that if we consider a large value of x, there were fewer coins at that time, so when we compute percentages, we will have to use in the denominatorthe number of coins that had been minted up to x months before the cutoff date.

1. While the notions of a bitcoin and of an address are completely clear, the notion of an owner is quite fuzzy since it can not be derived in a precise way from the available data (this may be a feature ofthe scheme, rather than a bug!). There are several ways how to deal with this issue:

1.1 Ignore it completely, and derive from the graph only statistical information about the behavior of addresses. However, we believe that this will completely distort many types of statistical informationwe try to extract from the graph, e.g., what is the distribution of the number of bitcoins that users keep, how many bitcoins they receive and spend, how big are their typical transactions, etc. Since thescheme enables (and even encourages)  users to keep multiple addresses and to constantly shuffle bitcoins internally among their accounts, we believe that it is essential to find a way to distinguish between"internal" and "external" transactions, and thus to determine in some way what is the common ownership of different addresses.

1.2 Use our methodology, which is to assume that in most of the transactions, sending bitcoins from multiple addresses indicates that all these accounts are owned by a single entity. This classification istechnically easy to apply, but it creates two types of errors: We underestimate the common ownership of accounts just because we never saw it in the given transactions, and we overestimate it sinceoccasionally there may be multiple owners who send bitcoins in a single transaction. All the anecdotal evidence we saw so far indicates that overall we tend to underestimate the number of addresseswhich are associated with a single entity (as was demonstrated in the case of Instawallet, in which we found only about 1/3 ot the actual addresses associated with it), and that the errors in the otherdirection, while they exist, are not likely to distort our statistical conclusions in a major way.

1.3 Use a different methodology, which will be closer to the ground truth, and which can be derived either from the available data, or from reliable alternative sources. Here we need your help insuggesting such a methodology, which will be discussed by and accepted by most of the bitcoin community as better representing the issue of common ownership. It is always easier to complain about theshortcomings of one methodology than to suggest a better one!

Dear Meni,

First of all, I would like to thank you and several other members of the bitcoin community for your public comments and private emails, which provided us with a lot of authoritative information about someof the intricacies of the scheme. We will be happy to add more discussion and clarifications to a revised version of our paper, which will hopefully clarify our methodology and add more relevant materialabout the quantitative aspects of the transaction graph.

I would like to address two issues which created the most heated discussion over the last few days:

1. While the notions of a bitcoin and of an address are completely clear, the notion of an owner is quite fuzzy since it can not be derived in a precise way from the available data (this may be a feature ofthe scheme, rather than a bug!). There are several ways how to deal with this issue:

1.1 Ignore it completely, and derive from the graph only statistical information about the behavior of addresses. However, we believe that this will completely distort many types of statistical informationwe try to extract from the graph, e.g., what is the distribution of the number of bitcoins that users keep, how many bitcoins they receive and spend, how big are their typical transactions, etc. Since thescheme enables (and even encourages)  users to keep multiple addresses and to constantly shuffle bitcoins internally among their accounts, we believe that it is essential to find a way to distinguish between"internal" and "external" transactions, and thus to determine in some way what is the common ownership of different addresses.

1.2 Use our methodology, which is to assume that in most of the transactions, sending bitcoins from multiple addresses indicates that all these accounts are owned by a single entity. This classification istechnically easy to apply, but it creates two types of errors: We underestimate the common ownership of accounts just because we never saw it in the given transactions, and we overestimate it sinceoccasionally there may be multiple owners who send bitcoins in a single transaction. All the anecdotal evidence we saw so far indicates that overall we tend to underestimate the number of addresseswhich are associated with a single entity (as was demonstrated in the case of Instawallet, in which we found only about 1/3 ot the actual addresses associated with it), and that the errors in the otherdirection, while they exist, are not likely to distort our statistical conclusions in a major way.

1.3 Use a different methodology, which will be closer to the ground truth, and which can be derived either from the available data, or from reliable alternative sources. Here we need your help insuggesting such a methodology, which will be discussed by and accepted by most of the bitcoin community as better representing the issue of common ownership. It is always easier to complain about theshortcomings of one methodology than to suggest a better one!

2. The question of how many bitcoins are dormant. Even though this was only one of our many findings, it was the one statistic that caught the attention of most commentators and web journalists. Webelieve that measuring this aspect is extremely important, since it implies some fundamental truths about whether the bitcoin scheme is used mostly to trade in goods or to speculate, and how thescheme will behave if its current users will change their current pattern of behavior. Once again , we have several possible approaches, and I would like to recruit your help in initiating a frank discussionin your community about how to measure this fundamental statistics in the most accurate way. We have spent a lot of time and effort in collecting all the data, but once we have it, it will be easy for us toadapt our measuring methodology based on your suggestions as a service to your community and as a contribution to the scientific study of the bitcoin scheme. However, there is one thing I would like toclarify: I do not want to have a target-shopping experiment, in which once you will see the results you will decide whether you like it or would prefer to change the methodology again in order to geta politically more appealing result. We thus propose to wait until some consensus emerges, and only then run the selected methodology on the data and announce the results.

2.1 In order to start this discussion, I would like to make an initial suggestion: Fortunately, the issue of dormant bitcoins can be made independent of the issue of common ownership of addresses(even though several comments we received argues the politically convenient point  that since our decisions about the later point did not absolutely match the ground truth, our results about dormantbitcoins were completely invalid). Let us thus work entirely at the level of addresses, paying no attention to our attempt to find such common ownerships. We propose to compile the followingstatistics: For every amount of time x (e.g., in units of full months), we will measure how many bitcoins were deposited into addresses in transactions that took place more than x months before ourcutoff date (May 13-th 2012), and were not followed by any later transaction in which the address  was one of the sending addresses.

2.2 Notice that if someone keeps moving his bitcoins every few days from one address to the next (which seems to be a relatively common behavior), we will not count these bitcoins at all as dormant(and in this sense we will underestimate the number of dormant coins) unless that user stopped doing this sometime before the relevant point in time (x months before the cutoff date), and in this casewe will only count these bitcoins once, in the last transfer which he executed (since all the previous transactions had a later outgoing transaction).

2.3. To deal with the issue of coins which were minted at the earliest period, when they had little value and could have been abandoned by early experimenters, we can also consider only transactionthat took place after a certain date.

2.4. To be fair, we will have to take into account that if we consider a large value of x, there were fewer coins at that time, so when we compute percentages, we will have to use in the denominatorthe number of coins that had been minted up to x months before the cutoff date.

I would appreciate it if you can bring this proposal to the attention of the bitcoind community, in order to initiate some discussion (and hopefully some kind of consensus). Once you tell us how we shouldmeasure the number of dormant coins in a way that will be accepted to the community, and assuming that this proposal is scientifically sound and technically doable), we will be happy to run theexperiment and report our findings.

Finally, I would like to explain a point that seemed to raise the level of paranoia in your community, and this is the involvement of the Citi Foundation in the project. I can assure you that it was ourdecision to use some of the money that the Weizmann Institute got as a gift from this foundation in order to fund some research on alternative payment systems, that the Citi Foundation had zeroinfluence on the choice of topic, that they did not get any information about our findings while the research was going on, and that they did not see our scientific report before we published it. Our research wasthus motivated by scientific curiosity about the bitcoin scheme, and we had no hidden motives to support or discredit it when we embarked on this project.

Best personal wishes,

Adi.

Is it really that bad? I mean, do you really want to make every price component explicit? Why just the transaction costs in particular, and not every other?

In the particular case of bitcoin, explicit transaction fees imply the user not only has to see a tiny price component s/he not necessarily cares about, but s/he also has to choose how much to pay. Even if you manage to abstract the mining process, people will still be in doubt about how much to give. Customers tend to be lazy. IMHO it's better to leave this task to the merchant.

He can display the total if the fee is calculated within the price, not outside of it. Like sale taxes in general.
True, that would mean the merchant wouldn't be able to know the exact amount he's going to receive before the transaction takes place. But as fees are supposed to be tiny this shouldn't be an issue. Parameters to specify a ceiling proportional to the transaction amount could also be available, solving this issue and at the same time forbidding an "evil customer" from arbitrarily creating a transaction in which the fee would be too large.

Been following this paper and the press resulting from it with interest...

And yet, am I incorrect in thinking the central thrust of the study is incorrect for the simple fact that most change goes to new addresses which are, by definition, unspent? This means that at any time, most coins will sit in "unspent" accounts, thereby appearing as though they are savings, when in reality they are just sitting there until they are spent normally.

Am I missing something or is this an absurd fatal flaw in their reasoning?

1. The paper does not mention the concept of "change" (https://en.bitcoin.it/wiki/Change), and some of the comments imply the authors do not recognize its role in the transaction graph. When outputs are spent in a transaction they must be spent entirely; if there is more value in the output than the amount one wishes to send, if he wants to keep the rest he must send it to an address of his, known as a change address. The widely used clients use a newly generated address for change as an anonymity feature; but for the typical user it is not a deliberate attempt to do anything, it is just what happens by default. This clearly explains the "long chains" behavior.

2. The paper seems to conflate the blockchain, a database replicated on every node on the network by broadcasting blocks to peers on the network, and individual efforts to make the data easily accessible, such as blockexplorer.com and blockchain.info. The blockchain itself does not of course have HTML pages or what can be considered "hyperlinks". It may be the case that scraping those public service sites is easier than parsing the arcane database format of the blockchain, but this needs to be specified explicitly, otherwise the focus on HTML looks bizarre.

3. It is generally accepted that currency amounts in Bitcoin aren't capitalized, just like "dollar" isn't. The creator of Bitcoin is Satoshi, but the smallest Bitcoin denomination is a satoshi; I can have bitcoins or send 3.7 bitcoins, and the value of a bitcoin is $12; this happens in the Bitcoin system following the Bitcoin protocol with Bitcoin software, and Bitcoin is invaluable. This mistake occurs several times in the paper.

4. You state that 7M bitcoins are in savings account, but it is not completely clear what you characterize as such. It looks like an address which has never sent coins is considered savings; that is a poor characterization, for if everyone follows the guideline of not reusing addresses, 100% of coins at all times will be in address which have never sent, regardless of how widely bitcoins are circulated. A better candidate would be an address which has never sent and has received some coins as early as, say, 2 months ago.

5. The infamous statement that "A very important feature of the Bitcoin network is that a transaction involving multiple sending addresses can only be carried out by the common owner of all those addresses".
a. You mention quoting an official policy to that effect. I would like to ask for a reference, as I know of no such policy and cannot imagine one.
b. Technically, for an input to be valid its script needs to be satisfied, usually by providing a signature for the transaction which matches the public key referenced by the input. Regardless of any current implementation details, the signatures can be independent, there is no need for the owners to be one or to share their keys.
c. The Bitcoin protocol supports more than just "moving coins from point A to point B" transactions. A glimpse of some of the potential applications can be seen at https://en.bitcoin.it/wiki/Contracts. Some of them crucially rely on this ability to have multiple owners constructing a transaction together. In this sense, it actually is a very important feature of the Bitcoin network that multiple inputs do not need to share an owner.
d. In fact, one such application is p2p mixing, of the kind I discussed at https://bitcointalk.org/index.php?topic=54266.0. These intentionally make it harder to use the transaction graph to deanonymize users.
e. In practice, most transactions on the network are simple transactions where multiple outputs of the same owner are merged, and advanced applications are not in wide use (if at all). Deducing that co-used addresses have a mutual owner is a reasonable assumption to make; but it is an assumption, it needs to be specified explicitly, and references to it being necessitated should be removed. Furthermore, this assumption - and any analysis dependent on it - will become increasingly less reasonable as advanced application find wider use.

Parameters can be specified, instead of an absolute amount. Like amount per kilobyte.

to have a Mt Gox code you need to have at least one confirm. For me to do what you are saying is I will have to have a balance left with the bank of my BTC. It would be like a debt card not a credit card.

That will be find for most uses but I'm sure there is a case where fast will come in handy.

I lost 2 bitcoins but was never told what happened to the site or would I be getting my money back?

If it's really economically inefficient, the use of such feature will be spontaneously ruled out by market forces. In the end, nobody would use it.
But while the feature doesn't exist, you can't really claim that it's use would be inefficient. Reading the rest of your post I believe you're making your judgement by looking at what happens on the current scenario of state intervention in the fiat word.

lol! Probably "RSA123"

If you observe most successful means of payment (credit cards, paypal etc), transaction fees are always embedded in the price of stuff we buy. They are never visible to the costumer. That's much more appealing than letting the costumer know that s/he's paying a fee

- even worse if it's up to the costumer to decide how much to leave as fee. They simply don't want to care about it, they care about the final price.

Plus, in the case of bitcoin particularly, it's normally the receiver who's more interested in having the transaction confirmed faster.

Would it be possible for both parties to somehow prove they have the key before and during the transactions to the adress.

Both can be proven in court if identities are known.

Brainstorming I can imagine some kind of rescue/backup transaction that would "unlock" and rollback the first transaction if certain conditions were met which would confirm from both parties that a rollback would be ok.

I might be wrong but I dont see Bitcoin as the system for that.

A man of few words

There isn't anything special or harder about an all zero hash.

To find "00000000000000000000000000000000000000000000000000000000000000000" hash is not harder than to find "458264a810936934867095f02578963498570298345702946587165c845698074" one.