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

[smooth]

I voted yes. 

It's bad enough to have the 'lost coins' issue with Bitcoin, where investors never know whether those ancient coins are dead or just resting.  I don't want to import dead coins and lost keys into an altchain.

Then by Peter R's definition it isn't a spin-off. Right or wrong you are making a value judgement giving your alt coin having a "better" initial distribution than BTC.

[1715009792]

1715009792

[1715009792]

1715009792

[thoughtfan]

I know we're only at the beginning stages of the required coding but I'd like to throw in a further consideration:

I understand part of the impetus for developing this idea was the premine issue with Ethereum - hence the æthereum proposal.  However, given the magnitude of the investment in Ethereum it is likely at least some in the Ethereum team are very unlikely to be welcoming of æthereum which potentially undermines their investment.  

May I propose therefore that a potentially co-operating dev team be approached first who are working on an altcoin where there's a fair chance they might embrace the spin-off idea for launching or re-releasing their coin on the merits being put forward in this thread?  In this way at least to start with the coin dev team and the spin-off technology dev team would be working together rather than a more adversarial relationship that is likely to ensue with spinning-off Ethereum.

[Peter R]

I know we're only at the beginning stages of the required coding but I'd like to throw in a further consideration:

I understand part of the impetus for developing this idea was the premine issue with Ethereum - hence the æthereum proposal.  However, given the magnitude of the investment in Ethereum it is likely at least some in the Ethereum team are very unlikely to be welcoming of æthereum which potentially undermines their investment.  

May I propose therefore that a potentially co-operating dev team be approached first who are working on an altcoin where there's a fair chance they might embrace the spin-off idea for launching or re-releasing their coin on the merits being put forward in this thread?  In this way at least to start with the coin dev team and the spin-off technology dev team would be working together rather than a more adversarial relationship that is likely to ensue with spinning-off Ethereum.

I think some feathers are going to be ruffled no matter what.  If the spin-off concept works and tends to outcompete the original, then many non-spin-off alt-coins are already at risk--they just don't know it yet.  It seems to me that since we are going to find out eventually, we might as well find out sooner so that our community can confidently direct their efforts towards projects more likely to bear fruit.

It's been suggested a few times that a spin-off employing Cryptonote technology be pursued as a pilot study; however, the Monero launch was one of the more legitimate I've seen so I don't like the idea of potentially undermining their efforts.  However, I'm not convinced that doing this actually would be undermining anyone's efforts!

For example, Tacotime (MRO dev) would be in ideal position to execute this plan, and could very likely profit should it be successful by mining blocks shortly after launch while difficulty was low.  If the spin-off later seemed doomed to fail, then by dumping the spin-off it would strengthen his MRO holdings.  If the spin-off seemed destined to outcompete the original, then by dumping his MRO he can expedite the collapse thereby strengthening his spin-off holdings. 

If you believe that the strong privacy offered by ring-signatures is genuinely useful, then why wouldn't you want to support the most legitimate implementation of that technology (whatever the market proves that to be)?   

[DeathAndTaxes]

Updated the Simplified Claim Verification (SCV) proposal https://bitcointalk.org/index.php?topic=563972.msg7122252#msg7122252

I will continue to update and expand the post as time permits.  Beyond the SCV I think a more complete analysis of the UXTO is useful so I will be adapting an existing block parser to that purpose.  It will have to wait until next weekend as I will be offline this weekend.  I promised my wife a real vacation.

[Peter R]

Then by Peter R's definition it isn't a spin-off. Right or wrong you are making a value judgement giving your alt coin having a "better" initial distribution than BTC.

I'm still struggling a bit here.

My original (half) proposal was simple and easy with the bitcoin-signed "claimto <address>" messages.  The trouble was that it only remained "simple" for pay2PubKeyHash and pay2PubKey outputs.  Although these represent ~99.5% of unspent outputs by count, they likely account for a smaller fraction by balance since the important pay2ScriptHash-type outputs are omitted.  My original technique is suitable for spin-offs launched with or without a claim window.  

Gerald's elegant solution allows for >99.9% of outputs (by count) to be claimed including the important pay2ScriptHash type (many of which likely have large balances), while completely eliminating signature verification by the spin-off clients.  However, this technique is most suited to spin-offs launched with a claim window.  

Ensuring that 100% of spendable bitcoins are claimable on the spin-off network greatly complicates the spin-off client and bloats the genesis block.

So what do we do?


D&T: don't let her catch you checking bitcointalk.  I always get busted  

  

[smooth]

My comment was not so much directed at the claim window as the stated intent to exclude possibly lost coins.

As for the claim window, I continue to believe it is redistributionary in a way that is fundamentally incompatible with the original proposal especially with respect to btc specifically as the parent (due to satoshis coins though of course not exclusively that). However elegant d&t's approach might be, it is an elegant solution to a different problem.

[DeathAndTaxes]

  - Same idea as above but to incentivize miners to scan the bitcoin blockchain for claim-txs (you alluded to this).  Perhaps the miner could only reward himself the full coinbase reward if a certain number of claim-txs were included.  (I am wondering if a fixed subsidy is better than a fee paid by the claimant to encourage users to make their claim and sufficiently-motivate miners to scan the blockchain).

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.  

  - Imagine that a user has 10 BTC in a P2SH multisig wallet.  Assume that the user transfers these 10 BTC to a new address after the snapshot was taken but without making a valid claim using OP_RETURN.  Can the user still make his claim?  (I think the answer is "yes" but I just wanted to make sure).  

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.

  - Advanced users will be able to include the required OP_RETURN bytes to make a valid claim-tx; however, less sophisticated users will need simple tools on the bitcoin-wallet side to make this happen.  I don't think this is necessarily a problem, but I thought I should point it out.  

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.

Validating raw Claim Request ...

WARNING:  Read the following careful to ensure your Claim Tx is valid before signing the transaction with your Bitcoin client.  The claim process is irreversible and if incorrect can result in the loss of your bitcoins and your spinoff claim.

You are redeeming the claim assigned to Bitcoin address A for SpinCoins in the amount of 9450 SPC.
The transaction will transfer your claim of 9450 SPC to SpinCoin Address B.
The transaction also transfers 0.123 BTC to Bitcoin Address C.  

You should ensure you have the appropriate private keys for SpinCoin Address B.  If you do not have the corresponding private key for SpinCoin Address B you will permanently lose your claim of 9450 SPC.
You should ensure you that Bitcoin Address C is an address in your Bitcoin Wallet.  If you do not control this address, you will permanently lose 0.123 BTC.

For more information please visit spinoff.orz

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

[Cryddit]

My comment was not so much directed at the claim window as the stated intent to exclude possibly lost coins.

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. 

[bitAsp]

Talking points...

• It seems to me that the context has now changed because of the emergence and significance of Darkcoin. Darkcoin appears to have a well-design architecture for promoting anonymous transactions whereas Bitcoin does not.
• Innovation, like that provided by Darkcoin, ought to be rewarded, and not punished
• Moreover, there is no Ethereum Coin in existence. Darkcoin already exists with significant new functionality in place. It is also under serious continuous development with serious a serious technology team leadership.
• So... what about a new Coin that is a Spin-Off of Darkcoin, providing all the functionality that Darkcoin provides.
• And... the big question... What about the Initial Distribution... Well, the Initial Distribution would be divided equally among holders of Bitcoin and Darkcoin at some specific Date and Time.
• 50% of the Initial Distribution Size would be allocated to Bitcoin addresses. 50% of that same size would be allocated to Darkcoin addresses.

There are several benefits to this idea...

• This new Coin would be a demonstration that Technology Innovation is rewarded.
• Like aEthereum, this new Coin is a Fluff, Meme-Only AltCoin Killer. AltCoin holders will be selling their Fluff Coins to own the new Coin based on Darkcoin.
• Those holding Bitcoin own a percentage of a coin that provides for anonymous transactions.
• Those holding Darkcoin own a percentage of a Second Coin that provides for anonymous transactions.
• Darkcoin holders will not sell their Darkcoin, hence, doing harm to Darkcoin viability, because their holding DRK entitles them to ownership of the new Spin Off Coin. This is important because it would be a good thing that the Darkcoin Development Team has even more motivation to Innovate.

A final benefit... We don't have to wait for Ethereum to appear on the scene to put Peter R's great idea to the test...  

Thoughts?

Darkcoin needs to prove itself I think it is still too early to know untill it's been hacked at a bit.

I understand darkcoin uses the coinjoin idea and as a result creating a spin off would require some way of publicly knowing the address so it won't be easy to prove the spin off is open and honest.
 
An innovation like darkcoin if truly better would not need a spin off the market would transfer value. DRK has a long way to go before this happens.

Still if I understand you, given darkcoin's level of anonymity, when it's open sourced Bitcoin could be spun off to make a darkcoin with Bitcoin distribution.

This thread hadn't seen a lot of action in a while before I posted the idea above. And I haven't been back since my post. Don't know if others have addressed issue...

I think the idea of SpinOffs as Fluff AltCoin Killers is a great one. That said, let me restate my concern more simply...

Let's say æthereum was SpunOff from Ethereum and the initial distribution was made only to BTC holders as discussed up thread. This could be done, only and precisely because the Ethereum Code was Open Source.

Issues:

• Why "reward" only BTC holders and not also Ethereum holders?
• At the release date of æthereum, wouldn't Ethereum holders be tempted to sell their Coin to purchase the Spun Off Coin, thereby, in effect, punishing, in the marketplace, the Ethereum Developers for their Innovative work?
• Suppose the æthereum Coin performs better in the marketplace than the Ethereum Coin. Over time, wouldn't Not rewarding Ethereum Holders in the Initial Distribution DISCOURAGE those developing new Technology Innovation from making their Code Open Source?
• As important, if Ethereum Holders were included in the Initial Distribution, the Ethereum Dev Team would have an incentive to work closely with the æthereum Dev Team while they enhance the functionality of Ethereum. The rollout of that same, new, great functionality in Ethereum would go much smoother for æthereum

[bitAsp]

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.

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

[jonald_fyookball]

Seems fair.

[DeathAndTaxes]

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

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.

[DeathAndTaxes]

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?

[bitAsp]

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

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.

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.

[bitAsp]

It's been suggested a few times that a spin-off employing Cryptonote technology be pursued as a pilot study; however, the Monero launch was one of the more legitimate I've seen so I don't like the idea of potentially undermining their efforts.  However, I'm not convinced that doing this actually would be undermining anyone's efforts!

For example, Tacotime (MRO dev) would be in ideal position to execute this plan, and could very likely profit should it be successful by mining blocks shortly after launch while difficulty was low.  If the spin-off later seemed doomed to fail, then by dumping the spin-off it would strengthen his MRO holdings.  If the spin-off seemed destined to outcompete the original, then by dumping his MRO he can expedite the collapse thereby strengthening his spin-off holdings.  

If you believe that the strong privacy offered by ring-signatures is genuinely useful, then why wouldn't you want to support the most legitimate implementation of that technology (whatever the market proves that to be)?    

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

[YarkoL]

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?

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.

[DeathAndTaxes]

The claim, by Peter R, that a Bitcoin Holders only Initial Distribution, is the Efficient Distribution... is nothing of the sort...

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.

[knightcoin]

10% ...

[Peter R]

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?

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.

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. 

[jonald_fyookball]

The claim, by Peter R, that a Bitcoin Holders only Initial Distribution, is the Efficient Distribution... is nothing of the sort...

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.

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.