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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1WcGdn-0001HM-3q
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 16:00:19 +0000
Received: from mail-pa0-f47.google.com ([209.85.220.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WcGdm-0001WC-1q
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 16:00:19 +0000
Received: by mail-pa0-f47.google.com with SMTP id lj1so3871193pab.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Apr 2014 09:00:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=tO6sBQ0snLYvJgLIocCkIXRnfYKxtIOQc51ioB7h6/g=;
b=b+W8G+RJz8fBxhmvhOFm04Ywt/r8GLBQhG4TwQosv/hXjGUPoScLGhxLgZb9bwR3q2
zMVnBOJH17UEzqhh6j54tNRu9cBWRXtUtpY7dMKu8EQsr1ukwg0yFVXFaqGh2Bd2eAYJ
BqfNIJR48bfXDMl+ielNXSo30nl19lXGBlKgyYdeXtJmlx7hHhGNdzKajvi1QKzAkw/b
ksmgpGFlMZY32f9J/87X/slW9cDYCAyZ1FsTW6Bu9SL/FA14R9lIksQcVMWmjWEdjDeT
O1HuQusTqRfTFngGvLvwTfvaSLI2zo2kMoDUVX3+6mCES+4eRkJcdNtMu0LXaLzMZzIm
wQRg==
X-Gm-Message-State: ALoCoQm8g/pNUOQwjDxx9sRoqRZu5uIVHbiLaZsN0PDTuCfdJl3kraK5vYPEhJgh1McoitgJ9DlC
X-Received: by 10.66.192.225 with SMTP id hj1mr3860406pac.142.1398096011923;
Mon, 21 Apr 2014 09:00:11 -0700 (PDT)
Received: from [192.168.127.240] (50-0-36-93.dsl.dynamic.sonic.net.
[50.0.36.93]) by mx.google.com with ESMTPSA id
iq10sm78960260pbc.14.2014.04.21.09.00.10 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 21 Apr 2014 09:00:11 -0700 (PDT)
Message-ID: <53554089.1010503@monetize.io>
Date: Mon, 21 Apr 2014 09:00:09 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>,
Jonathan Levin <jonathan.levin@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>
In-Reply-To: <a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WcGdm-0001WC-1q
Cc: 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:00:19 -0000
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.
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.
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.
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.
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.
>
> 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.
|
