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

I haven't seen it mentioned above ... there's an experiment in progress that uses a "proof-of-chain" approach to coin distro:

https://bitcointalksearch.org/topic/annclam-clams-proof-of-chain-proof-of-working-stake-aka-clamcoin-623147


The tone is a bit lurid perhaps but the claims proved accurate when this lapsed Shibe collected his CLAMs.

Cheers,

Graham

The point I was trying to make is that only 0% is "safe."  With any other distribution, there will be questions about legitimacy.  If there are too many questions, the technology (should it actually be useful) may be at risk of getting scooped by clone launched with a more efficient distribution.  

But like Cypherdoc said, the developers can still benefit based on the asymmetry of their information.  They can be highly-prepared to mine coins upon launch and they can purchase coins from bitcoin holders who are happy to sell this "free money" for cheap.  

When I said earlier that I expect the developers could accrue 0.1 - 1% of the money supply, I meant starting from 0%.  If the initial distribution differs from what is encoded by the unspent outputs in the bitcoin blockchain, it is not a spin-off.  

Peter R: What % do you think is "safe" for an altcoin developer to use?

If you have a large dev team and lots of unique tech, it is safer for you to give a smaller proportion to BTC and larger proportion to other, more targeted distribution that is more favorable to yourself. I don't buy the "it only takes one dev to keep a fork maintained" argument, there is so much more to acquiring network effect than initial distribution.

I'm curious about specific numbers. You wouldn't settle for anything less than 100%, and would lead a snapshot effort? What about 80%? 50%? Bitcoin whales can only spread their attention so thin before being unable to fork everything.

I think D&T said if a coin is innovative AND if it uses the spin-off technique, then it is unlikely that a copy could outcompete it.  In other words, if the "spin-off effect" is real, by launching with a spin-off distribution the developer can minimize the chance that his tech gets scooped by a clone (that goes on to outcompete the original).  



Developers gonna develop and no one can stop them.  However, it is pretty clear to me that a properly launched spin-off would outcompete a 50% pre-mined (but otherwise equivalent) coin.  But what if the developers awarded themselves 5% of the new coins?  What about 1%?  

If I was going to launch an alt-coin, I would use a true spin-off.  Since I was the one who picked the mining algorithm and controlled the launch date, I'd have my miners fired up and ready to go right at launch.  By mining when difficult was low, and perhaps by purchasing coins dumped for cheap, I bet a developer could accrue 0.1 - 1% of the money supply for a low cost.  The beauty here is that there will be no questions about the legitimacy of the distribution.  Every detail would be completely transparent.

Is 0.1% - 1% not enough incentive?  If your spin-off reaches the market cap of Litecoin, then that's $300,000 to $3,000,000 of potential profit.

I think a lot of the alt-coin developers aren't thinking BIG.  Litecoin has a $327 million market cap AND is not innovative AND has a sparser distribution than bitcoin.  Could a properly-launched and functioning spin-off of something that actually represents a potential innovation take second place?  

When does this hypothetical time in the future happen for bitcoin itself?

Since the answer is never, if investors really "need" this, then they wouldn't be investing in bitcoin, and the bitcoin distribution wouldn't be efficient.

Your argument is essentially a refutation of the original premise.

There's no need to include the founders in the initial distribution of a spin off. We've been through this already. Their premine or IPO distribution in the original coin is part of the problem. We are trying to avoid that in the spin off.

 The way the founders can still benefit is by buying up the cheap spin off coins that will surely be dumped by Bitcoiners who are skeptical. The founders will surely buy them up if they sincerely believe in their project since  they have the asymmetric knowledge  necessary to make that assessment.

If the goal is ONLY to stop people from
getting scammed by pump and dumps,
then I agree.

However, I thought part of Peter's idea
had additional benefits of bolstering
Bitcoin and benefiting bitcoin owners,
who represent a larger cross section
of the population.

Your premise that new technology
would always outcompete a spinoff
with a better distribution is certainly debatable. 

There are degrees of novelty and
I think the original idea was to have
each coin compete on it's merits,
including the distribution. 

I like the idea of including original
owners in the spin off distribution,
because it gives additional benefits
to both parties.  Additional "fighting chances"
to the spin off, benefitting bitcoiners,
And insurance to the original altcoiners.

The spin-off technique is only a tool.  If a spin-off tends to out-compete the original due to its supposed efficient initial distribution, then the "spin-off effect" just becomes a known part of economic reality.  If the effect is real, then developers will adjust to the new reality.  This is progress.  People adapt. 

Excitement about killing pump and dump scams, or fear of innovative developers losing out are projections made by humans reacting emotionally to an unknowable future.  It is no different than bitcoin supporters dreaming of entirely new markets and frictionless worldwide trade, or bitcoin opponents fearing a rise in child porn and terrorism. 

10% ...

Well now you get to the point.  The quote above indicates you disagree with the very basis for the concept even at the most fundamental level.   If true then don't use it.  The purpose of the thread is BASED on Peter's Premise how could we go about acheiving that goal.  If you disagree with the premise then the exact mechanics are kinda moot. 

If Coin X has "new tech" and uses a spinoff distribution then Coin Y (being a copy of Coin X) has no chance of mainstream adoption.  It doesn't matter if it uses Bitcoin as its parent or Bitcoin + Coin X it is a shallow copy which brings nothing new.   Coin X is going to win against Coin Y.  So I think your fear is overblown.  Shallow copies of existing tech will probably never be able to carve out a large enough niche to be successful in the long run.   A spinoff might help the chances of a cryptocurrency but a dud is a dud and spinoff isn't going to change that.

That's exactly the problem here.

Spin-off treatment is presented as a threat, something to kill altcoins, and
it of course does nothing of the sort. There wouldn't be any sense to spinoff
plain scrypt/x11/whatever clones, which is what most altcoins now are, since
the only uniqueness they may have is outside the codebase. Only technically
innovative coins can be threatened, so the end result is that exactly class A
altcoins get "the hammer" but not the fluffy ones.

On the other hand the spinoff technique is a very ingenious way of solving
the initial distribution problem. I just wish that it was marketed as that
and not as some sort of weapon.

Here's Peter R, himself, acknowledging that creating a Spin Off of a coin that includes Innovative Technology and, yet, doesn't include Holders of THAT Coin, but only Bitcoin Holders, in the Initial Distribution "undermines their [the Dev's] efforts."

The rest of his post amounts to this.... "yes, we're undermining True Tech Innovation but, if they're smart enough, there is a way for them to do fine even though we're ripping off the code they've established as OpenSource."

But what about those who Invested in the AltCoin Precisely because it included non-trivial Tech Innovation.... Doesn't their Investment in that Coin, worthy of Spinning Off, mean precisely that they are capable of making Market Efficient judgments about what ought to succeed in the marketplace. And these are the people who will get hurt the most by the plan because they might not know how Mine the Spin-Off from day one...

Meanwhile, Bitcoin Holders, those with a few and those truly wealthy, get the fruit of True AltCoin Innovation for no effort and no thinking...

How can this--an initial distribution that doesn't include Holders of the Coin-Spun-Off--be understood as anything else but a plan to rip off those who do Tech Innovation--and those who invest in it--for those who have large Bitcoin Holdings?

The claim, by Peter R, that a Bitcoin Holders only Initial Distribution, is the Efficient Distribution... obviously isn't a true or fair distribution...

I thought the point of the discussion has been to develop some Best Practice ideas for Spin Offs. What I'm suggesting is that it would be Very Bad practice to Spin Off a Coin without including its holders, by whatever rules, in the Initial Distribution.

So taking a look at how to store the values in the ledger entries.  These apply equally to both the direct* and simplified claim verification. No single claimant has 21M BTC and thus it isn't necessary to store values as a uint64.  The claimant (single PubKeyHash, ScriptHash, or unique multisig requirements) with the highest "balance" (sum of the value of unspent outputs) is ~1.8 x 10^13 satoshis.  This would mean all entries in the ledger can be stored as 46 bit integers (or 48 bits preserving byte boundary).  With some of the space saving considerations it may make sense to consider both an unpacked and packed version of the bootstrap.bin.  As an example the UXTO could be parsed to find the bit length needed to represent the highest ledger value, store the bitlength in the header, and then reduce the size of all entries to that length.   In initial setup the packed ledger could be unpacked to represent all values as uint64 (or whatever native structure the spinoff uses).

The size of the value field can be reduced further by looking at the min redeemable claim value.  Optionally the ledger doesn't need to represent satoshis unless entries down to a single satoshi are redeemable.  The required length of the value field is the range from smallest to largest value.  In Bitcoin Core v0.9+ the min fee to relay for low priority txs is 1,000 sat and the dust threshold is 543 sat.  Since the devs decided 0.543x the min fee was smarter than 1/2 the min fee working in increments of the dust threshold is clunky.  With a negligible loss of precision the UXTO could be purged of dust below the min relay fee by taking the floor of all uxto values  [ ledger_value = floor(value_in_satoshis / 1000) ].  This reduces the max entry to 1.8x10^10, allowing the value field to be reduced to 35 bits (40 bits if preserving byte boundary).  This probably can be reduced further by using some form of varint. 
  

If the average claimant identifier is ~22 bytes per record then for a 2 million entry bootstrap.bin we are looking at:
64 bits full range = 8+ 22 = 30 bytes (60MB ledger)
48 bits packed = 6 + 22 = 28 bytes (56MB ledger) ~7% reduction
40 bits packed = 5 + 22 = 27 bytes (54MB ledger) ~10% reduction
varint (avg 24 bits) = 3 + 22 = 25 bytes (50MB ledger) ~17% reduction

* Need a good term to identify spinoff not using SCV. Full Verification?  Direct Verification? Native Verification?

Well saying it is "simple" and making it simple are two different thing.  The concept of claim verification from a single parent (most likely Bitcoin) hasn't been completely resolved.  Adding 2 (or more) parents only makes the claim and verification process even more complex.

That being said a clone of a spin-off is not likely to gain any traction of marketshare (which is sort of the whole point).   Still if you want to design a system which can spinoff from multiple parents feel free to extend the concept.  Ultimately nobody can force a future dev to use any particular set (or subset) of available tools and resources.  The only thing which can be done to to create the tools and hopefully developers will use them.

Seems fair.

Not necessarily or entirely true... Even the Coin Spun Off From (e.g., Ethereum) WILL get dumped, by some, to purchase the new Spun Off Coin, thereby, punishing True Technology Innovators...

The solution that addresses this concern is simple... Include both Bitcoin and Coin-Spun-Off-From Holders in the Initial Distribution...

1 - Not to include them Establishes a Perverse set of Incentives for future Innovators... Here's one example...

"We provide Technology Innovation and we Want to be Open Source, but if we Are Open Source, the Coin we develop can/will be Spun Off to our detriment."

On the other hand, an Initial Distribution that includes holders of the Spun-From-Coin establishes a Virtuous Spiral of Incentives...

"We provide Technology Innovation and we Want to be Open Source. And if we Are Open Source, our work can be leveraged by others and we can benefit from others' work in the future that builds on our work."

2 - Not to include them leaves the entire Spinning Off Project subject to attack for a valid reason...

"The people doing the project Merely Represent Large Bitcoin Holders and the project represents the effort of those holders to increase their already existing wealth by Ripping Off those who work on future Tech Innovation."

Okay, in some trivial sense all lost bitcoins are already excluded from the altchain, because any corresponding altcoins can never be claimed. 

But the important thing, as far as I'm concerned, is that there needs to be some point in the future when potential investors can stop caring about whether or not they still include those potential coins in their analyses.  The simplest way to do that is with some kind of claim window, where if it's not claimed by some particular time it won't be claimed, but that's certainly not the only way to do it.

F'rexample you could also do it with an inflationary model.  Let's say some altchain spins off all twelve million or whatever it is right now Bitcoins, and then sets up a block reward that distributes 1.2 million new altcoins this year and increases it by ten percent annually.  In the long run, they converge on ten percent money supply inflation.  And that means that the unclaimed coins become a ten percent less significant part of the money supply every year.  Meaning, seven years approximately to halve their value, another seven to quarter it, another seven to make it the eighth part, and so on.   So, thirty years on, the unclaimed coins are such a small fraction of the money supply that they don't mess up the analysis any more.

Or you could have a diminishing claim, where the longer it takes someone to get around to claiming their coins, the less they actually get.  That's essentially the same idea, just using a different set of numbers. 

My first reaction is that the best solution is a fixed subsidy per claim tx that gets added to the block subsidy (if any).  This would be additional "minting" but the money supply would still remain finite (if that is desired) as the number of claims is finite.  


Yes but the user would need at least one unspent output referencing the particular ScriptHash that is in the snapshot ledger.  As a side note this would apply to any output type as well.  If the user has no unspent outputs referencing that identity* with which to create a transaction he would need to send some coins (any valid amount) to that P2SH address.  

This could be potentially confusing to users however I see a ClaimExplorer along the lines of blockchain.info or blockexplorer as a method to aid users.


Agreed.  Obviously the best solution is one where clients (or at least one major client) makes it easy to add an OP_RETURN output to a transaction.  Given the dislike by the core team regarding the use of OP_RETURN I don't see this happening in the Bitcoin Core but possibly in other wallets.

A potential workaround would be to use a third party application to create the raw unsigned transaction.  User supplies a bitcoin address, third party verifies there is an available claim (possibly checking multple spinoffs), and returns a raw transaction which user could use client to sign.  There is an element of trust involved but it is manageable.  One option would be to make this a function of the same open source software which generates the initial ledger.  A simpler option would be to at least make the snapshot software have the ability to decode raw Claim Request Txs into plain english.


This is one place I would advocate address reuse.  If A & C are the same address those lines can be dropped from the warning.