Topic: Spin-offs: bootstrap an altcoin with a btc-blockchain-based initial distribution - page 4. (Read 53616 times)

There's no need to download. The proof building tool can be hosted. Of course the entire tree should be published for transparency purposes, but each individual claimant doesn't need to download it.

Oh. 

Yes, exactly the same principle. 

This thread is about bootstrapping an altcoin with a btc-blockchain-based initial distribution, I want to bootstrap an altcoin with an altcoin-blockchain-based initial distribution.

Same principle?

In order to answer your question, I would need to know what you mean when you use the words "claiming coins through a bitcoin distribution."   

Sure, that works.   It's elegant even; it means nobody has to download the snapshot unless they're actually trying to import coins from the snapshot.  They'll need the snapshot to build the merkle tree but the people checking the transactions wouldn't need to see it.  The distinction in terms of code is that now your methods to import things from the snapshot have to build a merkle tree proof, and your methods to check those transactions have to check the proof. 

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://bitcointalksearch.org/topic/m.8171959

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.

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?

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

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

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.

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.

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

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

https://bitcointalksearch.org/topic/pre-ann-qeditas-a-formal-library-as-a-bitcoin-spin-off-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.

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.

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.

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.

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.

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.