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
|
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 <tier.nolan@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>
<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>
<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
Date: Mon, 21 Apr 2014 12:34:49 +0100
Message-ID: <CAE-z3OX8PGs7B_e32BGPx2BRkKeUwEO+GY-=i-VCxmKsZG6EZw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <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: 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 <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
> 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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 21, 2014 at 5:06 AM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.<br=
>
<br></div><div>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.=
<br></div><div>=C2=A0<br></div><div>If anything, it increases security, sin=
ce less hashing power is wasted while the full block is broadcast.<br>
<br></div><div>Block propagation could take the form<br><br></div><div>- br=
oadcast new header<br></div><div>- all miners switch to mining empty blocks=
<br></div><div>- broadcast new block<br></div><div>- miners update to a blo=
ck with transactions<br>
<br></div><div>If the block doesn't arrive within a timeout, then the m=
iner could switch back to the old block.<br></div><div><br></div><div>This =
would mean that a few percent of empty blocks end up in the blockchain, but=
that doesn't do any harm.<br>
<br></div><div>It is only harmful, if it is used as a DOS attack on the net=
work.<br><br></div><div>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.<br>
</div></div></div></div>
--001a113a7e5c20411004f78be389--
|
