Quote from: TierNolan on February 22, 2013, 02:51:31 PM

Quote from: Anon136 on February 22, 2013, 11:54:31 AM

What about multiple blockchains? And i dont mean competing blockchains, i mean other bitcoin blockchains that use the same bitcoins we use now. These blockchains wouldn't add any coins to the economy and would work entirely on transaction fees. Coins would be added to these blockchains by sending coins from the original blockchain to an address on the new blockchain and coins could be sent back to the original blockchain at any time.

I made a similar suggestion, though it was based on hierarchy. All chains would have a 1MB limit.

There would be a top-level parent chain. Each chain would have 4 children chains.

Coins could be swapped internally in a chain. In addition, there would be promote and demote transaction outputs. This would send coins upwards and downwards.

The problem is that if you require "upward" coins to be verified by the parent chain, then you are effectively including the child chain in the parent chain, which defeats the purpose.

One way around it is to use the simplified payment system to move coins back to the parent chain. This is where you assume the child chain blocks are valid, as long as there is a reasonable number of confirmations.

Miners on the toplevel chain would include the headers for the lower level chain in the parent chain somehow (say adding a merkle root to the coinbase code).

Once a header is included in the parent chain, then it becomes a "soft" checkpoint in the child chain and must be mined against, unless it is invalid. Effectively, a child chain header in the parent chain has higher PoW than one that isn't in the header. Validity checks are still needed so if an invalid child-block is included, it can still be orphaned.

As long as no reorg happens on the parent chain, this makes it much less likely that a re-org would happen on one of the child chains.

The parent chain would checkpoint the children every 1-2 blocks on average.

Downward payments are easy, a child chain needs to just monitor its parent and itself.

Upward payments could have a rule that they are accepted, as long as the transaction is buried at least N blocks deep in the child chain. This can be checked without having to download the entire child chain. N could be set to 120 or even higher.

A balance would be maintained for each child chain. The total sent upwards from a child chain could never exceed the total sent downwards. Child chains might end up with reduced coin value. This would happen if the chain confirmed a transaction that wasn't properly backed (and didn't orphan that transaction). This protects the parent chain and maintains an incentive for child chains to keep proper track of things.

If a child chain has 5,123,456 coins in various balances (including grandchildren) but only 4,999,124 was actually demoted on net from the parent chain, then it would have to rescale all coins by 4999124/5123456.

Also, child chains would have to be tx fee supported, there would be no minting fee.

You know what would be almost functionally equivalent. Release bitcoin2 as soon as it becomes a problem. it could be literally exactly the same as bitcoin1 in every way except 2. The market would drive people to adopt bitcoin 2 and 3 and 4 when transaction fees became unresonable, but they would also have incentive not to addopt too early since the more established chains would be more marketable. Anyway if decentralized electronic exchanges eventually make the process of buying products from someone who only accepts payment from a chain that you dont use sufficiently seamless than it wouldnt really be all that different than what i originally described.

as a user you would need to decide on a trade off between how accepted your chain is (how often you would need to use an exchange) how high the fees were and how secure the chain was (higher tx fee chains being more secure)

now at this point you have something fairly similar to what i originally outlined, only instead of actully moving btc from one chain to the other, you could just use seamless electronic exchanges.