Bitcoin Forum

I know this must've been discussed at some other point somewhere, so a link might be all I need.

With the availability of merged mining, Bitcoin could be optionally replaced using scripts that are impossible to eval-true the mainnet to destroy coins, but using a special script construct that sends them to an address on the new chain.  These scripts would be then be the "coinbase" transactions of the new chain.  The only way to generate coins on the new chain is through this mechanism.

For instance, the following output script destroys any coins sent to it on the main network, but easily identified by the second chain.

The new chain uses all scripts with this form as generation transactions instead of block rewards.  This guarantees that there is a direct, one-to-one relationship between BTC and BTC2 (though, it's only a one-way conversion scheme).   It has two main requirements:  it has the "same" coin-supply scheme as the original Bitcoin (because the only generation comes from destroying BTC which caps out at 21 mil), and generating BTC2 blocks provide no reward except for BTC2 fees.   And the lack of BTC2 block reward is compensated by the fact that all miners would use merged mining on the main network -- so they get their BTC reward and can optionally convert to BTC2.  They could even put the above script directly in their coinbases to generate directly into the BTC2 network.

Of course this is full of holes and unknowns.  And full of questions about how much BTC2 could actually differ from the original BTC if it's bound to its generation.  And there's questions about how to make it so BTC2 could eventually split off as an independent chain (could it?).

Indeed, did i miss something these past days ? We are changing blockchains or what  ???

Haha, sorry.  I've just been pondering the idea -- for no reason in particular -- how difficult it would be to retire BTC and move onto Bitcoin 2.0 if necessary for the future of crypto-currency.  It's always nice to have well-thought-out options if the need ever arises (SHA256/ECDSA is broken?)

Aaah, got it, please do ponder a bit on the issue yeah  :)

That might be a way to expand the coinbase, for example making 1 old BTC = 10 new BTC or whatever arbitrary value. By swapping them across chains you could avoid backwards compatibility issues with the old chain, and maintain fungibility indefinitely.

The only problem is what happens to people who have bitcoin stashes they can't access for long periods of time? If you have bitcoins hiding away for, say, ~30 years, and everyone else switches over to the new BTC2 or what have you during that time, won't your coins be left on an old, unused defunct blockchain that nobody even keeps anymore?

No, I think in this case Bitcoin is the genesis coin for Bitcoin2. You couldn't validate any BTC2 block without having BTC1's blockchain. I don't see a way to avoid this.

That's true, BTC2 would be tied to BTC1 blockchain.  But part of my thought experiment was how that might be "severable" in the future -- perhaps after X years, all unspent outputs become spendable BTC2 -- but that's entirely infeasible since there would tons of users who didn't "understand" and tried to execute transactions on the BTC1 chain that had already been abandoned... 

This severability may not be possible.  Lots of other issues, too.  But, I think this overall idea is a fun thought experiment, which is why I posted it.  Presumably, it would occur because of growing issues with BTC1, and people would want to switch to the new, safer chain.  But the solution doesn't work unless there's some flexibility to migrate at your own pace, and find a way for non-destructive severability.

Hmm.. without saving the unspent txOuts from the classic chain, there's no way to keep them spendable in the future. After a certain point, you could condense all the unspent txOuts from the classic chain into a ledger and save it away, but you'd have to maintain backwards compatibility basically forever to make sure that anyone who possibly still had access to classic coins could still spend them into the new chain. Since some of the coins are definitely lost, there's no way to know when it's "safe" to throw away all the remnants of the old chain.

As long as there was an easy old-to-new wallet converter, conversion would be no problem. After a certain amount of time, maybe 50 years, it would probably be safe to dump the remaining classic tx. The biggest problem I can see is that, compared to simply making a new free-floating currency, programming all of that backwards compatibility would be a lot of extra effort and cost. Also you'd have to hold 2 blockchains at once until at least most of the network converted, which might lead to a few double spends if any merchant were still relying on the old protocol for tx verification after the swap was finalized.

The biggest killer I can see with the BTC network is that the blockchain might tend to grow significantly faster than hardware (Wirth's Law (http://en.wikipedia.org/wiki/Wirth%27s_law)) leading to increased centralization and increased network costs. If that becomes the case, then managing two blockchains at once might be impractical or impossible.

I like this idea, but Given the fact that Bitcoin is improving, I'm curious why your thinking along these lines? There is no universal theory of finance and there will never be one single solution, not even Bitcoin. But Bitcoin can be the gold standard in which other solutions are secured. Even if Bitcoin has an enormous blockchain, it will never be as cumbersome as gold.

Your idea of pinning Bitcoin by script is intriguing. For instance, Bitcoin m-of-n transactions can be escrowed by script to lock to many other currencies indefinitely. Premined local coins could be generated and issued this way.

OP_PUSHDATA(20) <Bitcoin2Address> OP_PUSHDATA(8 ) BITCOIN2 OP_FALSE OP_VERIFY

I already did.   The second-to-last op-code is OP_FALSE which pushes "false" onto the stack, and the OP_VERIFY makes sure the top-value of the stack is "true", else the script fails.   Since this script always runs last, there's nothing any one can do to avoid having OP_FALSE OP_VERIFY at the end. 

Just a little hint about this:
There is no such thing, really )))
Bitcoin as it is now (and who knows for how long will stay like that?) is NOT for long-time investments. Besides the obvious technical things that just might happen (ECDSA broken, quantum computers force us to modify the mining algorithms, the community decides on some protocol change, whatever), nobody in their sane minds would invest long time in a commodity (or currency, whatever) that drastically changes it's price every few months. The enthusiasts do of course, but they know that this is a big risk. 30 years is like 1000 years in the IT world.

I don't understand the goal.  What problem with bitcoin are you trying to correct?

No particular problem.  I'm making a hypothetical assumption that Bitcoin 1.0 has insurmountable problems that will lead to security and integrity issues, and that somehow enough support was available to consider moving to something better.  There's a lot of lessons learned (such as on the Hardfork Wishlist (https://en.bitcoin.it/wiki/Hardfork_Wishlist)), and it may be in Bitcoin's interest to try to move to something better without throwing everything away and starting over (screwing over everyone who already has BTC).

It would be an extraordinary hurdle to migrate the community of staunch Bitcoin 1.0 followers, no matter what the justification is.  I feel like people would ignore all reasonable warnings about imminent doom and ride the train right into the Bitcoin apocalypse.  But perhaps there's a way to produce a smooth migration scheme that allows users to migrate at their own pace, but still preserve the existing supply curve and wealth distribution.

To follow up on severability:  I suppose if there was enough support, the main BTC software could be updated to "stop" at block 1,000,000, and then all unspent outputs at that block become generation inputs on BTC2.  Then generation would continue as normal on BTC2.  Yes, complicated....

I don't think my idea is really feasible, and even if it was, how much different could BTC2 actually be, given being tied to the BTC1 generation scheme.  But I think it's a useful exercise to know if such a migration was possible.

I think it much more likely that components will be swapped in and out of the bitcoin framework, rather than needing to start over.

A problem with ECDSA, RIPEMD-160 or SHA256 would cause a migration away from those functions to secure replacements, but nothing that would require a new chain.  Think more like "Blocks after 1,000,000 MAY use SHA3 instead of SHA2 for the header has, and blocks after 1,200,000 MUST use SHA3" and "Transactions in blocks after 750,000 MAY use NewfangledDSA instead of ECDSA" etc.

He's not talking about a general case.  He is saying that if we ever need to transition, we could do it by sending to this specific template.  They would be provably dead on the old network, and in a way that the new network can recognize.

Your assuming that a problem will be found that breaks the current system.  I find that unlikely, considering all the algos that bitcoin uses are modular, and can be swapped out without much problem, so long as the developers & miners can agree on a future path.  Do you know what Stratum is?

I don't want to debate the feasibility of the current system "breaking."  There's too many unknowns to say anything with any degree of confidence what will happen 10 years from now in the BTC ecosystem.  I simply wanted to explore the concept of migration, if it were to be necessary.  If it turned out that there was a very easy, smooth way to do it, perhaps it could be a better option than alternatives to dealing with major structural/security SNAFUs.

I intended for this to be theoretical exercise (with feasibility considerations).  It may not be of much use to others.  But there's plenty of discussions about what could be done in a new chain (and many alt-chains already), but I like the idea of being able to migrate without disrupting the existing wealth distribution.

I see.  Well, smooth migration was considered from the start by Satoshi, and mentioned in the white paper.  It was not expected that the algos that are secure today would remain that way forever, so there are 'stubs' in the protocol to allow future algos to be included and deprecated as required.