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

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!

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.  


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.  

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.   

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?

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.

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.

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

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

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

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

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

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

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

Now on to another topic:

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

        "claim to "

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


The roundabout answer:

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

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

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

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

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




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

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

       "claim to "

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

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