On Sat, Aug 29, 2015 at 4:22 PM, Jameson Lopp via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't think you'll find much support for introducing a mandatory minimum > block size. It's quite wasteful to "pad" blocks with transactions that the > miner is just sending back to themself. If you want to solve the block > propagation issue, I'd recommend instead working on O(1) block propagation.
O(1) propagation can never be achieved without a centralized topology. No matter how efficient of an IBLT (or similar) we implement, O(1) can only be achieved for transmitting a block between 2 nodes. The propagation time of a block across the whole network (or even to the miner's sub-network) will always depend on the concrete network topology. That's not to say that transmitting a block between to peers in constant time wouldn't greatly help with mining centralization concerns related the maximum block size, but I'm concerned about this incorrect "O(1) block propagation" meme keeps spreading. Even with ansibles [1] and safe zk-SNARKS [2] for constant time block validation (somehow removing the trusted setup), both of which are science fiction right now you need to verify the snark proof for every node receiving and relaying the block. At that point block propagation would be meaningless as a miner-centralization concern for not raising the maximum block size though: the minimum CPU costs for being able to mine profitably would be the next concern or "bottleneck". I completely agree with the minimum block size being inappropriate though. I don't even believe that the stated goals of the size minimum can be accomplished with it. [1] https://en.wikipedia.org/wiki/Ansible [2] https://eprint.iacr.org/2013/879.pdf _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
