Its the hypothetical future and BTC2 is being designed. Everyone loves BTC2 and no-one wants the old BTC1 any more.

People who have BTC1 would be annoyed that their assets are suddently worth a lot less because there's no demand for their BTC1 any more, so the designers of BTC2 want to include a simple way to convert their BTC1 into BTC2.

For this to work, the BTC1 world would need a way for coins to be put beyond use within the BTC1 world, in a way that everyone can be reasonably sure that no-one can use the evaporated BTC1 assets any more.

Does such a mechanism exist? If not, could/should one be added?

  • Good question... Not only double-spending, it also brings up the spectre of identity: in order to claim funds across these boundaries, you would need to prove that you are the owner of the BTC1 account in order to be credited on the new currency.
    – Andrew Vit
    Commented Sep 22, 2011 at 21:42
  • Proving is a simple as signing w/ private key. The new network just needs to be aware of BTC public keys. To reduce the number of transfer transaction it could be designed to be irreversable and one way. Once value is transfered from BTC1 to BTC2 it can't ever be undone and the BTC1 public/private key no longer has any value. Commented Oct 19, 2011 at 15:17
  • 2
    For anybody who wants to destroy some Bitcoins, I suggest sending them to the following address: 1BitcoinEaterAddressDontSendf59kuE (firstbits: 1Bitcoin)
    – Noah
    Commented Oct 20, 2011 at 12:02
  • the title is not nec correlating with the question contents. there could be many ways that bitcoins might be "destroyed" & the question contents only sketches out one of them (ie new protocol version/sequel built/released), biasing answers etc... although the general question may be too broad.
    – vzn
    Commented Mar 6, 2014 at 17:24

6 Answers 6


Sorry Alex, but you're wrong on the question being asked. It's trivial to put bitcoins "beyond use" so that they can never be spent again. All you would have to do is send the bitcoins to a made up address, which no one would have a key to. This has already been done, since coins have been sent to addresses which are almost certainly unowned (like the lowest possible hash that is a valid address).

So specifically in your situation, the BTC2 people could use a public method of creating an address that no one owns the private keys to, then design their system to credit people who send BTC1 bitcoins to that address. One reason someone might want to do this despite the open-source nature of Bitcoin would be to create a new, incompatible protocol that grabs some of the user base of BTC1 without forcing anyone to leave, allowing the two to coexist and compete quite fairly.

  • 1
    Just as a side note, does anyone have a link to the transaction I was talking about (lowest possible hash)? I thought I could find it with some blockexplorer-fu but came up empty in the 10 min I had to spend on it. It would be good to have a link. Commented Sep 13, 2011 at 19:37
  • @eMansipater 1111111111111111111114oLvT2's hash160 is zero (see What is the Bitcoin equivalent of /dev/null?).
    – 7anner
    Commented Apr 23, 2013 at 23:14

It's possible to send your BTC1 to any unknown or invalid BTC1 address. (Not with the standard bitcoin client though.) With scripting enabled, there would be even more possibilities to send your bitcoins to nowhere. This would allow the BTC2 protocol to accept BTC1 non-spendable transaction-outputs as base for BTC2 transactions. To be certain that the outputs are not spendable any more from BTC1, it is sufficient to enforce some special script format or address encoding that is incompatible with BTC1 spending.

The real problem with that is that the full BTC1 logic has to be part of the BTC2 protocol. Also, the BTC1 block broadcasts have to be accessible to BTC2 miners (or whatever they are called), so they can check validity of BTC1 transactions. This does not seems to be a good idea at all…

My personal thoughts on the subject lead to this question Decentralized transactions between two decentralized currencies, which may describe a much smoother approach to currency “upgrades” (and not only that). But still waiting for answers there!

  • You've got it a little too complicated there. All BTC2 has to understand and import is the BTC1 block chain and the private keys from BTC1. When it imports the private keys and also sees that those keys have sent bitcoins to the designated black hole, it credits the private keys in the new system. It's not really that hard to implement. Commented Sep 13, 2011 at 14:08
  • Sorry, I thought that insertion of BTC2 data into BTC1 block chain was the obvious way to go. But according to you, inserting BTC1 data into BTC2 block chain would be better? Commented Sep 13, 2011 at 17:17
  • BTC2 are the ones who are so concerned with bridging the two currencies, right? Commented Sep 13, 2011 at 18:55
  • They are also concerned about keeping their protocols and internals as clean as possible. What's the point of an upgrade if you end up with all the flaws and curses of the previous system? Commented Sep 14, 2011 at 11:38
  • 1
    Kinda getting off-topic and deep into a theoretical situation here. Commented Sep 14, 2011 at 14:08

The solution would actually be simple. A specific transaction could be added to the BTC1 protocol that means "transfer these coins to the BTC2 chain". Those mining BTC2 would also need to follow the BTC1 hash chain and permit transactions that import Bitcoins from the BTC1 chain, provided they're signed with the key the Bitcoins were exported to.

The technical issues are fairly minor and all have fairly simple solutions. A BTC2 block that imported coins illegally would be invalid and rejected by other miners. A large number of confirmations in the BTC1 chain should be required to protect against double-spend attacks on the BTC1 chain causing coins to be duplicated into both chains.

The only real requirement is that at least the majority of miners of the BTC2 chain would have to track the BTC1 chain as well to validate 'import' transactions.

All that would be required in the BTC1 system is the existence of a transaction that makes coins unspendable inside the BTC1 chain and has room to encode a key that can claim the coins in the BTC2 chain.

Whether or not this is a good idea is another story.

  • More or less the same answer as mine, but written in a much better English :-) And I was too lazy to talk about the “confirmations” issues, so +1 because you did. Commented Sep 13, 2011 at 13:53

It is highly improbable there will every be a genuine need to make "Bitcoin 2.0". The Bitcoin network can be modified over time to incorporate new features, and improvements. This evolving software model makes the need for a "clean break" unlikely. In a similar fashion that while the internet evolved far beyond its original concept, we never turned off the "old internet" and started a "new internet".

To answer the question I will assume a new block chain is needed. There is a method to make a clean switch with minimal legacy entanglements.

1) The bitcoin community should determine the new Bitcoin protocol (BTC2) and at the same time reach a consensus or at least super majority on when the current Bitcoin should end (BTC1). It would be possible to modify current Bitcoin protocol to allow stakeholders to vote based on the number of Bitcoins they hold at the time of the proposal. Any proposal to make to new block chain should have widespread support to avoid a scenario where it fragments the Bitcoin economy.

2) A omega block (last block) would be announced after debate and voting. Any bitcoins received after that block would not be able to migrate to the new block chain. Users should take care to not accept Bitcoins after the omega block. To avoid chaos and disruptions this should be announced well in advance, possible issuing new clients which warn users and even reporting post-omega transactions as bad (no value).

3) After the omega block is signed it will be reduced. The only data relevent at to the new chain is the current location of every single bitcoin. This means saving all active public addresses and their current value from the existing block chain. This will result in a significant reduction in size of block chain as the history of coins is no longer relevent, only their final location is. Likewise any public address with a value of 0 BTC doesn't need to be saved.

4) Either include the reduced block chain or a cryptographic hash in the genesis block. This provides a bridge between the old network and new.

5) The new block chain now has all the required information to migrate coins as needed by their owners. Since the BTC2 network won't "know" of transactions after the Omega block anyone coins transfered after that will have no value in the new network and thus no value in old network. It won't be possible to force BTC1 to stop as it is a P2P network but it is unlikely there will be much demand for unofficial post omega "orphaned" BTC1 transactions.

6) To avoid complicating the BTC2 protocol there will be a single transaction possible w/ BTC1 addresses/coins called "TRANSFER". The TRANSFER transaction will take a BTC1 public address and BTC2 public address and the transaction will be signed by the BTC1 private key. Thus the "owner" of any coin at the time of omega block will be the only one who can transfer it to the new network.

7) Once coins are transfered to BTC2 network via the TRANSFER transaction the BTC1 public/private key and wallet have no value or use and can be deleted by the owenr.

8) During the transistion it will be necessary for wallets to have a copy of reduced BTC1 omega block chain so they are "aware" of BTC1 and TRANSFER protocol. However once transfered a user will never need a "migration" wallet so eventually versions which drop all legacy support (TRANSFER protocol & omega block chain) will be released.

9) Nodes could choose at anytime to be "legacy free" and will ignore TRANSFER transactions and likely as time passes many nodes will stop accepting these legacy transactions as the volume of coins transfered will continually decline. As long as one node supports legacy addresses and TRANSFER transactions it will be possible to eventually have those transactions confirmed albeit with significantly increased confirmation times.


Bitcoin or "btc1" already has a mechanism built in to prevent this; it is free open-source software.

It would make much more sense (for the majority of people) to improve upon Bitcoin than to make a new blockchain.

To answer your question, a mechanism like your talking about does not exist in the Bitcoin core code. Nor do I think it should exist at present.

The people making btc2 are typically doing so in a get-rich-quick-scheme that benefits themselves. Joining these alternatives instead of modifying the open source Bitcoin core just decreases the value of BTC. It doesn't make sense for the BTC community to migrate for these reasons...


Search for "Proof of Burn". This article has a lot of good stuff: https://en.bitcoin.it/wiki/Proof_of_burn

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.