MIME-Version: 1.0
In-Reply-To: <CADL_X_emr1Dc-+Da4fDnu1DrtK+QHGFX022icV0fzKqqEGZBwg@mail.gmail.com>
References: <55E145EF.3060801@gmail.com>
	<CADL_X_emr1Dc-+Da4fDnu1DrtK+QHGFX022icV0fzKqqEGZBwg@mail.gmail.com>
Date: Sat, 29 Aug 2015 22:59:27 +0200
Message-ID: <CABm2gDo_==iAZ5Ud8djJyR_BdqFcg9S59ufWFsrmkPApvW2D7Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Jameson Lopp <jameson.lopp@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Variable Block Size Proposal
Precedence: list

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