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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CE4A305
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Jul 2015 02:57:22 +0000 (UTC)
X-Greylist: delayed 00:05:01 by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu
[18.9.25.14])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2702BE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Jul 2015 02:57:20 +0000 (UTC)
X-AuditID: 1209190e-f79c76d000002631-90-559355e27afd
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])
(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP
id 0F.99.09777.2E553955; Tue, 30 Jun 2015 22:52:18 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t612qHb7026218
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 22:52:18 -0400
Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com
[209.85.160.182]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t612qGjp020334
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 22:52:17 -0400
Received: by ykfy125 with SMTP id y125so27318525ykf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 19:52:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.129.76.70 with SMTP id z67mr30352498ywa.17.1435719136607;
Tue, 30 Jun 2015 19:52:16 -0700 (PDT)
Received: by 10.13.222.2 with HTTP; Tue, 30 Jun 2015 19:52:16 -0700 (PDT)
In-Reply-To: <CAPg+sBj2P6ZUxJyrn3Dq76USO5kDTfpkF-zuYsKQbpQbTnyq2A@mail.gmail.com>
References: <CAGpx8BXMfUSaW1FONsbR4dK-uvQ73TjGuh5PUzsxJVwVUW3O1A@mail.gmail.com>
<CAPg+sBj2P6ZUxJyrn3Dq76USO5kDTfpkF-zuYsKQbpQbTnyq2A@mail.gmail.com>
Date: Wed, 1 Jul 2015 10:52:16 +0800
Message-ID: <CAD5xwhj_cieV18zB-5W+dBse1JQkFqh7t3ofqV3_yf=BgnUq9g@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f1ce62286b20519c76948
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixCmqrPsodHKowc4zYhZNr20dGD1+/5jM
GMAYxWWTkpqTWZZapG+XwJVxqeEYU8El14pDa/pYGxivWncxcnJICJhITNl9kxXCFpO4cG89
WxcjF4eQwGImidMdqxghnLuMEk8frILKfGSS+L1vDyNIi5DAREaJX5vqQGxeAUGJkzOfsECM
KpZo+HGNFaLGU2LL0blMIDanQKDEi/nHWSEGTWeUOPtwI3MXIwcHi4CKxN8tOhBzAiR6Z3wC
2yws0Mwo8WbFKUaQGjYBOYkPv0xBakQEtCVmPt4CtotZoEZi9prXrBC2l8SUfzMYJzAKzUJy
0iwkqVlAk5gF1CXWzxOCCKtJ3N52lR3C1pZYtvA18wJG1lWMsim5Vbq5iZk5xanJusXJiXl5
qUW6xnq5mSV6qSmlmxjBIS/Jt4Px60GlQ4wCHIxKPLwCYpNDhVgTy4orcw8xSnIwKYny/g8A
CvEl5adUZiQWZ8QXleakFh9ilOBgVhLhzdAGyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJ
zU5NLUgtgsnKcHAoSfDGhQA1ChalpqdWpGXmlCCkmTg4QYbzAA3XCgUZXlyQmFucmQ6RP8Vo
zLHl97W1TBzbpt5byyTEkpeflyolztsLMk4ApDSjNA9uGixtvWIUB3pOmHcfSBUPMOXBzXsF
tIoJaNVL+0kgq0oSEVJSDYwhp27k7C+wOWq+2P3jlO0XY1qvGt800dJvfZb/MMRW0vz9rJfG
2db9rds3Tzg+f8ZD/Uu7VvCvyfZmEf3/K1yAozDx86KvQlnJTzbEiu09PK32weWMn6eSs3pe
Lnwt6yNlX1ax6vVSf+Obwrll669lb7lbl+8Ut2DZgsJqiebfLu/7+BLWqv5SYinOSDTUYi4q
TgQATBDIGDYDAAA=
X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD 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"
<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: Wed, 01 Jul 2015 02:57:22 -0000
--001a113f1ce62286b20519c76948
Content-Type: text/plain; charset=UTF-8
A simple hack to achieve this would be phase shifting the transaction fees
by one block. There may be other problems, but also potential
benefits, with that though.
This hack works because then a miner would orphan a block which didn't
properly reward them, which makes it very costly for even a miner to put in
a bunch of transactions for free. This phase can be adjusted to different
amounts, spread over multiple blocks, or even randomly selected at the time
of mining from a pool of un-fee claimed blocks (although this would require
some seeding to create a pool of any size greater than 1).
Again, this is probably a bad idea and I haven't thought it through
completely, but just tossing it out there.
Ps sorry if you're seeing this many times I think it bounced due to the
not-subscribed rule (sent from my other account)
On Wednesday, July 1, 2015, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','bitcoin-dev@lists.linuxfoundation.org');>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
--001a113f1ce62286b20519c76948
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"Ki"><div class=3D"Li" style=3D"height:102px"><div class=3D"Xh=
" style=3D"height:102px"><div class=3D"gi ji Wh" dir=3D"ltr"><font color=
=3D"#000000" size=3D"2" style=3D"background-color:rgba(255,255,255,0)">A si=
mple hack to achieve this would be phase shifting the transaction fees by o=
ne block. There may be other problems, but also potential benefits,=C2=A0wi=
th that though.</font><div style=3D"clear:both"></div></div></div></div></d=
iv><div style=3D"clear:both"></div><div class=3D"Ki"><div class=3D"Li" styl=
e=3D"height:220px"><div class=3D"Xh" style=3D"height:220px"><div class=3D"g=
i hi Wh" dir=3D"ltr"><font size=3D"2"><span style=3D"background-color:rgba=
(255,255,255,0)">This hack works because then a miner would orphan a block =
which didn't properly reward them, which makes it very costly for even =
a miner to put in a bunch of transactions for free. This phase can be adjus=
ted to different amounts, spread over multiple blocks, or even randomly sel=
ected at the time of mining from a pool of un-fee claimed blocks (although =
this would require some seeding to create a pool of any size greater than 1=
).</span></font><div style=3D"clear:both"></div></div></div></div></div><di=
v style=3D"clear:both"></div><div class=3D"Ki"><div class=3D"Li" style=3D"h=
eight:102px"><div class=3D"Xh" style=3D"height:102px"><div class=3D"gi ji =
Wh" dir=3D"ltr"><div><font color=3D"#000000" size=3D"2"><span style=3D"back=
ground-color:rgba(255,255,255,0)"><br></span></font></div><div><font color=
=3D"#000000" size=3D"2" style=3D"background-color:rgba(255,255,255,0)">Agai=
n, this is probably a bad idea and I haven't thought it through complet=
ely,=C2=A0but just tossing it out there.</font></div></div></div></div></di=
v><div><br></div>Ps sorry if you're seeing this many times I think it b=
ounced due to the not-subscribed rule (sent from my other account)<br>On We=
dnesday, July 1, 2015, Pieter Wuille <<a href=3D"mailto:pieter.wuille@gm=
ail.com">pieter.wuille@gmail.com</a>> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><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 particular block. So we need a 100% mempool synchronization across all n=
odes - otherwise just an attempted double spend could result in a fork in t=
he 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 t=
he first place, because we could just use "first to enter mempool"=
; as validity criterion.<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Jul 1, 2015 at 1:41 AM, Peter Grigor <span dir=3D"=
ltr"><<a href=3D"javascript:_e(%7B%7D,'cvml','peter@grigor.w=
s');" target=3D"_blank">peter@grigor.ws</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-size:12.800000=
1907349px">The block size debate centers around one concern it seems. To wi=
t: if block size is increased malicious miners may publish unreasonably lar=
ge "bloated" blocks. The way a miner would do this is to generate=
a plethora of private, non-propagated transactions and include these in th=
e 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 b=
loated 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 allo=
w 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 woul=
d contain a ridiculous number of transactions that *absolutely no other ful=
l 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 thres=
hold would be set by nodes on the allowable number of non-mempool transacti=
ons allowed in a solved block (say, maybe, 50% -- I really don't know w=
hat it should be). If a block is published which contains more that this th=
reshold of non-mempool transactions then it is rejected.</div><div style=3D=
"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.8000001=
907349px">If this idea works the block size limitation could be completely =
removed.</div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"javascript:_e(%7B%7D,'cvml','bitcoin-dev@lists.linux=
foundation.org');" target=3D"_blank">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>
</blockquote><br><br>-- <br><div dir=3D"ltr">--<br><a href=3D"https://twitt=
er.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank"></a></div><br>
--001a113f1ce62286b20519c76948--
|
