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

[Peter R]

I haven't committed to learning to program other than entity level html and css but I'll kick start the process by offering 1,000,000 bits (1BTC) to the first person to commit to undertaking the task on condition the code meets Peter's approval and  the source is posted under the same licence as the Bitcoin code.

That is very generous of you, Adrian!  

Note to bounty hunters: before the code can meet my approval, we must as a community finalize the file format for snapshot.bin and we should also discuss the language that the snapshot-taking program should be written in and other details.  If you are interested in this bounty, please keep us in the loop on this thread so that we are all on the same page with regards to expectations.  

As we move further along, this snapshot-taking program could potentially run on a server and create a snapshot for perhaps every 100th block.  The program would then write a new snapshot.bin file roughly every 16 hrs and 40 min (perhaps naming them snapshot_302800.bin, snapshot_302900.bin, snapshot_303000.bin, etc).  The program would store these files on the server so that they could be downloaded by the public.  In addition to making it easier for developers to launch spin-off-clones of interesting alt coins, over time this website would earn credibility and trust for accurately taking the snapshots (and make snapshot.bin the standard format).    

[Peter R]

The importance of creating a well designed coin is nothing compared to the importance of creating the network effect.

Most Alt coins not spunoff/seeded with prior chains are now obsolete in my opinion.

This concept could create the downhill snowball effect for new functionality.

Wheres the donation address  

Thank you for the kind offer!  So far I've been declining the donations offers I've received, but it sounds like there is a real demand to move forward with spin-offs.  I think one of the first things that needs to get done is for the snapshot-taking program to be written (upon finalization of the spinoff.bin file format).  Since Adrian has already offered a very generous bounty, perhaps he could set up an address specifically for this part of the project and you or others could contribute directly to that fund.  Alternatively, there are other tasks that need doing (that we will discuss later) that you may prefer to donate to as the need arises.

[Peter R]

...

Hey, it looks like you invented spin-offs a year before I did!  

https://bitcointalk.org/index.php?topic=153609.msg1630238#msg1630238

My "spin-off" thread got some attention, but I learned through various comments and PMs that this idea has actually been around since at least 2011.  I think the recent proliferation of alt-coin pump-and-dump schemes is what has created the more intense interest in spin-offs this time around.

[Peter R]

Extracting credits from Block 0 (snapshot.bin) with claim to transactions

The initial distribution of wealth in a spin-off is based on a snapshot of the unspent outputs of the bitcoin blockchain at a particular block height.  This snapshot file (snapshot.bin) becomes Block 0 and part of the definition of the spin-off coin.  Bitcoin holders can claim their wealth by producing the appropriate bitcoin-signed messages and broadcasting them to the spin-off network.  The purpose of this post is to discuss the mechanics of the "claiming" process.

Here are some of the requirements that I've thought of:

1.  The claiming process should be accessible to the entire bitcoin community.  Bitcoin users should be able to claim or transfer their share of the spin-off without needing to download the spin-off client and without needing to export their bitcoin private keys.

2.  The claiming process should be consistent between various spin-offs, to the extent possible, and portable into existing alt-coin source code with as little changes as possible.  

3.  The snapshot file becomes Block 0 and there must be no "time limit" to transfer unspent credits from Block 0.  Unspent balances in Block 0 permanently remain as valid as any other unspent output in a higher block. This requirement is debatable.

Requirement #1 places significant restrictions on the claiming processes.  Bitcoin users must be able to claim or transfer their spin-off credits using the tools they already know and trust.  IMO, this means that the claiming process must be (a) text based, and (b) use standard bitcoin-signed messages (perhaps with an application-specific "wrapper").  

Requirement #2 IMO means that (a) we should agree on a simple and flexible format for snapshot.bin, and (b) we should put sufficient thought into how credits move from the snapshot file and into the native format of the spin-off alt-coin.  This is not trivial because the spin-off may use entirely different signatures and address formats than bitcoin, but it must always be possible to claim your share of the pre-mine using bitcoin-signed messages (or at the minimum using ECDSA signatures based on bitcoin's secp256k1 curve).  

I have some ideas for how this could be done, but I'd like to ask first if other people interested in spin-offs have considered the technical details related to the claiming process.  Please share your thoughts.


I added requirement #3, because when the concept of Spin-offs was discussed on this podcast it was not understood that it is not possible (according to my definition of a spin-off) for a bitcoin user to ever lose his share of the pre-mine.  A user can claim his share on Day 1, or on Day 1000, or never; the credits are always valid as they become part of the definition of the coin.

[wachtwoord]

I want to reiterate that this concept is totally money.

It's the logical way to launch an altcoin, period. The only reason to do it otherwise is to deliberately tweak the distribution to be more "fair," but that is incredibly ironic.

It is incredibly ironic because Bitcoin is the first technology platform to actually allow a completely fair* "airdrop" where no one is left out "because they didn't hear about it in time." Once the world is on the Blockchain (of course the Bitcoin blockchain), the obvious thing to do to ensure no one is left out of an altcoin launch is to give everyone the altcoins automatically, so even if they "missed the airdrop" or "happened not to hear about the amazing new technology," they still are "reverse-taxed" the exact same proportion of the coin relative to their net crypto worth as everyone else.

Therefore if for some reason it ever becomes necessary to switch over from the Bitcoin Blockchain to a different one, there will be no need to: the ledger will be just as before, except for those that specifically opted out of the new technology. Only the technology will be different. With this spin-off idea, likely to be known in the future as "duh, that's how you launch an altcoin," you can't miss the boat, you can only jump off of your own accord. That's game-changing.

Final thought: Now consider that the Blockchain enables any asset to be launched in the same way, not just coins...

*What is "fair" will always be subjective, but at least within the crypto-sphere we can unequivocally call such distributions "fairness-neutral." That is, they don't alter the fairness of the Blockchain distribution as it stands. And Peter R's argument for why the Bitcoin Blockchain is the fairest make a great deal of sense.

Yes, this idea is so obvious it's brilliant. I can't believe it's actually being discussed. This should be a thread filled with "thank you Peter! Good job".

[Adrian-x]

1.  The claiming process should be accessible to the entire bitcoin community.  Bitcoin users should be able to claim or transfer their share of the spin-off without needing to download the spin-off client and without needing to export their bitcoin private keys.

yes the claimant, should just required to broadcast a signed message, form a Bitcoin address with valid unspent outputs in Block 0 (originating from the Bitcoin blockchain).

i think at the very least you will need a public private key pair from the spin-off, and a mechanism to broadcast the signed Bitcoin message to the spin-off blockchain this could involve at the very least downloading the spin-off client to do both those tasks.

but I'm jumping ahead, first off how to design the snapshot.bin, on for that i have to defer to those with experiences.
is this not quite simple, Block Number; Publick address + unspent outputs.

I think it beneficial if the spin off would include second 2 snapshot.bin, e.g. one for dogecoin and one for bitcoin. that way incorporating motivating the developers of doge, and broadening the user base.

[Peter R]

but I'm jumping ahead, first off how to design the snapshot.bin, on for that i have to defer to those with experiences.
is this not quite simple, Block Number; Publick address + unspent outputs.

For unspent outputs locked with standard scriptPubKeys (the vast majority of bitcoin wealth), I think it really is this simple and I'd like someone to try to find a flaw in this proposed file format:

Code:

// File header:
version (1 byte)  blockheight_of_snapshot (4 bytes)  num_bytes (4 bytes)  header data   // total of num_bytes of header data

// Wealth data for regular addresses:
tag1=0x4E (1 byte)  num_bytes (4 bytes)  pubkeyhash_1 (20 bytes)  balance_1 (8 bytes)  …  pubkeyhash_N (20 bytes)  balance_N (8 bytes)  // total of num_bytes of records here

// Wealth data for multisig addresses:
tag2=0xA7 (1 byte)  num_bytes (4 bytes)  data format to be determined

// Wealth data for other types of outputs with unusual redemption scripts:
tag3=0xB4 (1 byte)  num_bytes (4 bytes)  data format to be determined

1.  The claiming process should be accessible to the entire bitcoin community.  Bitcoin users should be able to claim or transfer their share of the spin-off without needing to download the spin-off client and without needing to export their bitcoin private keys.

yes the claimant, should just required to broadcast a signed message, form a Bitcoin address with valid unspent outputs in Block 0 (originating from the Bitcoin blockchain).

i think at the very least you will need a public private key pair from the spin-off, and a mechanism to broadcast the signed Bitcoin message to the spin-off blockchain this could involve at the very least downloading the spin-off client to do both those tasks.

This point will need some debate.  I'm thinking it is best if any bitcoin user can move their share of the spin-off's pre-mine to an exchange or to another user as simply as possible and using standard wallet tools such as bitcoin-signed messages of human-readable strings.  For example, if a bitcoin user just wants to dump their spin-off at Cryptsy, they could login to their Cryptsy account, generate an address for the Spin-off, and claim their share directly to their Exchange account.  This way, the user doesn't need to download a client in order to sell.  

I had an idea that the claiming process could possibly be as simple as producing a bitcoin-signed message of the ASCII string

       "claim <balance> to <spin-off address>"

wrapping this string and the resultant signature in an application-specific TX packet, and broadcasting the complete packet to the spin-off network.  The use of text strings in the transaction would be unprecedented AFAIK, but there could be no more than 1 of these unusual "claim to" transactions per snapshot balance, and it has the huge advantage that it makes claiming or exchanging your share of the pre-mine much easier.

How the "claim to" string and signature fit into a TX needs some discussion as well, but I think there's a reasonable solution here too.  

[DeathAndTaxes]

3.  The snapshot file becomes Block 0 and there must be no "time limit" to transfer unspent credits from Block 0.  Unspent balances in Block 0 permanently remain as valid as any other unspent output in a higher block.  

Why is this the case?  A limited "claim window" can provide cap market uncertainty.   As long as a large portion of the credits remain unclaimed there is the potential for them to be claimed in the future.  Markets generally hate uncertainty.   The mechanics are pretty easy simply define a max block height beyond which claim txs are no longer valid (and block 0 can be pruned).   So the question is more why do you believe there must be no time limit?

[Peter R]

3.  The snapshot file becomes Block 0 and there must be no "time limit" to transfer unspent credits from Block 0.  Unspent balances in Block 0 permanently remain as valid as any other unspent output in a higher block.  

Why is this the case.  I can see value if having a limited claim window.  This can be used to cap market uncertainty.   As long as a large portion of the credits remain unclaimed there is the potential for them to be claimed in the future.  Markets generally hate uncertainty.   The mechanics are pretty easy simply define a max block height beyond which claim txs are no longer valid (and block 0 can be pruned).   So the question is more why do you believe there must be no time limit?

TL/DR: Upon reflection, as long as the "claim-by" date is far enough in the future and as long as the launch is transparent, I think you are correct and it may be preferable to include a time limit.  


The roundabout answer:

A certain fraction of the cryptocurrency community believes that "something better" will replace bitcoin (e.g, the Friendster->MySpace->Facebook argument [that I believe is bogus]).  Spin-offs are a tool to help reinsure the community that should a better technology ever be found, that the natural decision would likely be to bootstrap that technology using the distribution of wealth encoded in the Blockchain.

Spin-offs are partly designed to reduce peoples' worry about "missing out," for I believe it is this fear (and greed) that powers the myriad of alt-coin pump-and-dumps that we witness.  Solidifying the spin-off process would allow people to invest in the dominant cryptocurrency (bitcoin) without paying as much attention to potential innovations in the alt-coin scene (because anything promising will be "spun off") including worrying about claiming their spin-off.   

Upon reflection, I am not completely opposed to placing a "claim-by" date on a spin-off, provided that it would be hard to credibly argue that the claim-by date was "too soon" or that the claiming process was "too complex" and that bitcoin holders missed out and now feel cheated.  For the spin-off to have legitimacy, it must avoid the criticism explored in this podcast where it was argued that spin-off developers might fudge the claim-by date to fraudulently reduce supply.  I thought that if that was made impossible it would be an improvement, but perhaps that is not actually the case.  

[DeathAndTaxes]

Agreed the claim by date should be far enough in the future to ensure users have adequate chance make a fair claim.   I can't really see how developers could manipulate a claim by date that is say one block year after the genesis block that wouldn't be obvious.

There is some merit to an open ended claim however it could have a chilling effect on the network if the available claim is relatively high compared to the active coin supply.  A claim by date allows the network to move forward with confidence that the coin supply can't be disruptively increased in the future.

[Peter R]

Agreed the claim by date should be far enough in the future to ensure users have adequate chance make a fair claim.   I can't really see how developers could manipulate a claim by date that is say one block year after the genesis block that wouldn't be obvious.

There is some merit to an open ended claim however it could have a chilling effect on the network if the available claim is relatively high compared to the active coin supply.  A claim by date allows the network to move forward with confidence that the coin supply can't be disruptively increased in the future.

I added a poll to this thread to assess what other users think about the merits of a time limit.

[jbreher]

Good arguments for either position. It may need to work itself out through competition in the marketplace. In the end, any new coin dev team will adopt as much or as little of your work as they desire anyhow, right?

[Adrian-x]

I actually would like to see both models released into the wild - my chose is both the above.
On the first implementation I'd go with the purging of the genesis block after X block height.  

[cypherdoc]

i like your original plan Peter of making the claim unlimited.

don't forget that we have this uncertainty in Bitcoin in regards to Satoshi's BTC and other addresses that haven't been touched in years.  yet no one currently suggests we go cancel them out.  the uncertainty of these addresses doesn't seem to have affected the Bitcoin market.  don't forget that part of your plan for Spin Offs was to make it as easy as possible to code these things en masse if and when you get this process moving forward.  it should be just a simple matter of dropping in the issuance code w/o anything else.  the goal was to make it as similar to Bitcoin as possible. i suggest this economic uncertainty has already been financially encoded within the Bitcoin blockchain and any perturbations away from that might cause problems.

besides, we've had this debate before ad nauseum concerning re-mining addresses that have been inactive for years, the assumption being that the private keys have been lost.  the valid counter arguments to this have been that you never know for sure if the owner of those addresses just never bothered to come to the forum to monitor news of his coins being potentially snatched just b/c they haven't been moved.  who knows, ppl can go into a coma for years before they come out of it.

[Peter R]

i like your original plan Peter of making the claim unlimited.

don't forget that we have this uncertainty in Bitcoin in regards to Satoshi's BTC and other addresses that haven't been touched in years.  yet no one currently suggests we go cancel them out.  the uncertainty of these addresses doesn't seem to have affected the Bitcoin market.  don't forget that part of your plan for Spin Offs was to make it as easy as possible to code these things en masse if and when you get this process moving forward.  it should be just a simple matter of dropping in the issuance code w/o anything else.  the goal was to make it as similar to Bitcoin as possible. i suggest this economic uncertainty has already been financially encoded within the Bitcoin blockchain and any perturbations away from that might cause problems.

besides, we've had this debate before ad nauseum concerning re-mining addresses that have been inactive for years, the assumption being that the private keys have been lost.  the valid counter arguments to this have been that you never know for sure if the owner of those addresses just never bothered to come to the forum to monitor news of his coins being potentially snatched just b/c they haven't been moved.  who knows, ppl can go into a coma for years before they come out of it.

LOL, now you've flipped me back to believing that there should be no time limits.

But as I think Adrian-X was implying, it doesn't really matter what any of us think.  Developers could launch spin-offs however they like and the market will decide whether they sink or swim.

[DeathAndTaxes]

I find the logic of the proposal a bit lacking though. Once you spin off an altcoin, calling it A, from bitcoin, why does the next one spin off bitcoin and not off A?

The premise is that to maximize the chance for adoption, the alt should always spin off the blockchain with the highest market cap at the time of launch.  Cryptocurrency users get automatically piggybacked to the most liquid and valuable network (which I expect to remain "bitcoin as is" for the foreseeable future).  

I dunno, why not spin off all of them? That's the largest market cap, right?

There is a cost in terms of the blockchain bloat of the new blockchain.  That being said one could use multiple parent chains.   However when looking at the market value of various money supplies BTC represents ~91% of the total valuation, BTC + LTC represents ~96%.  If you throw in DOGE, NMC, and PPC (tried to look at coins with 6+ months of history) that only nets you another 1%.  To get the final 3% or so would mean adding the balances of 300+ coins so pretty quickly you start to get to diminishing returns.

Just a ledger of Pay2PubKeyHash balances is ~70MB.  With P2SH, native multisig, and non standard outputs it will be more.  Lets say 90MB.   One could do similar analysis of other coins.  It really comes down to how large of a genesis block will you accept.  200MB? 500MB? 1024MB?  The more coins you use the more useful a claim limit becomes.  Once the claim limit has passed the entire tx set of the genesis block can be pruned.

[DeathAndTaxes]

i like your original plan Peter of making the claim unlimited.

don't forget that we have this uncertainty in Bitcoin in regards to Satoshi's BTC and other addresses that haven't been touched in years.  yet no one currently suggests we go cancel them out.  the uncertainty of these addresses doesn't seem to have affected the Bitcoin market.  don't forget that part of your plan for Spin Offs was to make it as easy as possible to code these things en masse if and when you get this process moving forward.  it should be just a simple matter of dropping in the issuance code w/o anything else.  the goal was to make it as similar to Bitcoin as possible. i suggest this economic uncertainty has already been financially encoded within the Bitcoin blockchain and any perturbations away from that might cause problems.

besides, we've had this debate before ad nauseum concerning re-mining addresses that have been inactive for years, the assumption being that the private keys have been lost.  the valid counter arguments to this have been that you never know for sure if the owner of those addresses just never bothered to come to the forum to monitor news of his coins being potentially snatched just b/c they haven't been moved.  who knows, ppl can go into a coma for years before they come out of it.

Well it isn't exactly the same as bitcoin outputs which haven't been spent in a long time.  In a scenario like that the holder (if not lost) truly believes in Bitcoin as if they didn't there was plenty of chances along the way to sell/trade/spend those coins.   Someone having a claim doesn't mean they have any vested interest in the spinoff.  If the limit is public knowledge they also have no expectation of unlimited timeframe.  My largest objection to "reclaiming" unused Bitcoins is that it is an "ex post facto" change and one which violates the social contract (tx are irreversible) between Bitcoin users.  That doesn't apply to a greenfield design.  If you know months prior to the genesis block that your claim expires then you have no expectation that it will remain valid forever.

There are also practical matters.   Having a claim limit allows the genesis block to eventually be pruned off completely.  If there is no limit then your choices are either arrange the claims in a merkle tree (~6M addresses = 12M hashes to validate) to allow pruning on a per claim basis or the genesis block can never be pruned.

The biggest reason is Peter's rule #2.   Someone, somewhere will decide they want to limit the claim window.   So it would be prudent in order to ensure #2 is valid that some best practices are put in place.  If it is a simple as setting one or two constants (isClaimPerpetual & claimWindowBlocks) it is more likely the process will be deterministic and uniform. 

[Peter R]

The biggest reason is Peter's rule #2.   Someone, somewhere will decide they want to limit the claim window.   So it would be prudent in order to ensure #2 is valid that some best practices are put in place.  If it is a simple as setting one or two constants (isClaimPerpetual & claimWindowBlocks) it is more likely the process will be deterministic and uniform.  

I think this settles the debate.  Whether you are for, against or agnostic to time limits, the best practices that are put in place should allow for their possibility so that they can be implemented consistently.  

Now on to another topic:

1. Can anyone see a technical reason why the claiming process (for funds unlocked by standard scriptPubKeys) can't be as simple as constructing and broadcasting a bitcoin-signed message of the ASCII string

        "claim <amount> to <spin-off address>"

wrapped in an application-specific TX packet?  I see no reason that this couldn't always be made to work (and earlier in this thread I argued for the advantages of using human-readable strings in the claiming process, despite their unorthodoxy.)

2.  Does anyone have insight into the best format for the section in snapshot.bin that contains funds unlocked by multisig and other complex scriptPubKeys?

[toast]

Someone just pointed me here saying there was a bounty for generating spinoff snapshots?

I just PMed the guy who made us our snapshot tool:

http://bitshares.org/resources/genesis-blocks/

Not sure if you will get exactly what you need from just that web tool but I'm sure it would be trivial to get him to modify it for whichever allocation you want from BTC or any altcoin

[Peter R]

Someone just pointed me here saying there was a bounty for generating spinoff snapshots?

I just PMed the guy who made us our snapshot tool:

http://bitshares.org/resources/genesis-blocks/

Not sure if you will get exactly what you need from just that web tool but I'm sure it would be trivial to get him to modify it for whichever allocation you want from BTC or any altcoin

Thank you for contacting the creator of that web-tool.

Yes, Adrian-X put up a 1 BTC bounty towards software to create the snapshot.bin files.  I want to be very clear that this bounty isn't really "live" yet because we haven't defined exactly what this piece of software should do.  So bounty hunters should communicate with us in this thread so that everyone is on the same page in regards to expectations.