Topic: Proposal for a new transaction type. (Read 954 times)

True, that threat of losing the coins will keep the number of coins in the new system in check until there really is enough demand for them, so I don't see it as a bad thing. And yes, for the recent future, blockchain upgrades can be done in reasonable time. However, the bigger bitcoin grows, the more time it's likely to take.


Yes, like I said, it's possible already, just not standardized, so this is mostly a cosmetic thing. What you proposed, however, is lacking in that it only contains the network-id, basically, it doesn't contain the information on how to verify respends in the new network.

In theory it's probably possible to have multiple block chains without any problems as long as it can be splitted and re-branched into main chains and so forth.

So there could be multiple main chains.

However there is one limitation:

Bitcoin addresses should then only belong to one chain, and not multiple.

Also transferring bitcoins from one main chain to another main chain would need some kind of solution.

The idea of the main chains is to prevent double spending.

As long as the bitcoins remain on their own chains with their own bitcoin addresses then there is no problem.

Otherwise the problem of double spending would return in theory and that would be bad.

In other words: bitcoins can and should only be spent/sent/received on a single/their own chain, to prevent duplicates.

However I see little value in providing any kind of multi chain support at this moment, simply because the future is unknown.

If the implementation needs to change then this will be known in the future.

I don't really see how the developers could take action now to make something that would make transition and compatibility in the future possible.

The only thing which they could do is use easily changeable formats, like xml/text but even binary can be changed with proper version fields.

The bitcoin client exchanges version information when it connects with clients.

I think that version information will be enough to implement changes in the future...

Such a transaction type already exists for getting Bitcoins "off" the Bitcoin network.

Just define a bogus Bitcoin address, and send Bitcoins to it.  The bitcoins can never be respent.

Here is an example.  1B1ackHo1eForYourBitcoinskDEzxdZ6j

Note, I calculated the suffix "DEzxdZ6j" to contain a valid check code, so that the Bitcoin client would accept it as a valid address.

You can send Bitcoins to it, and they will be forever gone.  This is a valid Bitcoin address, but it is impossible to create a vanity address that both a) contains this many user-selected characters, and b) provides a valid private key that would allow the funds to be respent.  So in effect, you can guarantee that any bitcoins are unspendable just by looking at it.  Sure, I can calculate a check code that makes the address look good enough to not be rejected by the Bitcoin client, but I can never respend the funds.

Simply hardcode your alt chain to recognize this special address as an import of coins and you're good.

No one presently wants a way to import non-Bitcoins into the Bitcoin block chain, so no one will accept any changes to accomplish that without an overwhelming consensus desiring it.

If you send coins to new chain and that chain, using your own words "does not end up being better", you will loose coins.

I think that protocol upgrades and development changes will be able to be done through single blockchain, if announced ahead of time enough. Also, I can think of client-to-client queries like "are you ready to switch to protocol XY after block Z?". When enough clients in the network agree on it, lets do it.

In current days, making an "agreement" with several largest mining pools would be sufficient.

I've been thinking about how to handle changes in development that will fork the blockchain without disrupting the markets too much. Creating a new blockchain is one obvious solution, however, this one has some drawbacks.

• If the new chain does end up being better and taking over, it's pretty much guaranteed some people will end up with worthless bitcoins
• The value of the new coin has to start from 0

This transaction type I'm proposing could mitigate these issues somewhat. The basic idea is to define a transaction type for the sole purpose of marking bitcoins as "having been sent to another chain". This transaction obviously wouldn't need to be doable from the regular interface, however, if the blockchain itself supported such a transaction, it'd allow creating other implementations that can be bootstrapped from bitcoin.

This is, of course, entirely possible even without a defined standard transaction type. However, having a defined transaction type for this would make it obvious what "that strange transaction" is about if people do choose to do this. This is also a potential upgrade path should the bitcoin network ever need a complete rework.

I expect that as Bitcoin network grows and as different implementations become more numerous that this will eventually become the only sensible way to upgrade the network. Ideally, the groundwork for this ought to be laid down before that happens.

The data the transaction would need to contain is network-id for the network to transfer bitcoins to and binary data for the txIn equivalent in the network. The transaction would also naturally mean the bitcoins transfered are no longer available for transfering within the bitcoin network.

The new network would then need to have a bootstrap period during which it'll accept coin transfers from the bitcoin network. This would likely make it necessary for the initial versions to include bitcoin compatibility mode as well. However, it could probably function in a semi-light mode, only verifying and keeping the data that is needed for verifying the bitcoins that have been transfered to it's network.

If this process could be made bidirectional, that would be great but I can't see how that could be done without a potential for major problems.

Any thoughts?