From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcCV0-0007x2-HL for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 11:34:58 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.170 as permitted sender) client-ip=209.85.216.170; envelope-from=tier.nolan@gmail.com; helo=mail-qc0-f170.google.com; Received: from mail-qc0-f170.google.com ([209.85.216.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WcCUx-0004wJ-Ax for bitcoin-development@lists.sourceforge.net; Mon, 21 Apr 2014 11:34:58 +0000 Received: by mail-qc0-f170.google.com with SMTP id x13so3920145qcv.15 for ; Mon, 21 Apr 2014 04:34:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.46.53 with SMTP id j50mr2669774qga.27.1398080089898; Mon, 21 Apr 2014 04:34:49 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Mon, 21 Apr 2014 04:34:49 -0700 (PDT) In-Reply-To: References: <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk> Date: Mon, 21 Apr 2014 12:34:49 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113a7e5c20411004f78be389 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 (tier.nolan[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: 1WcCUx-0004wJ-Ax Subject: Re: [Bitcoin-development] Economics of information propagation 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: Mon, 21 Apr 2014 11:34:58 -0000 --001a113a7e5c20411004f78be389 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd wrote: > Of course, in reality smaller miners can just mine on top of block headers > and include no transactions and do no validation, but that is extremely > harmful to the security of Bitcoin. > I don't think it reduces security much. It is extremely unlikely that someone would publish an invalid block, since they would waste their POW. Presuming that new headers are correct is reasonable, as long as you check the full block within a few minutes of receiving the header. If anything, it increases security, since less hashing power is wasted while the full block is broadcast. Block propagation could take the form - broadcast new header - all miners switch to mining empty blocks - broadcast new block - miners update to a block with transactions If the block doesn't arrive within a timeout, then the miner could switch back to the old block. This would mean that a few percent of empty blocks end up in the blockchain, but that doesn't do any harm. It is only harmful, if it is used as a DOS attack on the network. The empty blocks will only occur when 2 blocks are found in quick succession, so it doesn't have much affect on average time until 1 confirm. Empty blocks are just as good for providing 1 of the 6 confirms needed too. --001a113a7e5c20411004f78be389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 21, 2014 at 5:06 AM, Peter Todd <pete@petertodd.org> wrote:
Of course, in reality smaller miners can just mine on top of block headers = and include no transactions and do no validation, but that is extremely har= mful to the security of Bitcoin.

I don&= #39;t think it reduces security much.=C2=A0 It is extremely unlikely that s= omeone would publish an invalid block, since they would waste their POW.
Presuming that new headers are correct is reasonable, as lon= g as you check the full block within a few minutes of receiving the header.=
=C2=A0
If anything, it increases security, sin= ce less hashing power is wasted while the full block is broadcast.

Block propagation could take the form

- br= oadcast new header
- all miners switch to mining empty blocks=
- broadcast new block
- miners update to a blo= ck with transactions

If the block doesn't arrive within a timeout, then the m= iner could switch back to the old block.

This = would mean that a few percent of empty blocks end up in the blockchain, but= that doesn't do any harm.

It is only harmful, if it is used as a DOS attack on the net= work.

The empty blocks will only occur when 2 blocks are = found in quick succession, so it doesn't have much affect on average ti= me until 1 confirm.=C2=A0 Empty blocks are just as good for providing 1 of = the 6 confirms needed too.
--001a113a7e5c20411004f78be389--