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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 574F883D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 23:45:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 751A8EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 23:45:10 +0000 (UTC)
Received: by wicgi11 with SMTP id gi11so30542987wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 16:45:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=JX8eRNkJLZvo7hgxqlEj9mcCePblp5qRMpCzDYG2n+0=;
b=M25awFJ5RPrRZqlIQloW+vltFXwZvZaSLbrmpO+NWxWaxnYNctydGQXLZ7QZ4a+cLg
+gTu0//QpKEVfqyl51bmGETyxoPe+gFV7tX5nmWcogirjfecZFPJFgZfBOKck3+lr7/F
uXYaUojoCLjZLmlKXObHH/d3yKNBmRYh7SjBhc5+NdoJh3mWolXtwf3PltRYvO/XuPsz
Bvoc8uXVAkDClE12oMwp9Zg51Wv7/4kJ/6dPGkNtyIaKdUHzeLd8CCA7/8IvL3b0QZ09
7GScQZytCAs4PgR3NJyb8Iy16l5RH0XnVvrgKVvfNNtdel2gKiodfCM8KZXXuio1ed21
3bOQ==
MIME-Version: 1.0
X-Received: by 10.194.100.42 with SMTP id ev10mr40799402wjb.50.1435707909290;
Tue, 30 Jun 2015 16:45:09 -0700 (PDT)
Received: by 10.194.137.38 with HTTP; Tue, 30 Jun 2015 16:45:09 -0700 (PDT)
In-Reply-To: <CAGpx8BXMfUSaW1FONsbR4dK-uvQ73TjGuh5PUzsxJVwVUW3O1A@mail.gmail.com>
References: <CAGpx8BXMfUSaW1FONsbR4dK-uvQ73TjGuh5PUzsxJVwVUW3O1A@mail.gmail.com>
Date: Wed, 1 Jul 2015 01:45:09 +0200
Message-ID: <CAPg+sBj2P6ZUxJyrn3Dq76USO5kDTfpkF-zuYsKQbpQbTnyq2A@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Grigor <peter@grigor.ws>
Content-Type: multipart/alternative; boundary=089e0160aa48ef41f60519c4cb76
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A possible solution for the block size limit:
Detection and rejection of bloated blocks by full nodes.
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: Tue, 30 Jun 2015 23:45:11 -0000
--089e0160aa48ef41f60519c4cb76
Content-Type: text/plain; charset=UTF-8
The problem with this approach is that you need 100% exact behaviour for
every node on the network in their decision to reject a particular block.
So we need a 100% mempool synchronization across all nodes - otherwise just
an attempted double spend could result in a fork in the network because
some nodes saw it and some didn't. And actually, if we had 100% mempool
synchronization, we wouldn't need a blockchain in the first place, because
we could just use "first to enter mempool" as validity criterion.
On Wed, Jul 1, 2015 at 1:41 AM, Peter Grigor <peter@grigor.ws> wrote:
> The block size debate centers around one concern it seems. To wit: if
> block size is increased malicious miners may publish unreasonably large
> "bloated" blocks. The way a miner would do this is to generate a plethora
> of private, non-propagated transactions and include these in the block they
> solve.
>
> It seems to me that these bloated blocks could easily be detected by other
> miners and full nodes: they will contain a very high percentage of
> transactions that aren't found in the nodes' own memory pools. This
> signature can be exploited to allow nodes to reject these bloated blocks.
> The key here is that any malicious miner that publishes a block that is
> bloated with his own transactions would contain a ridiculous number of
> transactions that *absolutely no other full node has in its mempool*.
>
> Simply put, a threshold would be set by nodes on the allowable number of
> non-mempool transactions allowed in a solved block (say, maybe, 50% -- I
> really don't know what it should be). If a block is published which
> contains more that this threshold of non-mempool transactions then it is
> rejected.
>
> If this idea works the block size limitation could be completely removed.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e0160aa48ef41f60519c4cb76
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The problem with this approach is that you need 100% exact=
behaviour for every node on the network in their decision to reject a part=
icular block. So we need a 100% mempool synchronization across all nodes - =
otherwise just an attempted double spend could result in a fork in the netw=
ork because some nodes saw it and some didn't. And actually, if we had =
100% mempool synchronization, we wouldn't need a blockchain in the firs=
t place, because we could just use "first to enter mempool" as va=
lidity criterion.<br></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Wed, Jul 1, 2015 at 1:41 AM, Peter Grigor <span dir=3D"ltr">&l=
t;<a href=3D"mailto:peter@grigor.ws" target=3D"_blank">peter@grigor.ws</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div s=
tyle=3D"font-size:12.8000001907349px">The block size debate centers around =
one concern it seems. To wit: if block size is increased malicious miners m=
ay publish unreasonably large "bloated" blocks. The way a miner w=
ould do this is to generate a plethora of private, non-propagated transacti=
ons and include these in the block they solve.</div><div style=3D"font-size=
:12.8000001907349px"><br></div><div style=3D"font-size:12.8000001907349px">=
It seems to me that these bloated blocks could easily be detected by other =
miners and full nodes: they will contain a very high percentage of transact=
ions that aren't found in the nodes' own memory pools. This signatu=
re can be exploited to allow nodes to reject these bloated blocks. The key =
here is that any malicious miner that publishes a block that is bloated wit=
h his own transactions would contain a ridiculous number of transactions th=
at *absolutely no other full node has in its mempool*.</div><div style=3D"f=
ont-size:12.8000001907349px"><br></div><div style=3D"font-size:12.800000190=
7349px">Simply put, a threshold would be set by nodes on the allowable numb=
er of non-mempool transactions allowed in a solved block (say, maybe, 50% -=
- I really don't know what it should be). If a block is published which=
contains more that this threshold of non-mempool transactions then it is r=
ejected.</div><div style=3D"font-size:12.8000001907349px"><br></div><div st=
yle=3D"font-size:12.8000001907349px">If this idea works the block size limi=
tation could be completely removed.</div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--089e0160aa48ef41f60519c4cb76--
|
