Nick Szabo  🔑

Rather, these initiatives will each be phased (e.g. @realLedgerwatch's rent proposal has six phases) and, while the June target is somewhat arbitrary, we do want a sense of urgency. We will meet in January and discuss dates again at that point, but I'm all for deadlines.

We had *very* in-depth, productive dialog and debate about each proposal. Looking forward to sharing the notes shortly and dissecting and discussing them with the community on @EthMagicians forum.

There was an impassioned plea for us to save the network from unbounded state growth, especially in light of a likely ability to increase tx throughput by as much as 10x, which would cause it to explode and cause the network to shrink to a centralized core of nodes.

And one way to frame this is that, while rent is a stick that would have clear UX impacts, a ~10x increase in tx throughput is a carrot that's incredibly valuable, and is a tradeoff that the community may be willing to accept.

There are a *lot* of unsolved challenges around data availability, if we break the existing invariant (*not* specified in the yellow paper, however!) that all block headers, bodies, receipts, and logs are always available within the existing P2P network.

Finally, multiple folks brought up concerns about avoiding a technocratic decision-making process and ensuring that we have community buy-in before moving forward with any of of these proposals, esp. something as controversial as rent.

An abuse of the word "community". Ethereum users are far too diverse and unknown to the developers for anything resembling a community (a group of people regularly communicating with each other) and there's little you can learn about in what ways you do and do not have buy-in.

If you want Ethereum to be a true world computer it must scale socially, i.e. behave in a manner trustworthy to as many diverse users in diverse parts of globe as possible, not merely geographically (just a few dozen English-speaking mutual acquaintances in a handful of cities).