Spin-offs: bootstrap an altcoin with a btc-blockchain-based initial distribution

[Cryddit]

Does the script you're using allow people without the private key for the txOut, to identify which txOuts in the spin-off chain correspond to which txOuts in the original bitcoin chain? 

IOW, can you publicly prove that you *did* include all the P2PkH transactions, short of someone producing the private key and spending them?  Can people who are running your client prove it? 

[smooth]

I hope to start an alt chain soon, and I'd like to use this spin-off idea for the initial distribution. Using some ocaml code I parsed the block chain up to block 346,000 (yesterday morning). It's easiest if I only handle those that can be converted to P2PkH. Since P2SH has become more popular in the past year, this would mean omitting about a million bitcoins. (To be exact 1,011,673.35678149 cannot be converted to P2PkH. The vast majority of these are from P2SH outputs.)

The total value would still correspond to over 92% of the current number of bitcoins, even if I omit "dust".

I plan to release a whitepaper and announce at least a week before I take the real snapshot I will use. This will give a chance for those with bitcoins held by third parties or held in multisig an opportunity to move the bitcoins to an "ordinary" address in time for the snapshot, if they are motivated to do so.

Question: Should this still be considered a "Bitcoin Spin-off"? I am only asking about the terminology, not an attempt to claim the bounty. To be very clear: I will not attempt to claim the bounty and do not expect to meet the criteria for it.

With a million coins excluded I would say no. That's roughly 7.5% of the total outstanding and more than that if you consider lost coins (many, many coins were lost to technical errors and apathy early on when they weren't worth much if anything). Hardly negligible.

Furthermore the precedent would be terrible as the P2SH proportion is likely increasing. Someday it might approach 100%.

[Bill White]

Does the script you're using allow people without the private key for the txOut, to identify which txOuts in the spin-off chain correspond to which txOuts in the original bitcoin chain? 

IOW, can you publicly prove that you *did* include all the P2PkH transactions, short of someone producing the private key and spending them?  Can people who are running your client prove it? 

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.

[binyu]

Our team will be presenting shortly a proposal for a working alternative implementation of the famous "smart contract enabled" technology : Ethereum

Most of the work consists of adapting and blending various existing opensource software including the excellent go-ethereum by Jeffrey Wilcke; our main goal is creating a fully working Ethereum alternative implementation, compatible with the existing protocol and able to seamlessly interact with its blockchain.

With this in mind, we will be doing some important modifications to the current Ethereum specifications :

• Changes in the initial distribution - We will take a snapshot of the Bitcoin blockchain and automatically assign coins based on unspent outputs.
• No fees for computational steps in the Virtual Machine - more on this soon

This project is meant as an experimental research in financial modeling of decentralised systems and it is by no means an attempt to speculate on other group of developers hard work.

More material to be released within this week.

[Bill White]

@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.

[Raystonn]

While this distribution method may seem more fair than those previously used in the alt-coin world, it still leaves you with an alt-coin after the distribution date, and all the implications of that.  After the date of distribution, the new coin would be in competition with Bitcoin for market share.  It's time someone researched turning Ethereum into a fully fledged Bitcoin side-chain.  There's no reason to use another coin, when Bitcoin itself will work great as fuel.  A separate coin will end up being siphoned by "developers" to fund their (lack of) activities.  A Bitcoin side-chain can prevent this from happening in any hidden way.

[smooth]

A separate coin will end up being siphoned by "developers" to fund their (lack of) activities.

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.

[Raystonn]

The spin-off is effective as of the date of distribution.  At that time all the current Bitcoin outputs are assigned Aethereum outputs.  After this point in time, any new investors must purchase Aethereum, which will involve selling Bitcoin.

There's no reason we can't use Bitcoin, or a side-chain currency pegged to it, as Ethereum fuel directly.  Creation of a new coin for this only encourages eventual competition between the new coin and Bitcoin, something that cannot happen with a side-chain peg.

[smooth]

The spin-off is effective as of the date of distribution.  At that time all the current Bitcoin outputs are assigned Aethereum outputs.  After this point in time, any new investors must purchase Aethereum, which will involve selling Bitcoin.

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).

There's no reason we can't use Bitcoin, or a side-chain currency pegged to it, as Ethereum fuel directly.  Creation of a new coin for this only encourages eventual competition between the new coin and Bitcoin, something that cannot happen with a side-chain peg.

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.

[Raystonn]

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).

There's no reason to have two coins here, when one will do great.  Bitcoin can be used as the fuel currency of Ethereum by pegging it to Bitcoin through a side-chain.  There is no reason to force those who want to use Ethereum's features into becoming investors in a new coin.  The core of Ethereum isn't about financial investment, it's about distributed apps.

[smooth]

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).

There's no reason to have two coins here, when one will do great.  Bitcoin can be used as the fuel currency of Ethereum by pegging it to Bitcoin through a side-chain.  There is no reason to force those who want to use Ethereum's features into becoming investors in a new coin.  The core of Ethereum isn't about financial investment, it's about distributed apps.

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.

[Bill White]

I did a pre-announcement and released a white paper for my project: Qeditas.

https://bitcointalk.org/index.php?topic=998559

The snapshot will be taken at block 350,000 (not including 350,000 since the genesis block is 0). I won't say more about the project here since it's not the appropriate thread.

Taking the snapshot has turned out to be more complicated and time consuming than I expected. Nevertheless, I am confident I can do it and include p2sh addresses. I have written a (partial) script interpreter that succeeds in over 99% of cases. There are only two script commands I deliberately omit (OP_RIPEMD160 and OP_SHA1) since I otherwise have no reason to support SHA1 or general RIPEMD160 hashing. I also will change the semantics of OP_CHECKSIG* and OP_CHECKMULTISIG* to check for the signature of a text claim (signed using bitcoind or bitcoinqt) instead of the signature of a transaction.

I will post here again when I have a snapshot in case someone wants to inspect it and make sure the claim process will work. If all goes well, I will have a snapshot up to 348,000 soon.

[Crestington]

I did a pre-announcement and released a white paper for my project: Qeditas.

https://bitcointalk.org/index.php?topic=998559

The snapshot will be taken at block 350,000 (not including 350,000 since the genesis block is 0). I won't say more about the project here since it's not the appropriate thread.

Taking the snapshot has turned out to be more complicated and time consuming than I expected. Nevertheless, I am confident I can do it and include p2sh addresses. I have written a (partial) script interpreter that succeeds in over 99% of cases. There are only two script commands I deliberately omit (OP_RIPEMD160 and OP_SHA1) since I otherwise have no reason to support SHA1 or general RIPEMD160 hashing. I also will change the semantics of OP_CHECKSIG* and OP_CHECKMULTISIG* to check for the signature of a text claim (signed using bitcoind or bitcoinqt) instead of the signature of a transaction.

I will post here again when I have a snapshot in case someone wants to inspect it and make sure the claim process will work. If all goes well, I will have a snapshot up to 348,000 soon.

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

[Bill White]

I did take the snapshot after 350,000 blocks last week. Details are in the Qeditas thread.

This post describes an easy way for people to "claim" their part of the distribution. I think it can be helpful for other people who make future spin-offs.

One way will be simply to use the system, importing private keys. However, I want to make sure there is a way for people to "sell" their claim with a Bitcoin signed message.

The right concept seems to be to "endorse" the claim to another address (like endorsing a check). For example:

Address 1LvNDhCXmiWwQ3yeukjMLZYgW7HT9wCMru starts with a balance of 0.0015 units (since the address had 1.5 mbits at the time of the snapshot).

Suppose Alice is has the private key for this Bitcoin address.

Suppose Bob with the Qeditas address QVmqaNmBE3GbTPG3kqNh75mYpA6uUcxs35 wants to buy this claim from Alice.

Alice can sign a message

"endorse QVmqaNmBE3GbTPG3kqNh75mYpA6uUcxs35"

Qeditas will recognize two kinds of redemption scripts: an "ordinary" one (where the signatures are checked against the tx) and an "endorsement" where there are really two parts:

(1) the endorsement to an address whose signature (made by Alice, e.g., in Bitcoin-QT) is checked against the message "endorse QVmqaNmBE3GbTPG3kqNh75mYpA6uUcxs35"
and
(2) an "ordinary" script/signature made by Bob where the signature is checked against the tx.

I am oversimplifying. Since there are both p2pkh and p2sh addresses, there will be 6 cases (ordinary p2pkh, ordinary p2sh, endorse from p2pkh to p2pkh, endorse from p2pkh to p2sh, endorse from p2sh to p2pkh, endorse from p2sh to p2sh).

Does this seem reasonable to everyone? The important thing is that Bob can purchase Alice's distribution without Alice needing to share her private key or needing to interact with Qeditas.

[joeykrug447]

Augur to go with Ethereum? If you can't figure out how to do a sidecoin/spin-off for Augur, someone else will. Hitching your wagon to anything other than the economic majority, as cumbersome as it may seem, does such a powerful idea a disservice in my opinion. Thinking Ethereum "isn't about being money" is dangerously close to the fallacious mainstream "Forget the currency, it's all about the blockchain technology" meme.

Money makes the blocks go 'round. Ethereum will fail unless it understands that, or someone will create Aetherium, or even launch it as a sidechain. The point is that the economic majority, meaning Bitcoin holders, is where the action is. Not fixing Augur's coin distribution to Bitcoin will be needlessly hampering it in the extreme.

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.

[Ayle56]

Which lines of code in a spin-off would set a "claim by" time limit?

[joeykrug447]

Which lines of code in a spin-off would set a "claim by" time limit?

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). 

[Crestington]

I notice that in the sidecoin whitepaper that it isn't very detailed into the process of creating a spin-off using the balances of one Blockchain, parsing the addresses and then creating the redemption script within the new Blockchain. Would someone be able to help me with the process in a more detailed way?

[Cryddit]

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.

[Peter R]

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.

As an alternative to the ~100MB download, Smooth suggested publishing the UTXO set separately, hashing it into a Merkle tree, and embedding only its root with your distributed client.  A user would then be required to present the complete Merkle-branch proof that his claim is valid when submitting a claimTX.    

There's a diagram here:

https://bitcointalk.org/index.php?topic=563972.msg8171959#msg8171959