| > oh you just don't understand why this is a good thing That wasn't my intent at all. I don't think it's a good thing; I just think it's a predictable thing. I was trying to justify it like you'd justify the actions of someone with a mental illness, or like you'd justify an evolutionary adaptation. To "feel the flow of the causal process that resulted in this" (which isn't just the designers not being "fully aware of how it would be used.") Most people, I find, who are put off by Ethereum's design, don't actively dislike the design; they just find it hard to understand the motivation for its design decisions, finding them obscure. That's what I was trying to help with, there. It's perfectly okay to understand that motivation and then dislike Ethereum. I do too! (I haven't seen a genuinely good distributed-computation substrate yet, though. Have any recs?) > There are many many if-statements with this logic to handle the multitude of edge cases that come up from using the same address namespace for person-addresses and contracts Eh, that's more a fact of the implementations than the design, I think? You could theoretically treat every EVM CALL op as always executing bytecode, with regular addresses being wrapped in an ADT that, when asked for their bytecode, returns a zero-length string; and an EVM interpreter that, when asked to execute a zero-length bytecode string, does so successfully at a cost of zero gas. IIRC, there's nothing in the yellowpaper constraining them from writing the code this way. Whoever wrote the code is just a bunch of mooks who don't understand data-primacy and eliminating (cyclomatic) complexity. > because checking if a sender is person or contract is not trivial I'm not too familiar with what is and isn't exposed in Solidity, but at the EVM level, isn't that just 𝑒 ("the present depth of the message-call/contract-creation stack")? If 𝑒=0, a human (or a human/bot oracle) called you; if 𝑒>0, another contract called you. > And for your idea of a contract having multiple addresses, what would be the purpose of this? There really isn't a legitimate purpose in a contract having access to multiple [pretend-]signing identities, given that you can always construct a system of contracts that message one-another to accomplish the same task. The point of my thought was to achieve parity between smart-contract oracles and human/bot oracles, insofar as human/bot oracles can sit there and do things in response to anything happening on the blockchain they're watching, not just something happening to an address they own. Theoretically, contracts could be allowed to subscribe to any log event stream that a node can subscribe to, such that, after any 𝑒=0 call which generated logs successfully returns, the EVM would then be required to run all contracts with active subscriptions that match the logs just written into a transaction receipt, with those contracts paying the gas out of their own accounts to run. |