We shouldnt lose track of the aspect that miner's interests are not directly aligned with user interests. Users want security, decentralisation properties and reasonably cheap fees, miners profit from fees. Particular miners may profit from centralisation. Miners are in competition with each other in a complex game.
We could do with some analysis on Jeff's BIP and Greg Maxwell's flexcap (or Meni Rosenfeld's somewhat similar pay for size variant) -- and Gavin's proposal of what miner game-theory is anticipated and how the proposals hold up under those attacks. In Gavin's proposal why would we assume that 8MB wont be used? Or the huge 8GB later. It is free even for a miner to create blocks of any size up to the cap (zero fees or fees paid to himself). The stale rate of propagation delay maybe hidden by the relay-network or by collusion, or advantage of a miner already knowing its own block. Will a group of network topology close miners try to create big blocks that disadvantage other miners? Or will miners keep blocks small to extract switching-cost fees from users. (Regardless of cap). Jeff's proposal has a cost free miner vote for cap increase with a 25%-ile and 90% threshold. But in the second attack (keeping blocks small) it alternatively becomes easy for an advantaged 10% to force the block to stay small, in order to extract switching cost fees from users. Maybe users really love the decentralised features of bitcoin and are willing to pay a lot! Of course overlaid as Jeff observes by meta-incentive that miners need to sell mined bitcoin to pay electricity bills, and want Bitcoin to be in demand and therefore indirectly to satisfy user demand. But that may still result in a fair bit of switching cost. Switching cost economics is common in many networks. I submit that in terms of robustness of mechanism assuring security, it be ordered something like: 1. consensus rule 2. aligned economic interest 3. attack requires miner collusion 4. meta-incentive Then we could evaluate proposals for how robustly they can enforce user interests vs miner game-theory attack or collusion scenarios. Adam On 23 June 2015 at 09:59, Ross Nicoll <[email protected]> wrote: > Also, before that's turned into "8MB blocks are infeasible", my presumption > is that blocks are not expected to jump suddenly to 8MB, and that most will > have time to ramp up storage and bandwidth. > > The point about not outright replacing existing test data is the more > critical one, anyway, although in retrospect we could simply add spam > transactions on top of existing transactions. _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
