From: "Jorge Timón" <jtimon@jtimon•cc>
To: Jameson Lopp <jameson.lopp@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Variable Block Size Proposal
Date: Sat, 29 Aug 2015 22:59:27 +0200 [thread overview]
Message-ID: <CABm2gDo_==iAZ5Ud8djJyR_BdqFcg9S59ufWFsrmkPApvW2D7Q@mail.gmail.com> (raw)
In-Reply-To: <CADL_X_emr1Dc-+Da4fDnu1DrtK+QHGFX022icV0fzKqqEGZBwg@mail.gmail.com>
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
prev parent reply other threads:[~2015-08-29 20:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-29 5:41 Justin M. Wray
2015-08-29 14:22 ` Jameson Lopp
2015-08-29 18:25 ` Justin M. Wray
2015-08-29 20:59 ` Jorge Timón [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABm2gDo_==iAZ5Ud8djJyR_BdqFcg9S59ufWFsrmkPApvW2D7Q@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jameson.lopp@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox