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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <dscvlt@gmail.com>) id 1WcGL1-0002qP-Mo
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 15:40:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=dscvlt@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WcGKz-0007dn-VS
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 15:40:55 +0000
Received: by mail-oa0-f43.google.com with SMTP id eb12so4408532oac.30
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Apr 2014 08:40:48 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.186.40 with SMTP id fh8mr10572obc.87.1398094848549; Mon,
21 Apr 2014 08:40:48 -0700 (PDT)
Received: by 10.182.225.106 with HTTP; Mon, 21 Apr 2014 08:40:48 -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: Tue, 22 Apr 2014 01:10:48 +0930
Message-ID: <CAOXABZrB0p3KzKhGaYQsgQ2TGMvg_A0cuOhQ956QPRBPrO_=qg@mail.gmail.com>
From: Ashley Holman <dscvlt@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0153764acf694d04f78f528a
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
(dscvlt[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: 1WcGKz-0007dn-VS
Cc: bitcoin-development@lists.sourceforge.net,
Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
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:40:55 -0000
--089e0153764acf694d04f78f528a
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <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.
--089e0153764acf694d04f78f528a
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 1:36 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<blockquote class=3D"gmail_quote" style=3D"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 f=
or the information to validate the block and update their UTXO sets. This r=
esults in the same problem as before, as the large pools who mine most bloc=
ks can validate either instantly - the self-mine case - or more quickly tha=
n the smaller miners.<br>
<br></blockquote><div>=C2=A0</div><div>Under the headers first scenario, wo=
uldn't the full block still reach everyone in the same time as it would=
under the current rules? =C2=A0So the small miner loses nothing in terms o=
f updating their UTXO set, but gains an early "heads up" alert th=
at a new block is coming. =C2=A0This allows them spend the propagation time=
working more productively on an empty block in the new chain rather than w=
asting time on an orphan. =C2=A0It's true that it doesn't solve the=
problem of larger pools vs smaller pools, but if it doesn't make it an=
y worse then headers-first propagation would be a net benefit to the networ=
k since it removes the incentive to make small blocks.</div>
</div></div></div>
--089e0153764acf694d04f78f528a--
|
