Bitcoin Forum

I saw once that there are about 6 millions of unspent outputs
Is it true? How can I check that?

Should be closer to 11M, the same as the total number of bitcoins in circulation.

There's no reason it would be the same

By the definition of "unspent outputs", there's no reason it would not be the same

correction: value of unspent outputs is equal to the coins in circulation

however

The number of unspent outputs can differ from that. It's possible for all unspent outputs to be located at one address or a million.

The value of an output not being forced to be 1btc each time is a pretty good reason actually


If you buy all the 11M BTC and send them to a single address there's only 1 unspent output
If you buy all the 11M BTC and send 1satoshi to 10^15 different addresses there are 10^15 unspent outputs

ok. You are talking about the "total number of outputs", while I am talking about the "total number of bitcoins in outputs"

At block #239314 there are 6187163 unspent outputs (plus 2 that had been abandoned because of non-unique TXID)

There is an RPC command in the official client that can print it, after awhile.
I don't remember the exact word, but I'm almost sure that is starts with "get" and does not take any parameters - see "help" and you should find it easily.

Didn't know this has happened! Could you tell me more or point me to a relevant source?

I dont know. Maybe something like: https://en.bitcoin.it/wiki/BIP_0034
I think it happened in the code, when they switched to LevelDB.

It doesn't matter - whoever had that coins didn't bother to spend them on time, or more likely, nobody had them anyway.
And besides, he can always go to Gavin for a refund :)

You are throughly confused. We would never change the software in way that stole coin from someone, and no one would adopt the software if they did.

There were two instances of broken miners which created the same coins twice. Because of the way the software was written, with an implicit assumption that txids were unique, the second coins overwrote the first. The creator of those coins destroyed them, not anyone else.

The command you are looking for is "gettxoutsetinfo" (you can enter it also in the debug console of bitcoin-qt).


AFAIK:
This had nothing to do with LevelDB. As gmaxwell said, due to an error of miners it happened 2 times that a new transaction was created having the same transaction hash as existing transactions before (which in fact means that the previous transaction got overwritten). While it's normally not easy or practically impossible to produce 2 transactions with the same hash value this is not true for coinbase transactions (which can be more easily duplicated - as one can freely enter anything into the coinbase field thus influencing the resulting transaction hash value).

To avoid that this can happen again, a new check was introduced which checks, if the transaction hash exists already in the chain (and has unspent outputs IIRC). But as already 2 transactions existed which broke this rule, these 2 cases are specially handled in code now (you can see this in line 1622 here: https://github.com/bitcoin/bitcoin/blob/v0.8.2/src/main.cpp#L1622 ).

So nothing bad here, one check was missing and got fixed (already some time ago).

Please correct me, if I got something wrong.

John :)

Are you sure?
My understanding was that the previous Berkeley DB could handle no-unique keys and up to that moment all those transactions were spendable.
Moreover it was a well known fact that coinbase transactions could have the same ID and it was just openly allowed by the protocol, though not used too often. I believe there was even an explicit comment in the source code saying that same TXID is allowed for coinbase transactions.
So that could had been a design or implementation flaw, but it definitely was not considered as a "broken miner", neither "the same coins twice" - at least like two years ago, but I understand that history books can adopt quickly to a new reality ;)

After switching to LevelDB the same keys (representing TXID) just merged into each other, became undistinguished in the DB, and only since that very moment coinbase with same ID have not been spendable anymore.
But before, with Berkeley DB you could spend them, as many times as they had been mined - at least that was my understanding, so please correct me if I'm wrong.

I didn't study a lot about what happen but I don't see how two different transactions with same hash can be spent, because of the uniqueness of txids as gmaxwell pointed out

This raises a question: is this uniqueness part of the bitcoin protocol or only part of the current clients?
Because allowing same txid for different transactions could be possible in theory. By starting the output indexes at the last output index of the previous tx for example (not sure if clear)


Btw thanks you guys for the number of unspent outputs and the rpc command

It's very simple. If it has the same ID, then it must have everything else also the same - pk_script(s), the value(s)...  whatever
So it doesn't matter which one of the two gets into an actual input while being spent, since they are both identical.

You have an index of unspent outputs, where each key consists of 36 bytes (TXID+Vout).
Now when you have a database that allows you to have duplicate indexes - then you just don't need to do anything. When you see the same TXID being mined, you just append it to the table. When you spend it, just make sure to delete only one record from it.

But if one day you switch to a database engine that enforces you to use a unique indexes - then you have a problem. Not a big one, you can work around it by adding a count filed to the unspent record, but nobody bothered.
It's OK that nobody bothered, it wasn't worth it, but my point is that blaming your (a developer's) problem on "broken miners" is just not fair, since they were not broken, but 100% protocol compliant at that time.

So yeah, since you used this word already, IMO you did steal that coins, and that is why when this, as you call him, "broken miner" would realize it one day, he should be entitled to a refund :)