1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A603125B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 20:59:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com
[209.85.217.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8ABED106
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 20:59:29 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so45184141lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 13:59:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=Kz2nzwBcRJM//EIgdMrAMEGAn52wirVFPmCqOrPMu3c=;
b=Q6Q0vdJksTqsqiOOBxkk6Sc96ZluWrLHVzX1r/FO7mJglsBimwe1646SArEIWT1MWO
2aaBMrkziAeA6r2Qe137AiL86/wLOcaX6Y3uwEDRhUFbHxgwotYE7IwJAGOYB87gD0j3
ctjJXYJJ25t19XnjA8oAZ/3WiuGJJpZZBa00rzauDRLvCSqske3ZE5T9LUpFZIUmkIzI
+SvTJIlfoy8jgOP0L3cq7fMSjCUd90KN04axMmyhWbs5i50/ByKngCcJg3L9kBeXl9KQ
wvf8U8mJI9Y5jKVM1so8sxiAM4Ttk+vOTMVy5joPagISLxB7Ndsehsdx1/rTaT8eLdMq
y2/A==
X-Gm-Message-State: ALoCoQkfM/ZwvLl4GNM9eq8SvNqWhmZLsTRzNDmQmWq4+s+Wf+xon7uAlXdgCj5Yyko+Jmewjs7B
MIME-Version: 1.0
X-Received: by 10.152.21.196 with SMTP id x4mr7091713lae.117.1440881967908;
Sat, 29 Aug 2015 13:59:27 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Sat, 29 Aug 2015 13:59:27 -0700 (PDT)
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
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Variable Block Size Proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Aug 2015 20:59:30 -0000
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
|
