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
|
Return-Path: <peter@grigor.ws>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 956F8B19
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 23:41:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com
[209.85.192.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 217C31BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 23:41:30 +0000 (UTC)
Received: by qget71 with SMTP id t71so11672414qge.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 16:41:29 -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:date:message-id:subject:from:to
:content-type;
bh=wcf0gJ/kYBsok+Co0q1gdg84Nvh4bnQcWE5S+BMp/wQ=;
b=hy4tecw3LTfxJZmhYKSTTA9+vviUXXlGfQo/uWMFDb+39nMm7TCh9KNKhbX0UfeomH
krCKHOqk8E/1iiJGJfft1/lYxsE115aGzE2Bm1spyJhdarIPbvsFndY+rdT9Xv67DfCg
oCdrwf9S/14ffjk2RwWKCOEC2BBW/vSAVt3MwBKnxz/LQiy1riMA6m+y9ix2DtBM5mM/
V/QxphlrjgUecqOEOGRbNbcgFYErwKxZLvBKLA4e2/LlWK4RJUyyk0jVvsWc9MkqJ3Hh
pjb4XLNV6DJYTy5LGSDBeEMDK9Ky6lgBcWeWVRmhFrf2HvgKM7Kmaxg2iwShFNZOnFn8
gYXA==
X-Gm-Message-State: ALoCoQkmdFfZnloormJP85NukLR7I8EV5N/+rC4B1KSkc2FrB5AYK7t1aRr+/lUrZ1ZWpHRTIKQO
MIME-Version: 1.0
X-Received: by 10.55.18.197 with SMTP id 66mr30808973qks.13.1435707689371;
Tue, 30 Jun 2015 16:41:29 -0700 (PDT)
Received: by 10.140.20.33 with HTTP; Tue, 30 Jun 2015 16:41:29 -0700 (PDT)
X-Originating-IP: [68.5.225.232]
Date: Tue, 30 Jun 2015 16:41:29 -0700
Message-ID: <CAGpx8BXMfUSaW1FONsbR4dK-uvQ73TjGuh5PUzsxJVwVUW3O1A@mail.gmail.com>
From: Peter Grigor <peter@grigor.ws>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11474faad3ad4f0519c4befa
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: [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:41:30 -0000
--001a11474faad3ad4f0519c4befa
Content-Type: text/plain; charset=UTF-8
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.
--001a11474faad3ad4f0519c4befa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-size:12.8000001907349px">The block size=
debate centers around one concern it seems. To wit: if block size is incre=
ased malicious miners may publish unreasonably large "bloated" bl=
ocks. The way a miner would do this is to generate a plethora of private, n=
on-propagated transactions and include these in the block they solve.</div>=
<div style=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-si=
ze:12.8000001907349px">It seems to me that these bloated blocks could easil=
y 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 mem=
ory pools. This signature can be exploited to allow nodes to reject these b=
loated blocks. The key here is that any malicious miner that publishes a bl=
ock that is bloated with his own transactions would contain a ridiculous nu=
mber of transactions that *absolutely no other full node has in its mempool=
*.</div><div style=3D"font-size:12.8000001907349px"><br></div><div style=3D=
"font-size:12.8000001907349px">Simply put, a threshold would be set by node=
s on the allowable number of non-mempool transactions allowed in a solved b=
lock (say, maybe, 50% -- I really don't know what it should be). If a b=
lock is published which contains more that this threshold of non-mempool tr=
ansactions then it is rejected.</div><div style=3D"font-size:12.80000019073=
49px"><br></div><div style=3D"font-size:12.8000001907349px">If this idea wo=
rks the block size limitation could be completely removed.</div></div>
--001a11474faad3ad4f0519c4befa--
|
