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

Very interesting.  I spent some time trying to figure out a claiming process using OP_RETURN but I couldn't get the details sorted out.  I'd love to hear your ideas. 

Peter,

In doing some research on merge mining an idea occurred to me that could potentially make claims easier by creating an OP_RETURN output on the Bitcoin network.  The spinoff could operate in a manner that would be best described as a SPV node when it comes to validating claims and thus would not need to know anything about Bitcoin scripting language.  Like a SPV node the "proof" that a claim is valid would be that it is sufficiently deep in the bitcoin primary chain.  This really would make the most sense for coins which are planning to adopt merge mining and intend to implement a claim window.  If you prefer we can discuss it by PM or in a new thread.

The spin-off hypothesis is that bootstrapping a new payment system (alt-coin) with the bitcoin distribution would be more efficient than an IPO or a mine-from-zero approach and would thus out-compete those coins.  Empirical evidence is required to establish the validity of this hypothesis.   


Lastly, spin-offs are an experiment.  Because bitcoin holders win either way, they can look at the process from an impartial and unemotional perspective.

There are also those with physical bitcoins or other irreversible/impractical long-term-cold-storage means of managing private keys who would be disadvantaged by timed cut-offs.  Obviously sooner or later if a coin that turns out to surpass bitcoin and/or even supplant it then those holographic stickers will need to be peeled off the Casascius coins but if it came to that it would be accompanied by great relief on my part that it was launched as a spin-off rather than as an alt that I missed out on completely!

Apologies D & T.  I had not read your point on this when I responded (I had forgotten I had more pages to read of this thread!) - hence deleting it after I'd read it.  I acknowledge it is very different in that the cutoff point will be known in advance and all claiming/trading will be done with this in mind - as opposed, as you say, to reclaiming 'inactive addresses' which is ex post facto.  

I still believe whatever the merits or otherwise of using the distribution of bitcoin as the means of distributing the new coin it is lessened when introducing a tool that has such a radical re-distributing outcome.

I doubt it.  What makes a pump & dump possible is
a) a very limited supply/float
b) very thinly traded markets (often heavily controlled by the developer)
c) a dubious (but real) fear among altcoin users that they may be missing the train.  

On c I think this is probably like trying to catch lightning in a bottle a second time but I can at least recognize the human psychology behind it.   No doubt some people will try to use a spinoff to support "yet another altcoin" but critics can and should exercise their economic power given to them by the spinoff to "vote" against it by selling off their stake.  Pumps are very difficult to accomplish in the face of large order book on the sell side and as you point out critics have nothing to lose by selling their spinoff stake if the coin ultimately ends up a failure.  Getting even 1 satoshi per xCoin is better than getting nothing (if you feel the ultimately value is 0).

Nobody can prevent the creation of a shallow clone for the purpose of fleecing idiots from their hard earned money.  However an instamine, premine solely for the devs benefit, or "IPO" all are superior choices for trying to perform a pump and dump.  A spinoff in essence is a premine where the developer has no control over who gets a "piece" of the initial supply.  Unlike other choices where the other holders are either fellow conspirators or bagholders, a spinoff gives critics a stake at no cost.  They can act as a contrary force and source of liquidity.


If you feel there is no value or merit to the spinoff you certainly should.  In doing so your economic interests will align with the "greater good" helping the market to determine the appropriate price for the asset which if you are correct is zero.  Even if the spinoff is pointless the the market is more efficient as it has more participants.  Many of those would be critical, and willing to sell for any price (if you are convinced something is worthless then getting 1 satoshi on the Bitcoin is a net gain).  This leads to a faster price discover for spinoffs regardless of their value.   In comparison in an "IPO coin" the initial stake holders are only those who were willing to buy some coins.  There is significant selection bias as those who believe the coin has no merit wouldn't buy into the IPO.  Only the "believers" hold the stake and they are reluctant to sell (especially for a loss) this distorts the market, reduces liquidity and is how you see altcoins explode 5000% in a short period of time on essentially no volume.  Eventually price will follow value but the distorted market, lack of effective shorting mechanism, and very tiny float ends up delaying price discovery leading to short term spikes before it finally circles the drain.

The snapshot is taken at a specific block height.  Transactions that occur after that block don't matter. 

If the developer elected to use a claim window of 2 years, it just means the if you held 0.000002% of the bitcoins at Block XXXXXXX when the snapshot was taken, that you would have two years to make your spin-off claim. 

In other words, if more complex scripts become widespread in the future, it doesn't affect spin-offs that launched in the past. 

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.

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.

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.

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.





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.

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.

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.

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.

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. 

well it certainly benefits bitcoin holders over altcoin pumpers.

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.

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.

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

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)


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:

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

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.


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.