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

[Adrian-x]

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>"

Why not just a Bitcoin signed message with a spin-off address - no need for the claim amount it's determined by the bin file
 All seed coins are released to the first confirmed spin-off address.

[1715633352]

1715633352

[1715633352]

1715633352

[DeathAndTaxes]

One thing to keep in mind is that bitcoin doesn't just sign the message as input by the user. It appends a header to the message and signs the header+message.  This is done as a security measure to ensure a user can't be tricked into signing a tx.  The claim source code would need to be aware of the format of the bitcoin sign message header.

[DeathAndTaxes]

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?

Keep in mind that multsig can either be in the form of "native" multisig (script is in the output) or P2SH (scripthash is in the output). 

P2SH is the easier format to handle.  It would be recorded in the snapshot identically to PubKeyHash balances.  Claiming the credit would require a more complex message as you would need at a minimum the redeemscript as well as the require number of signatures.

Maybe I missed it but what is the reason for not just having the spinoff client handle the claim tx?  Is it that you want to avoid importing bitcoin private keys into a different client?

[Peter R]

One thing to keep in mind is that bitcoin doesn't just sign the message as input by the user. It appends a header to the message and signs the header+message.  This is done as a security measure to ensure a user can't be tricked into signing a tx.  The claim source code would need to be aware of the format of the bitcoin sign message header.

Yes I realize that (actually I learned about it from you a few months ago).  This is another reason why I think bitcoin-signed messages of plain-text strings are preferable to having the user sign some random piece of binary data: there's no way to trick the user and steal his bitcoins.   

But like you said, the spin-off software must be aware of these details.   

[Peter R]

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?

Keep in mind that multsig can either be in the form of "native" multisig (script is in the output) or P2SH (scripthash is in the output).  

P2SH is the easier format to handle.  It would be recorded in the snapshot identically to PubKeyHash balances.  Claiming the credit would require a more complex message as you would need at a minimum the redeemscript as well as the require number of signatures.

This will require some thinking.  Perhaps for m-of-n support, the "claim to" string could be signed by m of n addresses and the string + all the signatures could be wrapped and broadcast to the spin-off network.  The nodes would look up the address, read the redeem rules from the snapshot.bin file, and ensure that a sufficient number of correct signatures was present.  

But are there other common redeem scripts besides the standard single-address script and m-of-n multisig (native and P2SH)?  I realize we could implement the full bitcoin transaction verification procedure to handle arbitrary scripts, but I was hoping to avoid this if possible.  

Maybe I missed it but what is the reason for not just having the spinoff client handle the claim tx?  Is it that you want to avoid importing bitcoin private keys into a different client?

Yes, the idea is that the user shouldn't have to download the client (and trust it with his private keys) in order to claim his share of the spin-off pre-mine.  Someone like my dad could figure out how to use his blockchain.info wallet to produce a bitcoin-signed message of a plain-text string, and he would probably feel comfortable signing it if the text he was signing actually made sense to him, but I can't see him downloading a new client and importing his private keys.  

I actually think this is quite important.  I think we want it to be as frictionless as possible for users to claim their spin-off (for example, so that they could send it to an exchange to sell, or transfer to another user).

EDIT: Also, this might open-up the door to scams where "spin-off claiming" services convince uneducated users to give up their private keys.  

[Peter R]

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>"

Why not just a Bitcoin signed message with a spin-off address - no need for the claim amount it's determined by the bin file
 All seed coins are released to the first confirmed spin-off address.

This would be my preference too, but it does not allow for a transaction fee to be specified.  On the other hand, it makes it impossible for the user to accidentally donate his share of the spin-off to the miners!

[DeathAndTaxes]

This will require some thinking.  Perhaps for m-of-n support, the "claim to" string could be signed by m of n addresses and the string + all the signatures could be wrapped and broadcast to the spin-off network.  The nodes would look up the address, read the redeem rules from the snapshot.bin file, and ensure that a sufficient number of correct signatures was present.  

With P2SH the redeem script is not known to the network until the output is redeemed so the user would need to supply the redeemscript in the claim message.  It could then be signed by as many keys as necessary.

But are there other common redeem scripts besides the standard single-address script and m-of-n multisig (native and P2SH)?  I realize we could implement the full bitcoin transaction verification procedure to handle arbitrary scripts, but I was hoping to avoid this if possible.  

A P2SH address is just the hash of a script.  The script can be anything that the Bitcoin scripting language allows. I would guess most redeem scripts are probably fairly straightforward multisig but the redeemer supplies the redeem script so using just the blockchain there is no way to know what the scripts for the X unspent outputs to P2SH addresses are.

It probably would be a good idea to develop an UXTO parser to categorize what portion of the outputs belong to the following defined templates

1) PayToPubKey (obsolete but was used in early coinbase txs)
2) PayToPubKeyHash
4) PayToScriptHash
5) Native Multisig (not P2SH, multiple PubKeys specified directly in the tx output)
6) Non-standard *

* Note it is possible that some P2SH scripts are also non-standard but we can't categorize them as we don't know what the script is.  For this "template" we mean all outputs which don't conform to any other known template.

Somewhat related, you may find that having complete support for the range of possible Bitcoins scripts is rather code intensive.  Your claim module/class can be rather heavy and that makes all future clients heavy as well.  Having a defined claim limit would allow you to drop that code for some clients in the future.  Once the claim limit has passed and the limit is thousands of blocks deep into the blockchain and behind a checkpoint or two most nodes could probably drop support for validating claim txs and just accept that if they are behind the checkpoint and in blocks thousands of blocks deep in the longest chain then they are valid. 

[Peter R]

Thanks for that helpful information.  It sounds like we can use an easy text-based signing procedure combined with a very simple format for snapshot.bin to support claims for:

1) PayToPubKey (obsolete but was used in early coinbase txs)
2) PayToPubKeyHash
3) Native Multisig (not P2SH, multiple PubKeys specified directly in the tx output)

Somewhat related, you may find that having complete support for the range of possible Bitcoins scripts is rather code intensive.

This complexity is what I hoped to avoid.  Upon parsing the blockchain with your proposed UXTO Template Parser, I think we will find that the vast majority of the coins fit the PayToPubKeyHash template.

I suppose the question is:  Is it necessary to support all redeem scripts, or just the vast majority, in order for the spin-off to have legitimacy?  If snapshot.bin and the claiming process allowed 99% of the outstanding bitcoins to be claimed (rather than 100%) would that result in outrage?



EDIT:

This will require some thinking.  Perhaps for m-of-n support, the "claim to" string could be signed by m of n addresses and the string + all the signatures could be wrapped and broadcast to the spin-off network.  The nodes would look up the address, read the redeem rules from the snapshot.bin file, and ensure that a sufficient number of correct signatures was present.  

With P2SH the redeem script is not known to the network until the output is redeemed so the user would need to supply the redeemscript in the claim message.  It could then be signed by as many keys as necessary.

I missed what you meant here.  This doesn't sound too complex, actually.

[DeathAndTaxes]

I suppose the question is:  Is it necessary to support all redeem scripts, or just the vast majority, in order for the spin-off to have legitimacy?  If snapshot.bin and the claiming process allowed 99% of the outstanding bitcoins to be claimed (rather than 100%) would that result in outrage?

That is a good question and one that can potentially simplify the system.  We can look all all non-P2SH outputs and categorized them by standard templates ranked by how commonly they occur.  My guess is with only a half dozen templates you probably cover 99.5%+ of the spendable UXTO (some outputs are unspendable either through design or error).  So it probably does make some sense to limit it to more common output types.

P2SH introduces a wrinkle in that until spent we don't know what script the hash represents.  So if there are 1M BTC in outputs encumbered by script hashes, unlike "native" or direct output scripts there is no way to know how definitively how those coins are distributed.   You however get a proxy by looking at all spent P2SH outputs (the redeemScript will be in the input) and stratifying them into known templates.  By analyzing and categorizing the UXTO (and P2SH spent output proxy) you can get a good idea how much of the long tail do you want to include.  As an example if you have a high confidence that supporting 5 known templates covers 99% of all outputs is it worth it to support 35 known templates to cover 99.5% and the entire scripting language in all its permutations to support 100%.

[Brangdon]

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.

Certainly people have proposed spin-offs that exclude Satoshi's coins, and/or all coins that haven't been moved recently. And alt-coin communities often point to Satoshi's holdings as showing that Bitcoin's distribution is poor. So people care. Whether it's affected the market is impossible to say; perhaps the current price would be double if those coins had been provably destroyed. In any case, destroying them within Bitcoin would be near-impossible politically, so it's kinda pointless to discuss it.

I like the idea of the time limit for claims, partly because it has the effect of excluding Satoshi's coins, and those of other inactive people, without having to impose an arbitrary historic cut-off date. If we excluded BTC untouched since 2012, for example, some people would lose out and there'd be nothing they could do about it. Where-as if we require claims to be made before 2016, then Satoshi himself can make his claim if he should awaken from his slumber. It's probably better for the new coin if its users are at least a little bit active.

[smooth]

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.

Certainly people have proposed spin-offs that exclude Satoshi's coins, and/or all coins that haven't been moved recently. And alt-coin communities often point to Satoshi's holdings as showing that Bitcoin's distribution is poor. So people care. Whether it's affected the market is impossible to say; perhaps the current price would be double if those coins had been provably destroyed. In any case, destroying them within Bitcoin would be near-impossible politically, so it's kinda pointless to discuss it.

I like the idea of the time limit for claims, partly because it has the effect of excluding Satoshi's coins, and those of other inactive people, without having to impose an arbitrary historic cut-off date. If we excluded BTC untouched since 2012, for example, some people would lose out and there'd be nothing they could do about it. Where-as if we require claims to be made before 2016, then Satoshi himself can make his claim if he should awaken from his slumber. It's probably better for the new coin if its users are at least a little bit active.

This greatly calls into question the economic premise of this idea, which is that the bitcoin distribution is the most efficient. If that isn't true, then all bets are off. Sure you can use various different rules for what is included or isn't included but that goes right back to 100s (or more) of different alts, each with people rigging the rules to whatever their advantage (generally short term advantage) happens to be.

[jonald_fyookball]

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.

Certainly people have proposed spin-offs that exclude Satoshi's coins, and/or all coins that haven't been moved recently. And alt-coin communities often point to Satoshi's holdings as showing that Bitcoin's distribution is poor. So people care. Whether it's affected the market is impossible to say; perhaps the current price would be double if those coins had been provably destroyed. In any case, destroying them within Bitcoin would be near-impossible politically, so it's kinda pointless to discuss it.

I like the idea of the time limit for claims, partly because it has the effect of excluding Satoshi's coins, and those of other inactive people, without having to impose an arbitrary historic cut-off date. If we excluded BTC untouched since 2012, for example, some people would lose out and there'd be nothing they could do about it. Where-as if we require claims to be made before 2016, then Satoshi himself can make his claim if he should awaken from his slumber. It's probably better for the new coin if its users are at least a little bit active.

This greatly calls into question the economic premise of this idea, which is that the bitcoin distribution is the most efficient. If that isn't true, then all bets are off. Sure you can use various different rules for what is included or isn't included but that goes right back to 100s (or more) of different alts, each with people rigging the rules to whatever their advantage (generally short term advantage) happens to be.

well it certainly benefits bitcoin holders over altcoin pumpers.

[Peter R]

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.

Certainly people have proposed spin-offs that exclude Satoshi's coins, and/or all coins that haven't been moved recently. And alt-coin communities often point to Satoshi's holdings as showing that Bitcoin's distribution is poor. So people care. Whether it's affected the market is impossible to say; perhaps the current price would be double if those coins had been provably destroyed. In any case, destroying them within Bitcoin would be near-impossible politically, so it's kinda pointless to discuss it.

I like the idea of the time limit for claims, partly because it has the effect of excluding Satoshi's coins, and those of other inactive people, without having to impose an arbitrary historic cut-off date. If we excluded BTC untouched since 2012, for example, some people would lose out and there'd be nothing they could do about it. Where-as if we require claims to be made before 2016, then Satoshi himself can make his claim if he should awaken from his slumber. It's probably better for the new coin if its users are at least a little bit active.

This greatly calls into question the economic premise of this idea, which is that the bitcoin distribution is the most efficient. If that isn't true, then all bets are off. Sure you can use various different rules for what is included or isn't included but that goes right back to 100s (or more) of different alts, each with people rigging the rules to whatever their advantage (generally short term advantage) happens to be.

Redistributive schemes do not qualify as "spin-offs" according to my definition.  I find it absurd that people can even argue that for some reason Satoshi doesn't deserve his coins, or that him having them is a problem.  Satoshi invented a completely new paradigm!

But Smooth, there are a few fine details that need to be considered.  I'd like your opinion on:

1.  Eliminating dust by rounding all address balances down to the nearest 1000 bits.  This cuts the size of Block0 for the spin-off in half (from ~80 Mbytes to ~40 Mbytes).

2.  Reducing the complexity of the claiming process by not supporting certain bitcoin UXTOs with complex / non-standard redeem scripts.  If only 99.5% of the bitcoins were claimable, as opposed to 100%, would this be considered legitimate (assuming the rules were known in advance)?  Claiming standard payToPubKeyHash outputs is very easy (which is the vast majority of the bitcoin money supply), but complexity builds if every possible output script must be supported.  

3.  What is your opinion on spin-offs launched with time-limited claim windows (assuming the window is sufficiently long)?  DeathAndTaxes made some good arguments in their favour. 

[smooth]

1.  Eliminating dust by rounding all address balances down to the nearest 1000 bits.  This cuts the size of Block0 for the spin-off in half (from ~80 Mbytes to ~40 Mbytes).

2.  Reducing the complexity of the claiming process by not supporting certain bitcoin UXTOs with complex / non-standard redeem scripts.  If only 99.5% of the bitcoins were claimable, as opposed to 100%, would this be considered legitimate (assuming the rules were known in advance)?  Claiming standard payToPubKeyHash outputs is very easy (which is the vast majority of the bitcoin money supply), but complexity builds if every possible output script must be supported.  

3.  What is your opinion on spin-offs launched with time-limited claim windows (assuming the window is sufficiently long)?  DeathAndTaxes made some good arguments in their favour. 

I acknowledge the practical value of all of these. They all have some redistributive effect, but the actual scheme has to live in the real world, with practical considerations. If the redistributive effects are small then the practical considerations really should dominate.

My reaction is strongest on the claim window because I think that is the most grossly redistributive (against people who do not choose to "wake up" and claim their coins within the time window).  As D&T said, with a greenfield design you can do whatever you want, but some of those things are redistributive, and some are not. This one is. Clearly that is the case when there are comments about wanting to eliminate a potential "overhang" of coins.

Again I'm not certain that the non-redistributive spin-off approach is necessarily the best, but one should recognize redistributive variations for what they are.

[Brangdon]

2.  Reducing the complexity of the claiming process by not supporting certain bitcoin UXTOs with complex / non-standard redeem scripts.  If only 99.5% of the bitcoins were claimable, as opposed to 100%, would this be considered legitimate (assuming the rules were known in advance)?  Claiming standard payToPubKeyHash outputs is very easy (which is the vast majority of the bitcoin money supply), but complexity builds if every possible output script must be supported.  

As time goes by I'd expect more and more coins to be held by complex scripts. I know Armory is working on n-of-m scripts, so they'll become more accessible, and for businesses where two or more signatures are needed to spend funds they'd be a natural fit. So you might be able to get away with excluding them today, but not in 2 or 5 years, without it become political. If you have a claim window of 5 years, or unlimited, then any script type could become common.

[jonald_fyookball]

I haven't been closely following this thread but does the basic spin off functionality work already?
I suggest getting a basic 1.0 going...worry about dust, multisig, etc in the next version.

[DeathAndTaxes]

I pointed out that analyzing the blockchain for various "templates" would be a useful way to determine how common they are.  Someone has already performed a similar analysis as of block 290,000. Just to be clear it isn't exactly what we are looking for but it is an interesting datapoint.

http://www.quantabytes.com/articles/a-survey-of-bitcoin-transaction-types

The linked survey
* Based on all outputs (unspent, invalid, and spent).
* Shows the nominal # of each output template, not the value of the outputs.
* The template of the P2SH redeem scripts is unknown .

Optimal bootstrap survey
* Based on only valid, unspent outputs
* Show % of value by template type
* Break down P2SH based on known redeem scripts (spent outputs as a proxy)

The linked article breaks the outputs out into 24 templates however for our purposes many of these can be combined.  The article drops any template which has less than 10 occurrences however by my math the outputs not cataloged represent less than 0.01% of all outputs.  I computed that by looking at the difference between the # of cataloged outputs and the total # of outputs confirmed by my own tool (uncategorized = total - sum of 24 reported templates).  There may be a small difference as I was looking at total outputs at a later block but 0.01% would be an upper bound.

Code:

Pay2PubKeyHash (1 form)           86,380,556	98.91%
Pay2PubKey (2 forms)                 904,300	 1.04%
Native Multisig (10 forms)	      27,217	 0.03%
Pay2ScriptHash (1 form*)	      19,451	 0.02%
Unknown, bug, or OP_RETURN (11 forms)  2,216	 0.00% (unspendable can be dropped from bootstrap)
Not categorized (>100 forms)                   < 0.01%

* P2SH only has one format for the output script, the actual redemption is based on the redeem script which is hashed to the scripthash in the output.  
A similar analysis of the actual redeem scripts would need to be done (my assumption is that most outputs conform to one of a few templates).  

To simplify the bootstrap the Pay2PubKey (and obsolete output) outputs could be converted into Pay2PubKeyHash by hashing the PubKey.
The known unspendable outputs (bugs, possibly intentional unspendable outputs, testing, and OP_Return can just be dropped from the bootstrap.
This would mean that supporting just Pay2PubKeyHash, Native Multisig and P2SH (with only the most common forms) would provide support for at least 99.6% of outputs and possibly as much as 99.9%.  

Remember this is based on just the # of outputs not the value of the unspent outputs although I do not think the distribution will change significantly.

[tacotime]

The idea is a premine favouring Bitcoin holders, so it's no surprise that we're seeing a lot of huge Bitcoin holders here in the thread.

SolidCoin did this already with SolidCoin2 because their first chain was attacked, and I'm sure there are other instances as well.

I think it will fail for two reasons:
1. Premines in favour of Bitcoin holders are still premines.
2. There are limits to the inflation of Bitcoin, but no limits to the inflation of Bitcoin spin offs. If the first one becomes popular, next week you will see "Bitcoin-spinoff shitcoin 5.0 with PoS, Dark Send, Ethereum, Ring Signatures, and ZeroCoin", and it will simply be the next platform of pump and dumps.

I hold more Bitcoin than any Alt, but when these come out I look forward to dumping them for yet more Bitcoins.

[jonald_fyookball]

I hold more Bitcoin than any Alt, but when these come out I look forward to dumping them for yet more Bitcoins.

That was part of Peter's point.  Most coins will get dumped as they rightly deserve to be.  Only the
really innovative and valuable coins will remain held and used.

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

I was also seeing the parallel with the discussion of bitcoins on inactive addresses.  There's also the matter of physical coins and long-term, not-easily-accessible cold storage wallets.  As Peter says, it's not possible to stop people releasing spin-offs with a time deadline but the arguments can be presented here in such a way that a consensus may be reached by all other than those who want to cut out 'old money' and they are in my guess less likely to get involved with spin-offs in the first place hoping the idea will not catch on!

Despite the possibility that I am flogging a deceased equatine, there is a difference between reclaiming "inactive addresses" and a greenfield project which puts the requirements for a claim upfront.  Imagine Satoshi had decided originally designed Bitcoin (to provide a limit on blockchain growth) that an output is invalid for spending more than 1 million blocks from when it was confirmed.  I would see no problem with keeping it that way.  Anyone creating an address would be aware of the limits of the system in advance.  Changing Bitcoin now to reclaim "inactive addresses" is unethical as it is an ex post facto change.  A new coin however that uses the bootstrap as of Bitcoin block 300,000 and requires claims to be made before "newcoin" block X has no such ethical risk.  The rule is known at the point of launch (actually it probably will be known well in advance of launch).  Nobody is suggesting excluding valid unspent outputs  (except maybe very limited scenarios related to feasibility).  If Satoshi wanted to claim x coins in a spinoff he certainly could do so by creating the appropriate signatures.  If he doesn't and the claim window passes then he is making a choice to exclude himself.

The only reason I bring this up again is I feel there may be some confusion on what is being considered with a claim window.  The claim window would be on the spinoff (i.e. claim outputs are only valid before block X) it wouldn't exclude any particular bitcoin unspent output.