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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jonathan.levin@sant.ox.ac.uk>) id 1WcHLa-0005RC-IA
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 16:45:34 +0000
X-ACL-Warn:
Received: from relay14.mail.ox.ac.uk ([163.1.2.162])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WcHLX-0006Zv-21 for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 16:45:34 +0000
Received: from hub03.nexus.ox.ac.uk ([163.1.154.216]
helo=HUB03.ad.oak.ox.ac.uk)
by relay14.mail.ox.ac.uk with esmtp (Exim 4.80)
(envelope-from <jonathan.levin@sant.ox.ac.uk>)
id 1WcHLQ-00058N-kp; Mon, 21 Apr 2014 17:45:24 +0100
Received: from MBX03.ad.oak.ox.ac.uk ([169.254.3.44]) by HUB03.ad.oak.ox.ac.uk
([163.1.154.216]) with mapi id 14.03.0169.001;
Mon, 21 Apr 2014 17:45:23 +0100
From: Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
To: Mark Friedenbach <mark@monetize.io>
Thread-Topic: Economics of information propagation
Thread-Index: AQHPXYEWpTaZmGM7n0CdxFu2gwNUfg==
Date: Mon, 21 Apr 2014 16:45:22 +0000
Message-ID: <F956A706-5730-4B68-A8CB-4F832915319B@sant.ox.ac.uk>
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>
<53554089.1010503@monetize.io>
In-Reply-To: <53554089.1010503@monetize.io>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.150.236]
Content-Type: multipart/signed;
boundary="Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0";
protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WcHLX-0006Zv-21
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
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 16:45:34 -0000
--Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Thank you for your thoughts.=20
> The earlier, larger block A will only become stale if *two* blocks are
> found in the extra time it takes for block A to propagate the network.
> That is a substantially different risk, and probably a negligible
> concern to most miners.
I really like Mark=92s suggestion but one concern is that it might tip =
the needle too far. Currently, there is a private cost to include more =
transactions, which might be too high, but limit the amount of negative =
externalities that this creates on other miners. If I am able to create =
blocks that are very likely to be on the main chain with the maximum =
number of transactions then this makes imposing negative externalities =
on other miners less costly. Other nodes that are closely connected to =
me would experience a positive externality through this as well. Would =
have do some more thinking here but it seems that there is a balance to =
strike.
> If anything, looks like a threat to the current situation with huge
> mining subsidies coming from the seigniorage, not a problem that you
> would have when the the seigniorage is gone.
The incentives remain so long as the ratio of the seignorage revenues to =
transaction fees remain very high. Even though the dollar price does not =
change that relationship it does mean that Bitcoin becomes more =
expensive in USD terms as the USD price of Bitcoin rises.
> I think the most important part is that nodes can reliably decide on
> "first received", regardless of how they subsequently act on it.=20
If we want to limit the amount of network time spent on redundant =
problems it would be best for miners to act on this information? What is =
the benefit of serialisation? Is it that the miner would consider it =
more likely to make it into the main chain rather than the block that =
came second?
> But I don't see how miners mining headers first would result in empty
> blocks either.
I guess it is due to the fact that this is the only way a miner can be =
certain that none of the transactions have been spent already resulting =
in an orphan block.
On 21 Apr 2014, at 17:00, Mark Friedenbach <mark@monetize.io> wrote:
> That wasn't what I was saying. Right now the primacy of a block is
> determined by the time at which the `block` message is received, which
> is delays due to both the time it takes to transmit the block data and
> the time it takes to validate. Headers-first, on the other hand, has =
the
> option of basing primacy on the time the block header is received, =
which
> is O(1) time to transmit and to SPV-validate. Mining on that block
> doesn't actually commence until the full block is received and =
validated.
>=20
> To see how this works, take an example: two blocks with a common =
parent
> are found relatively close to each other, block A and block B. A is
> found first but is a large block with the maximum block size and many
> slow scripts. B is found a few seconds later and is an empty block. In
> the current regime it is entirely possible that block B, the later but
> smaller block, would get received and processed first by more mining
> peers than the larger block A, exactly as described in Jonathan =
Levin's
> email.
>=20
> With headers-first, however, the cost of propagation of the block =
header
> is the same and we should expect block A to win out over block B =
nearly
> every time. Miners will continue working on the old, known valid =
parent
> block until the contents of block A are received and processed. So the
> smaller block B is still found, and since it's data moves across the
> network faster, miners even briefly mine on block B. But as soon as =
they
> receive and process the contents of block A, they switch to that.
>=20
> The earlier, larger block A will only become stale if *two* blocks are
> found in the extra time it takes for block A to propagate the network.
> That is a substantially different risk, and probably a negligible
> concern to most miners.
>=20
> On 04/20/2014 09:06 PM, Peter Todd 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.
>>=20
>> 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.
--Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJTVUslAAoJEFPmse9fNbQlBoQH/2sxPccDRPK1Da6+e6lHK3tJ
RsHpkyKl/lwDlBopES4Ei9eVshzuiFIt3OvpN8DPaXEy8rB+gk10GbVq2kyWiWeb
iuWVkMrNCjJi2JYRNzMSoRvw8N1qrJpD+hyLFfwL9j1KolDZvq/T2HAJOl42Ncyp
GXXtQkhjxNVlFhEENfuoSPxBuybRUFsBRgZVW9SpRIoSGcfQrJYPQUTaJxJwyMrV
x3x3Za3jZWXqqJSnpu1C35h8XQWQSedMCECk0tHH2abMaWPPX+Slq+QaJWBBzbie
4KxG0+lGIm1sKmJBG3pK6aO41blFghnbGG281jsSq4fvyWhPnYRPZE8RYY7JkGI=
=1EmZ
-----END PGP SIGNATURE-----
--Apple-Mail=_F256537F-C6CF-44DD-BAD7-5B2E660686C0--
|
