Topic: Is blockexplorer's total bitcoins in existance accurate? (Read 3206 times)

a) true, but so what?  Also, impossible.
b) false, so long as destroyed < 100%

It is a pointless change.  Yes, I said change.  Not a problem.  Not an issue.  A change.


Yes, this one example can be done in many ways.  But I think you missed the key point of my previous post.  I'll repeat it here:


The scripts allow anyone, anywhere to devise their own systems without seeking permission from the rest of the world.  I guess if you don't see that as a useful feature, I'm not going to waste any time trying to convince you.  But then again, I don't need to either.  You are the one asking the world to change.

By the way, these two topics have been discussed to death on these forums.  Search for "demurrage" and "script".

Because a) it's good to know exactly how many coins will be/are in circulation b) the number of bitcoins has a hard capped limit and if enough are destroyed it will make it difficult to function properly as a currency. Why are you so against fixing the issue?


You could do this fairly easily with Shamir's secret sharing algorithm. Just generate 4 shares of a single SHA256 private key with 2 shares required for reconstruction. You keep one, the bank keeps one and two go in the vault.

Or even more straight forward just code this type of transaction into the client. Yes you will need to update, but i expect the scripting will require updates as well. At the moment not even the main bitcoin client has all the script operands enabled, Bitcoinj only supports 7. As different clients become more popular it will be difficult to ensure scripts are fully supported.

No hashing system is perfect, but we keep getting better at it.  MD5 was pretty good.  SHA is much better.  And even if the distribution of outputs from SHA256 is only a tenth as good as perfect (which we totally would have noticed by now, but whatever), that just means that the next collision will happen in a mere 100 million years rather than a billion years (as per my totally exaggerated example from before).

Coin destruction certainly exists, but it isn't a problem.  So far, no one but you seems to have taken any offense to it.  Why do you think it is a problem?


Peter gave the big picture.  Let me give an example of a specific scenario that can be done with the scripting system, but not with simple signatures.

You want to protect your wallet.  You use a secure offline computer to generate a bunch of keys and print them out for safekeeping in a bank box.  You also sign up with an online service that gives you a series of keys (or just one key, or a seed to generate a sequence yourself, whatever).  You create another set of keys yourself, and then combine them with a script that can be satisfied under the conditions (A and B) or C, where C is one of the keys in your safe, A is one of the keys from the service, and B is just an ordinary key.

In that way, whenever you want to spend coins, you sign it with your B key and forward it to your online service.  The service consults a set of policy rules associated with your account and sends a SMS to your phone asking for verification.  You reply to the SMS, and the service signs the transaction with their A key, and broadcasts it to the network.  Since the transaction has both A and B keys, the script can be completed, and the transaction will spend as usual.

Someone that gets access to your computer can't spend your money unless they can also get the key from the service.  Also, someone that gets access to the service can't spend your money unless they can also get your keys.

If the service is attacked and you lose faith in it, or if they shut down, or if you lose your B keys, you go to the vault and pick up your stack of paper, so that you can transfer your funds to a new safe location by using just the C keys that you printed earlier.

All of this can be done using the scripting system, and without anyone in the entire network having to update their client to allow it specifically.

Do you understand the value now?

Types of transactions we haven't thought of yet.

The script system is rather flexible, and allows us to add new types of transactions in the future, without requiring the entire network including miners to upgrade to a new version.

That assuming SHA256 is a perfect hashing algorithm. Besides the coin destruction problem still exists.


Please explain what could be done in a script than couldn't be done if each client had a set of known methods to sign a transaction and a simple varint was included in a transaction to identify which method to use. At the moment scripts add a large amount of size to the block chain for little purpose.

Birthday problem

In general, we expect a collision in the hash output once every 2¹²⁸ hashes.  That is 3.4*10³⁸.  That means that 100 billion people, each generating 100 billion hashes per second for 1 billion years will generate on average one collision.


In that case, you probably don't really understand what scripts are or what they do.  In my opinion, they are the most important feature of bitcoin for the long run.

It could be a collision with any previous transaction hash, so the odds are increased the bigger the chain grows. I still think it's better not to leave things to chance, when it can be patched fairly easily.


This is a design flaw which can't be fixed, the other issue can be. I must admit it seems to me like scripts create a lot more problems than they solve.

Miners (or anyone) can also destroy coins irredeemably by sending generated coins to "OP_FALSE" or to any other script that can never return true.

The "bug" you described is a collision in SHA256(SHA256(x)).  If such a thing can be made, we have much bigger problems than someone overwriting a coinbase with a transaction.

There is no way you can be a 100% sure that nobody owns the private key of a particular address, so you don't know for certain if they are destroyed or not. There is also the possibility that in future a collision maybe generated and the coins reclaimed. With this this method you can be 100% certain that the coins are destroyed and there is no way they can possibly be reclaimed.

To fix the (rare but not impossible) bug i described either CheckBlock() should allow blocks with no coinbase at all or coinbase transaction hashes must be unique.

The miner could just as easily generate a block with 40 BTC to an address they control when they could have claimed 50 BTC and so have 10 BTC just not there, as generate a block with 40 BTC to an address they control and 10 BTC to an address they don't control like 1111111111111111111114oLvT2, or even generate a block with 40 BTC to an address they control and 10 BTC to another address they control that they then delete the private key of. It does the same thing either way, and there is just as much BTC "in circulation" either way. Having the client reject some of these possibilities doesn't help any "attack" scenario, since one can do the same thing in another way just as easily.

Destroying BTC if you control its generation or its private key is very easy: Just send it to an address that nobody has the private key for, or just delete your private key yourself. This doesn't hurt anybody but yourself. And in most cases, I'd expect an attacker that had control over a pool generation or over a private key that had coins would just send the money to themselves rather than just outright destroying it.

Still, shouldn't Bitcoin protocol be more predictable, like there will be exactly X coins in circulation at specified time ?

Not allowing miners to generate more than 50 BTC, while simulataneously allowing them to generate less than 50 BTC is little weird from programmer's point of view. Why should  < 50 BTC blocks be counted as valid, while blocks > 50 BTC be counted as invalid ?

Why wouldn't this work both ways ?

So you are saying that we should allow miners to generate tons of invalid blocks with 0 BTC as output ?

What about if a mining pool gets hacked and produces thousands of blocks of which each will yield 0 BTC ? This is a possible attack vector.

Then why bother checking to see if a block has a coinbase transaction at all.

Would the following not be a potential issue.

1) You receive a block over the network with valid coinbase whose hash is a duplicate a of an existing normal transaction
2) The block is accepted and saved to disk
3) The chain is rescanned and the block is read back from disk
4) the block will now have a normal transaction in it's coinbase slot

Will it then be rejected?

You can't stop people from destroying coins. People can just lose their private keys if they want to destroy BTC.

But can they not prevent new coins from coming into existence? Surely as a method of coin destruction it should be patched?

There's no point in adding new code the prevent duplicates. Only generation transactions can be duplicates, and they don't harm the network.

Ok I see, I think adding the following to CheckBlock() would be enough to patch it.

It is a curiosity.  If a majority wanted to stop us from creating more duplicate coinbase transactions, someone could easily patch the code so as to reject such blocks.  But I doubt that enough people care enough to overcome well-placed conservatism and inertia among pool operators, miners, and core developers.  I personally would tend to oppose such a change for the BTC chain, though I might revisit it when starting a competing chain.

In the end, is this of any concern for the general Bitcoin using public or just a technical curiosity?