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; 
MIME-Version: 1.0
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
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Precedence: list

--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&#39;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">&lt;<a href=3D"mailto:jgarzik@exmulti.com" target=3D"_bl=
ank">jgarzik@exmulti.com</a>&gt;</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&#39;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 &lt=
; 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&#39;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&#39;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--