[RFC] æthereum: a turing-complete coin distributed as per bitcoin's blockchain

[Peter R]

It's unfair if it requires controlling 0.001% of the bitcoin money supply to claim a share of æther.

0.001% of the bitcoin money supply = 130.54 bitcoins

That means you need $80812 worth of bitcoins in a single address to claim a share of æther!

Do you mean no matter how small a percentage of the bitcoin money supply you hold in an address, you can claim a share of æther equal to that percentage?

Thanks for pointing out the ambiguity.  I edited the post to state:

If you are a bitcoin holder, your share of æther is already secure.  For example, if you control 0.001% of the bitcoin money supply, those same private keys will allow you to claim 0.001% of the initial æther supply.  In general, if you control X% of the bitcoin money supply, you would be able to claim X% if the initial æther.

There will likely be a dust limit in order to minimize the file size of snapshot.bin, but even if you only have 1000 bits (0.001 BTC) you'll still be able to claim the corresponding amount of æther.

[bubble83]

What will you do with the percentage representing all the dust that you will not convert to æther?

Will you simply not create that percentage of æther, or do something else with it?

[Peter R]

What will you do with the percentage representing all the dust that you will not convert to æther?

Will you simply not create that percentage of æther, or do something else with it?

Analysis of the UTXO by DeathAndTaxes shows that setting the dust threshold at 100 bits (0.0001 BTC) means that 99.9999% of all bitcoin wealth is included, yet the snapshot.bin files size is reduced from approximately 3 million claims to approximately 2 million.  The remaining 0.0001% would simply vanish (it would be as though it never existed from the perspective of the aethereum blockchain).  

[cypherdoc]

What will you do with the percentage representing all the dust that you will not convert to æther?

Will you simply not create that percentage of æther, or do something else with it?

Analysis of the UTXO by DeathAndTaxes shows that setting the dust threshold at 100 bits (0.0001 BTC) means that 99.9999% of all bitcoin wealth is included, yet the snapshot.bin files size is reduced from approximately 3 million claims to approximately 2 million.  The remaining 0.0001% of the wealth would simply vanish (it would be as though it never existed).  

seems like such a waste. Its not like they're unspendable. In fact, they can be in circumstances where they've been accumulated in an address with multiple other UTXO's of larger amounts. A single spend which lumps all the UTXO's together along with the dust will allow them to be claimed.

Regardless, I understand that you're trying to reduce the size of the file. I only hope it's necessary.

[bubble83]

What about addresses on exchanges, do the exchanges get to claim those shares of æther?

[Peter R]

seems like such a waste. Its not like they're unspendable.

The full snapshot.bin file will allow for 100% of spendable (bitcoin) funds to be claimed in the spin-off network, including dust and including unusual raw script outputs.  We're just trying to understand the statistics for the UTXO set so that spin-off developers have the information they need to make efficient choices.  (For example, whether developers support claims of the very tiny set of raw-script outputs or whether they support claims from addresses that only contain dust is a choice they would need to make).  

D&T has shown that 99.9999% of the UTXO can be re-cast as either a P2PkH or a P2SH claim, resulting in a 72 Mbyte snapshot.bin file.  By including the remaining 0.0001% of outputs as uncompressed script, the snapshot.bin file format is lossless--all wealth distribution information is preserved.  Whether a spin-off developer supports 100% of claims (as opposed to 99.9xxx%) is implementation dependent.    

Comparing 72 MB to the approximately 1 GB uncompressed bitcoin UTXO set shows that the snapshot.bin file format has already made significant progress.  A small snapshot.bin genesis block is preferable because it's faster to download a 72 MB file than a 1 GB file (meaning users would be more likely to install the client software).  The rationale for potentially removing dust is so those claims don't have to sit in RAM forever (UTXO bloat is more resource intensive than blockchain bloat and the entire snapshot.bin file is effectively part of the UTXO set).  

A single spend which lumps all the UTXO's together along with the dust will allow them to be claimed.

This is exactly how the UTXO set was analyzed.  If a single claimer (e.g., a single address) controls a bunch of dust combined with (e.g.) a 0.1 BTC output, then this would appear as a single claim of (e.g.) 0.1000012 BTC.  Only addresses that contain a combined sum that falls below the dust limit would be at risk of removal, if a spin-off developer used dust filtering.  

[Peter R]

What about addresses on exchanges, do the exchanges get to claim those shares of æther?

If a private key controls x% of the bitcoin money supply at the blockheight where the snapshot was taken, then the entity that controls that private key can claim x% of the spin-off.  This entity could very well be an exchange.  If interest in spin-offs becomes significant, then exchanges will be pressured to make there claim policy clear.  For example, they could claim the spin-off on behalf of their depositors and immediately credit the depositors' account with the claimed spin-off.  The exchange could charge a fee for this service.  

[smooth]

A small snapshot.bin genesis block is preferable because it's faster to download a 72 MB file than a 1 GB file (meaning users would be more likely to install the client software).

If it is a full client (and in practice many altcoins rely on full clients at least early on), then the difference is not so great because new users will need to download a block chain as well. That plus the software itself will rapidly eclipse 72 MB.

Now, maybe 1 GB is a lot (that might be years of blockchain on a lightly-used coin), but something more than 72 MB can certainly work.

[Peter R]

A small snapshot.bin genesis block is preferable because it's faster to download a 72 MB file than a 1 GB file (meaning users would be more likely to install the client software).

If it is a full client (and in practice many altcoins rely on full clients at least early on), then the difference is not so great because new users will need to download a block chain as well. That plus the software itself will rapidly eclipse 72 MB.

Now, maybe 1 GB is a lot (that might be years of blockchain on a lightly-used coin), but something more than 72 MB can certainly work.

Agreed.  For this reason it probably makes sense that the snapshot.bin genesis block for any spin-off contains a record of 100% of the claimable funds.  Whether 100% is actually claimable (as opposed to 99.9xxx%) is still implementation dependent, as there are some subtle complicating issues.  

[smooth]

Agreed.  For this reason it probably makes sense that the snapshot.bin genesis block for any spin-off contains a record of 100% of the claimable funds.  Whether 100% is actually claimable (as opposed to 99.9xxx%) is still implementation dependent, as there are some subtle complicating issues.  

Maybe a full snapshot.bin is published somewhere as a Merkle tree but only the root hash need be distributed? To make a claim you post a proof that your claim is supported by an entry in the tree.

[Peter R]

Agreed.  For this reason it probably makes sense that the snapshot.bin genesis block for any spin-off contains a record of 100% of the claimable funds.  Whether 100% is actually claimable (as opposed to 99.9xxx%) is still implementation dependent, as there are some subtle complicating issues.  

Maybe a full snapshot.bin is published somewhere as a Merkle tree but only the root hash need be distributed? To make a claim you post a proof that your claim is supported by an entry in the tree.

Interesting.  

This proposal has the advantage that the spin-off genesis block is tiny in byte size and it has the advantage that the unclaimed entries in snapshot.bin need not be store in RAM on the client nodes.  A disadvantage is that the claim TXs are a lot bigger and the same inner hashes will get mined over and over (different claim TXs will share common inner hashes in their respective Merkle branches).  I see no reason why your proposal wouldn't work with both full-claim verification and simplified-claim verification.  The bridge nodes in Gerald's SCV proposal could optionally store the full snapshot.bin file so that they can prepare the claim TXs with the Merkle branch proof and then mine them into a block to earn a claim fee (assuming this fee exists).    

These are the kind of discussions we need to have to finalize the format for snapshot.bin.  

[defaced]

So we give the bitcoin whales all the aethereum? Rich get richer. ^_^

[JMAHH]

Please look into a different name. You must be aware the naming is confusing and will cause future complications. Save yourself the trouble.

[defaced]

Please look into a different name. You must be aware the naming is confusing and will cause future complications. Save yourself the trouble.

maybe that is the joke

[JMAHH]

Please look into a different name. You must be aware the naming is confusing and will cause future complications. Save yourself the trouble.

maybe that is the joke

I'm sure it is, but if this is to be viable currency it will need a viable name.

[Peter R]

Please look into a different name. You must be aware the naming is confusing and will cause future complications. Save yourself the trouble.

maybe that is the joke

I'm sure it is, but if this is to be viable currency it will need a viable name.

The idea behind æthereum is that it is identical in function to ethereum except for the initial distribution of credits.  You have to purchase ether whereas all bitcoin holders can claim æther for free using the spin-off method. 

I think the current name (æthereum) does a good job of communicating the fact that it's a clone. 

[seriouscoin]

When will the client be available for download?

Its not in OP so i assume it was never posted.

[U]

When will the client be available for download?

Its not in OP so i assume it was never posted.

Depending on ETH I guess.

[defaced]

Please look into a different name. You must be aware the naming is confusing and will cause future complications. Save yourself the trouble.

maybe that is the joke

I'm sure it is, but if this is to be viable currency it will need a viable name.

The idea behind æthereum is that it is identical in function to ethereum except for the initial distribution of credits.  You have to purchase ether whereas all bitcoin holders can claim æther for free using the spin-off method. 

I think the current name (æthereum) does a good job of communicating the fact that it's a clone. 

It does indeed.

[rapport]

Who are the people developing/maintaining this?  Surely that should be included in the FAQ in OP