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)
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.txt
Advantages 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.