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
184
185
186
187
188
189
190
191
192
193
|
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 <etotheipi@gmail.com>) id 1WcGbo-0007fk-Be
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 15:58:16 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.48 as permitted sender)
client-ip=209.85.216.48; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f48.google.com;
Received: from mail-qa0-f48.google.com ([209.85.216.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WcGbl-0004w6-5X
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 15:58:16 +0000
Received: by mail-qa0-f48.google.com with SMTP id s7so3901838qap.21
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Apr 2014 08:58:07 -0700 (PDT)
X-Received: by 10.140.108.200 with SMTP id j66mr45180767qgf.7.1398095887730;
Mon, 21 Apr 2014 08:58:07 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id f3sm74250211qag.7.2014.04.21.08.58.06
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 21 Apr 2014 08:58:07 -0700 (PDT)
Message-ID: <5355400E.1060108@gmail.com>
Date: Mon, 21 Apr 2014 11:58:06 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
<CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com>
In-Reply-To: <CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------020600030704050406030703"
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
(etotheipi[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: 1WcGbl-0004w6-5X
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 15:58:16 -0000
This is a multi-part message in MIME format.
--------------020600030704050406030703
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 04/21/2014 11:40 AM, Ashley Holman wrote:
> On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>
> That is mistaken: you can't mine on top of just a block header,
> leaving small miners disadvantaged as they are earning no profit
> while they wait for the information to validate the block and
> update their UTXO sets. This results in the same problem as
> before, as the large pools who mine most blocks can validate
> either instantly - the self-mine case - or more quickly than the
> smaller miners.
>
>
> Under the headers first scenario, wouldn't the full block still reach
> everyone in the same time as it would under the current rules? So the
> small miner loses nothing in terms of updating their UTXO set, but
> gains an early "heads up" alert that a new block is coming. This
> allows them spend the propagation time working more productively on an
> empty block in the new chain rather than wasting time on an orphan.
> It's true that it doesn't solve the problem of larger pools vs
> smaller pools, but if it doesn't make it any worse then headers-first
> propagation would be a net benefit to the network since it removes the
> incentive to make small blocks.
>
I think the most important part is that nodes can reliably decide on
"first received", regardless of how they subsequently act on it. I
believe it would be fine for a node to receive a header and continue
mining the old block, or a subsequently-verified competing block, until
it has the necessary pieces to fully verify the first header received.
If that block data doesn't come, then it will be naturally ignored. But
if multiple blocks come at once, even if a competing block "verifies"
first, the node would still switch to considering the first header
received as the best block when it later receives proof it is valid
(which may only be a couple seconds).
In other words, the node will always consider the header-received time
as the primary ordering criteria, but will not mine on anything until it
has full proof of validity, even if /that/ is out of order. This means
that new blocks "effectively" propagate at the speed of 80 bytes, which
limits certain kinds of block-injection/racing attacks.
--------------020600030704050406030703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 04/21/2014 11:40 AM, Ashley Holman wrote:<br>
<blockquote
cite="mid:CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Apr 21, 2014 at 1:36 PM,
Peter Todd <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
That is mistaken: you can't mine on top of just a block
header, leaving small miners disadvantaged as they are
earning no profit while they wait for the information to
validate the block and update their UTXO sets. This
results in the same problem as before, as the large pools
who mine most blocks can validate either instantly - the
self-mine case - or more quickly than the smaller miners.<br>
<br>
</blockquote>
<div> </div>
<div>Under the headers first scenario, wouldn't the full
block still reach everyone in the same time as it would
under the current rules? So the small miner loses nothing
in terms of updating their UTXO set, but gains an early
"heads up" alert that a new block is coming. This allows
them spend the propagation time working more productively
on an empty block in the new chain rather than wasting
time on an orphan. It's true that it doesn't solve the
problem of larger pools vs smaller pools, but if it
doesn't make it any worse then headers-first propagation
would be a net benefit to the network since it removes the
incentive to make small blocks.</div>
</div>
</div>
</div>
<br>
</blockquote>
<br>
I think the most important part is that nodes can reliably decide on
"first received", regardless of how they subsequently act on it. I
believe it would be fine for a node to receive a header and continue
mining the old block, or a subsequently-verified competing block,
until it has the necessary pieces to fully verify the first header
received. If that block data doesn't come, then it will be
naturally ignored. But if multiple blocks come at once, even if a
competing block "verifies" first, the node would still switch to
considering the first header received as the best block when it
later receives proof it is valid (which may only be a couple
seconds). <br>
<br>
In other words, the node will always consider the header-received
time as the primary ordering criteria, but will not mine on anything
until it has full proof of validity, even if <i>that</i> is out of
order. This means that new blocks "effectively" propagate at the
speed of 80 bytes, which limits certain kinds of
block-injection/racing attacks. <br>
<br>
<br>
</body>
</html>
--------------020600030704050406030703--
|
