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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <joel.kaartinen@gmail.com>) id 1SXbbc-0003AM-Uh
for bitcoin-development@lists.sourceforge.net;
Thu, 24 May 2012 17:13:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=joel.kaartinen@gmail.com;
helo=mail-lpp01m010-f47.google.com;
Received: from mail-lpp01m010-f47.google.com ([209.85.215.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SXbbX-0005hi-Cs
for bitcoin-development@lists.sourceforge.net;
Thu, 24 May 2012 17:13:44 +0000
Received: by lags15 with SMTP id s15so10569lag.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 May 2012 10:13:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.44.163 with SMTP id f3mr73553lbm.59.1337879612789; Thu, 24
May 2012 10:13:32 -0700 (PDT)
Received: by 10.112.39.8 with HTTP; Thu, 24 May 2012 10:13:32 -0700 (PDT)
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
Date: Thu, 24 May 2012 20:13:32 +0300
Message-ID: <CAGKSKfUzTce+d_nyWvHeXc9vdXu=34oRgaL=tbLrvO00iwuyNQ@mail.gmail.com>
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: multipart/alternative; boundary=bcaec554d23e12955d04c0cb5f8c
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
(joel.kaartinen[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: 1SXbbX-0005hi-Cs
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:13:45 -0000
--bcaec554d23e12955d04c0cb5f8c
Content-Type: text/plain; charset=ISO-8859-1
I think the strong verification would go well if you add it along with an
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)
On Thu, May 24, 2012 at 7:33 PM, 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
>
--bcaec554d23e12955d04c0cb5f8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think the strong verification would go well if you add it along with an o=
ptimization that avoids rechecking transactions that have already been veri=
fied as valid. Any transactions it doesn't have to verify are from the =
pool, of course :)<br>
<br><div class=3D"gmail_quote">On Thu, May 24, 2012 at 7:33 PM, 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>
--bcaec554d23e12955d04c0cb5f8c--
|
