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 ) 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 ; 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: References: Date: Thu, 24 May 2012 10:05:29 -0700 Message-ID: From: Arthur Britto To: Jeff Garzik 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 Subject: Re: [Bitcoin-development] Punishing empty blocks? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.

= -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. =A0Even 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:

=A0 =A0 - Do not store or relay empty blocks, if time since last block <= ; X
=A0 =A0 =A0 (where X =3D 60 minutes, perhaps)

or even stronger,

=A0 =A0 - 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? =A0It 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/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d0407125948a69404c0cb42d3--