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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ahbritto@gmail.com>) id 1SXbTm-0004hv-Qz
for bitcoin-development@lists.sourceforge.net;
Thu, 24 May 2012 17:05:38 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.175 as permitted sender)
client-ip=209.85.217.175; envelope-from=ahbritto@gmail.com;
helo=mail-lb0-f175.google.com;
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SXbTk-00016T-Fc
for bitcoin-development@lists.sourceforge.net;
Thu, 24 May 2012 17:05:38 +0000
Received: by lbol5 with SMTP id l5so6571lbo.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 May 2012 10:05:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.102.234 with SMTP id fr10mr153087lab.32.1337879129794;
Thu, 24 May 2012 10:05:29 -0700 (PDT)
Received: by 10.112.2.66 with HTTP; Thu, 24 May 2012 10:05:29 -0700 (PDT)
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
Date: Thu, 24 May 2012 10:05:29 -0700
Message-ID: <CAFjXj6NjVnTAoKFvA==w6ZCMo7fQA-DdaVweS4scAe8M__uosA@mail.gmail.com>
From: Arthur Britto <ahbritto@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=f46d0407125948a69404c0cb42d3
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(ahbritto[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1SXbTk-00016T-Fc
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Punishing empty blocks?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 17:05:38 -0000
--f46d0407125948a69404c0cb42d3
Content-Type: text/plain; charset=ISO-8859-1
I think you need the stronger change. Otherwise, the mystery miner could
just put in a few transactions to himself to mask his block. His block
would appear to be of some use while not being helpful.
-Arthur
On Thu, May 24, 2012 at 9:33 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
>
> The former is easier to implement, though there is the danger that
> no-TX miners simply include a statically generated transaction or two.
>
> The latter might be considered problematic, as it might refuse to
> relay quickly found blocks.
>
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d0407125948a69404c0cb42d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think you need the stronger change. =A0Otherwise, the mystery miner could=
just put in a few transactions to himself to mask his block. =A0His block =
would appear to be of some use while not being helpful.<div><br></div><div>=
-Arthur<br>
<br><div class=3D"gmail_quote">On Thu, May 24, 2012 at 9:33 AM, Jeff Garzik=
<span dir=3D"ltr"><<a href=3D"mailto:jgarzik@exmulti.com" target=3D"_bl=
ank">jgarzik@exmulti.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
There appears to be some non-trivial mining power devoted to mining<br>
empty blocks. =A0Even with satoshi's key observation -- hash a fixed<br=
>
80-byte header, not the entire block -- some miners still find it<br>
easier to mine empty blocks, rather than watch the network for new<br>
transactions.<br>
<br>
Therefore I was wondering what people thought about a client<br>
implementation change:<br>
<br>
=A0 =A0 - Do not store or relay empty blocks, if time since last block <=
; X<br>
=A0 =A0 =A0 (where X =3D 60 minutes, perhaps)<br>
<br>
or even stronger,<br>
<br>
=A0 =A0 - Ensure latest block includes at least X percent of mempool<br>
unconfirmed TXs<br>
<br>
The former is easier to implement, though there is the danger that<br>
no-TX miners simply include a statically generated transaction or two.<br>
<br>
The latter might be considered problematic, as it might refuse to<br>
relay quickly found blocks.<br>
<br>
Comments? =A0It wouldn't be a problem if these no-TX blocks were not<br=
>
already getting frequent (1 in 20).<br>
<br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>
--f46d0407125948a69404c0cb42d3--
|
