Hey all,
Vitalik Buterin, founder here.
I would like to ask the community for opinions on a few technical issues around the Ethereum protocol:
1. Should numbers on the stack be bounded to 2^256 as they are now or unbounded? If they are unbounded, the cost of operations and the memory fee would of course be variable; I'm thinking k + c * bytes ^ 3 as the structure for the fee for pushing a value onto stack or memory. The advantages in favor of bounded are:
* Contract creators can count on the fact that the cost of a single operation is bounded
* Reduced risk for security holes in contracts
* Much simpler fee structure
* Reduced risk of implementations getting corrupted with very big integers (eg. what if someone's bigint library does not support more than 1 MB in an integer); however, the c * bytes^3 component should make such attacks infeasible in practice.
The arguments in favor of unbounded are:
* No need for kludges such as SDIV, SMOD and my implementation of SHA256, since negative numbers can be supported.
* You can do RSA crypto inside of contracts that way
* RLP supports unbounded numbers anyway
* Goes with the protocol's general ethic of Pigovian fee regulation only without hard limits
2. Encoding for addresses
Right now, I am thinking of considerably simplifying the encoding for addresses from Bitcoin's. Specifically, Bitcoin works as follows:
hash160 = ripemd160(sha256('04'+pubkey_x+pubkey_y))
hash160wcheck = 'x00' + hash160 + sha256(hash160)[:4]
address = base58encode(hash160wcheck)
I'm thinking
hash160 = sha256(pubkey_x+pubkey_y)[12:]
hash160wcheck = hash160 + sha256(hash160)[:5]
address = base32encode(hash160wcheck)
Where base32encode is an implementation of Zooko's version of base32:
http://philzimmermann.com/docs/human-oriented-base-32-encoding.txtAdvantages of my way:
* Makes Ethereum more distinguishable from a marketing standpoint with different-looking addresses
* base32 is slightly simpler to implement since it can be done 5 bytes at a time'
* JS libraries only have to include one hash (sha256), not two, of which one is rather obscure (ripemd160)
* No reason to have the '04' in the hash since that's just for serialization in Bitcoin and in Ethereum we're never serializing pubkeys
* Addresses become easier to read out since you do not need to memorize capitals vs lowercase, and Zooko's more restrictive alphabet further reduces the chance for mistakes
Advantages of existing way:
* BTC addresses can be directly converted into ethereum addresses
* Base58 is slightly more compact (34 chars vs 40)
* People can copy code from BTC libraries rather than using ethereum libraries
Note that there are possible compromises here (eg. remove the '04' and the RIPEMD but keep the base58).
If we can get some discussion going on this stuff that would be great.
Comments
2.) I believe it would be extremely important to support the existing developers for bitcoin in the ethereum protocol. Many advantages of your way are minor in terms of utility and personally I believe the ability to port over BTC libraries will help drive community support/development a lot more than your way. However my stance on this is definitely arguable, I am just a fan of having the community of bitcoin developers be able to port their code to the ethereum protocol with ease.
For (2), we are likely going with the non-Bitcoin approach though; the reason is that we're switching to sha3 as our main hash in place of sha256 and ripe160, so there's no real possibility for backwards compatibility in any case. But we are still using secp256k1 so there is full compatibility on that side.
For (1), limited size ints do seem to make more sense at this point.
I'm just spewing out conceptual thought but I honestly think I might be on to something.
What are you proposing as the block time?
How many ether per block and at what rate will it decrease.
I'm trying to think of away to implement a block time and ether amnt based in a naturalistic or Darwinian economic perception.
Does it have to be a constant time and amount?
What would happen if it was dependent on the amount and rate of transactions. What if miners were able to mine blocks quicker holding a lower amount of transactions thus receiving a lower out of ether. Maybe my strategy of mining would be more conservative with less transactions with lower ether amounts and your be more risky aiming for new densely filled blocks with greater reward.
So what's would be the variables
Speed and memory. Maximum amount of transactions allowed in a block(this could be based on a time limit of how long a transaction could be unconfirmed. )
Maybe a Maximum of 10 minutes but a quicker miner picks you up maybe it will take a minute aka a rapid miner.
Quantity and rate of transactions taking place? Maybe no maximum amount of transaction per black but simply a time limit, you want to hold off longer and shoot for that 10 minute mark an fill up the block to reach an ether max that's fine but of you get greedy as the clock ticks someone might crack it at 9 minutes.
Miners waiting longer timers would have more advanced computers possibly?
This would allow for little guys to still mine ether.
Could mining also be on a linear curve. Or multiple curves.
Eventually miners will be able to look at the current amount and rate of ether transacting and based on twit computers abilities discover their equilibrium point which of course will be constantly evolving
How can mining become alive.
60s
> How many ether per block and at what rate will it decrease.
Linear forever. Ether per block depends on how much we raise in the fundraiser.
I can't find much on sha3 and quantum computing; it looks like the mechanism hasn't been well researched yet.
Inre: addresses, I would urge an address format that makes for easy regexes -- perhaps just some id characters around the address? I agree it's nice to have something that visually scans as 'ether'.
All hash algorithms are invulnerable to polytime quantum algorithms (eg. Shor's, which breaks factoring and elliptic curve cryptography) but are vulnerable to Grover's algorithm. So composing hashes doesn't really have a benefit.
> K let me know when the fundraiser is
Jan 25
Back to ethereum. Nice to see the predictions on Dagger, because current "CPU-coins" have shown weaknesses towards GPU or other specialized hardware. I try to abandon the use of proprietary software and do not use proprietary drivers for my GPU and use cloud servers to mine coins. I know you probably can not say this for sure and only predict to the best of your knowledge so forgive me for asking, but will Dagger remain CPU-only or will it still be possible that GPUs with proprietary drivers will outperform CPU/free drivers by a small but none the less irritating level towards the free software community?
Looking at Dagger now, I have to admit that GPUs may be slightly better; the reason is that my holy grail of 500 MB is nonviable since we do need one round of mining to take a few seconds and not an hour. But it will still be considerably better than Scrypt.
Just mentioning this. No idea if it is any better or worse than dagger.
1) the stack be bounded to 2^256 to be unbounded
2) your way in simplifying the encoding for addresses from Bitcoin
My input follows the trend here:
(1) Bounded numbers are fine. As for SDIV and friends, it does sort of suck to proliferate two versions of all the opcodes that need it, but x86 did it and managed to survive. I think ethereum asks enough big questions without also asking "what could go wrong with unbounded registers?". Is it actually impossible to do RSA crypto without unbounded stack elements?
(2)
>* BTC addresses can be directly converted into ethereum addresses
I'm not sure I understand what the advantage is here.
>* Base58 is slightly more compact (34 chars vs 40)
z-base-32 has other advantages that IMO are worth the 6 bytes. (Either would be an improvement from the current (as of POC-4 at least I think) ethereum addresses, which have no ergonomic encoding at all.
>* People can copy code from BTC libraries rather than using ethereum libraries
This is pretty much trivial, right? If your application interops with ethereum, then using the appropriate library, reference code, or spec is not a huge barrier. You wrote the code for everyone to discuss above, it's really just three lines.
@peterv Mentioned the presence of ripemd was a defence against quantum attacks, to which you correctly responded that it made no real difference for hashes. My understanding of the relationship between these issues is that if you assume a quantum computing attacker, then hash composition leaves you in a better spot, allowing a buffer for when one of the hash algos falls to some future attack. I am under the impression that this is why bitcoin does things this way, but I could be wrong.
(2) You can publish one pubkey, and that pubkey can simultaneously produce a Bitcoin address, a Litecoin address, a Dogecoin address, etc. If we keep secp256k1 the pubkey will also give you an Ethereum address.
(3) The final intent is to use namereg as the primary usability gain. But I probably will create an advanced encoding using SSSS for addresses, with support for encoding a messaging format into an address for sub-currencies. z-base-32 sounds like the way to go.