It will be possible for people to prove, given a certain address, that the address started with the snapshot balance (possibly modulo dust).

I will probably only start with one txOut for each funded address, essentially combining all the snapshot txOuts for that address in the bitcoin block chain.

@alexkravets and @smooth: Thank you for your replies. One yes (more or less) and one no. I agree 7.5% is a great deal to omit. It's probably fair to conclude there will not be an overwhelming majority agreeing it's a spinoff with only P2PkH outputs.

I will spend a few days attempting to cover as much of the P2SH outputs as is reasonable. This will require me to code a subset of the script language in ocaml. While this doesn't sound like fun, it will hopefully be educational. If I run into unusual cases, I will ask on the board and hope someone can help.

There will be no way to tell how many of the current P2SH spendable outputs I can handle since the redeem script is only known when it is spent. However, I will try to make sure it at least works on 90% of the P2SH outputs that have been spent so far. At that point it will be fair to estimate that at least 99% of the distribution has been copied.

As for when I will take the "official" snap shot, I am leaning towards block 350,000. This should be found at the end of March or beginning of April. As of block 350,000, 2/3 of the bitcoin distribution will be complete.

This thread makes it quite clear that taking a snapshot to create a spin-off is still highly nontrivial.

With a spin-off that only happens if Bitcoin holders decide to sell. They are betting against the new coin, while buyers are betting in favor of it. If either bets wrong, they can and will lose their money. A passive Bitcoin holder who does nothing (makes no bets) is neither helped nor hurt by the new coin.

I see no reason why a coin constructed as a sidechain and therefore impedes these bets is preferable to unbundled assets that allow betting.

In financial terms a sidechain attaches an option at par to each existing bitcoin, which allows buying a new coin which also has an attached option at par on the original bundle.

It is likewise entirely unclear to me why this form of attached assets would be preferable to unbundled assets.

After that point in time, if you don't own Bitcoin, you need to decide whether to buy or mine bitcoin, or to buy or mine the new coin. There is basic symmetry between the two in terms of their starting distribution, open competition, and a single ledger consisting of some value on each coin (assuming both coins continue to retain value at all).


You haven't explained why competition is so bad that it makes sense to suppress with a bunch of attached options the asset holders didn't necessarily want in the first place (otherwise they could just buy options). Sounds to me like someone thinking they are smart enough to pick winners, which generally ends badly.

Actually there is a reason. Because it is the most simple and natural way to implement it (not that simplicity is a value that Ethereum seems to particularly care about), and one that can be done in a trust-free way that doesn't rely on dodgy things like merged mining and mined side chains expected to be secure without mining incentives.

The reason Bitcoin created a new coin is the requirement that miners be incentivized by something entirely within the system. Otherwise it would make perfect sense to just move dollars (i.e. the existing ledger with far greater liquidity) on the blockchain.

That doesn't mean side chains are necessarily a bad idea, but claiming an approach which is both:

a) complex both technically and financially
b) unproven

is one that will "do great" is assuming a conclusion.

Fantastic! Maybe if it works you could help to create a claim for other Coins as well.

Saw this a long time ago & forgot to reply ---
Not doing a spin-off any longer, gong with sidechains to Ethereum.

Ethereum != only ether, & it's entirely possible to implement a Bitcoin sidechain to ethereum (so people can use Bitcoin on Augur ).  In fact, I'm going to work on doing just that starting in a couple weeks.

In the claim tx you just make there be a block limit (so if it's past block x, then you can no longer claim). 

If you really want to do this?

First, take your snapshot of the bitcoin UTXO set and package it with your distributed client.  It'll add a few hundred megabytes to the download.

Second, in the chainparams.cpp file where different types of key are defined and identified with prefix bytes, you make sure that none of your altcoin's keys can be confused with any of bitcoin's keys - and then you define prefix bytes for additional classes of key - one matching every type of bitcoin key whose balance you're offering to carry forward into the new block chain.

Third, in the places in the code that look at the prefix byte to determine what kind of key something is and apply the different methods for spending pay-to-pubkey-hash, pay-to-script-hash, and pay-to-pubkey altcoin addresses, you have to add methods for spending the corresponding types of bitcoin addresses when those prefix bytes are used.  These methods look it up in the txout set snapshot instead of the block chain history, and create altcoins 'ex nihilo' when bitcoin keys are used to spend the snapshotted txOuts.  Be absolutely sure that they work without making the corresponding privkey available in your block chain, because thieves will use your block chain as an information source enabling them to steal bitcoin otherwise.

But these additional spend methods only work up until block 10K or whatever your expiry block is. 

Fourth, you hack the client so that when someone 'imports' a bitcoin key it will find the corresponding balance in the utxo snapshot and make an immediate transaction creating altcoins in that amount - which must FAIL if that particular key has already been claimed by a previous tx in your block chain, but you knew that right?

After block your expiry block you can trim the database of all the bitcoin txOuts that are still unspent in the alt, as expired coins that will never be imported into the alt. In later clients you distribute the reduced database of imported keys only, to enable them to check transactions when verifying the block chain and make sure that the 'imports' are legitimate.

At least, that would be my approach.  A fair amount of coding is involved.