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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 622611414
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 15:43:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A99B1F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 15:43:13 +0000 (UTC)
Received: by lahh2 with SMTP id h2so31571915lah.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 08:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=dJMXJqmzzAYPogBCqvP2KfTHYbRz7om0kfoHZYl6VyI=;
b=SE9JQ5r6ldXQZ/gO9zyOf9bCsS2aYBmHcG/ymzlURHMl7dJx+mZrRUtrl0Dt78nR7u
xiEZHPyElDWidoRcbs7RmDf6mO5vFQn0C+y/c/525UWqMO5Ej9LZzd6Z1zoT9VwuwtTo
NIwiFQQQJPPVTmFn776M2RCLQWXtJCCF7YprJ95cPecoJiJSUqJphbyPVVBELf1TfvWt
AZ0M73WapjZ/sAkvEWzUO3l6RvEl1PKdEIpSvhMhBhqcS8yvpRBSevYlEYXcxUNykLxa
+XdTt+uqR/6gBiy1plzS/aLAYko0HTIKoZosJ9NjfWv/Z93x3ilEv7xN0rXtm8RxKsUG
0JGg==
MIME-Version: 1.0
X-Received: by 10.112.161.137 with SMTP id xs9mr11893568lbb.4.1443022991759;
Wed, 23 Sep 2015 08:43:11 -0700 (PDT)
Received: by 10.25.200.214 with HTTP; Wed, 23 Sep 2015 08:43:11 -0700 (PDT)
Date: Wed, 23 Sep 2015 11:43:11 -0400
Message-ID: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c3cdf2d39ee305206bf898
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Weak block thoughts...
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2015 15:43:14 -0000
--001a11c3cdf2d39ee305206bf898
Content-Type: text/plain; charset=UTF-8
I've been thinking about 'weak blocks' and SPV mining, and it seems to me
weak blocks will make things better, not worse, if we improve the mining
code a little bit.
First: the idea of 'weak blocks' (hat tip to Rusty for the term) is for
miners to pre-announce blocks that they're working on, before they've
solved the proof-of-work puzzle. To prevent DoS attacks, assume that some
amount of proof-of-work is done (hence the term 'weak block') to rate-limit
how many 'weak block' messages are relayed across the network.
Today, miners are incentivized to start mining an empty block as soon as
they see a block with valid proof-of-work, because they want to spend as
little time as possible mining a not-best chain.
Imagine miners always pre-announce the blocks they're working on to their
peers, and peers validate those 'weak blocks' as quickly as they are able.
Because weak blocks are pre-validated, when a full-difficulty block based
on a previously announced weak block is found, block propagation should be
insanely fast-- basically, as fast as a single packet can be relayed across
the network the whole network could be mining on the new block.
I don't see any barrier to making accepting the full-difficulty block and
CreateNewBlock() insanely fast, and if those operations take just a
microsecond or three, miners will have an incentive to create blocks with
fee-paying transactions that weren't in the last block, rather than mining
empty blocks.
.................
A miner could try to avoid validation work by just taking a weak block
announced by somebody else, replacing the coinbase and re-computing the
merkle root, and then mining. They will be at a slight disadvantage to
fully validating miners, though, because they WOULD have to mine empty
blocks between the time a full block is found and a fully-validating miner
announced their next weak block.
.................
Weak block announcements are great for the network; they give transaction
creators a pretty good idea of whether or not their transactions are likely
to be confirmed in the next block. And if we're smart about implementing
them, they shouldn't increase bandwidth or CPU usage significantly, because
all the weak blocks at a given point in time are likely to contain the same
transactions.
--
--
Gavin Andresen
--001a11c3cdf2d39ee305206bf898
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've been thinking about 'weak blocks' and SPV=
mining, and it seems to me weak blocks will make things better, not worse,=
if we improve the mining code a little bit.<div><br></div><div>First: =C2=
=A0the idea of 'weak blocks' (hat tip to Rusty for the term) is for=
miners to pre-announce blocks that they're working on, before they'=
;ve solved the proof-of-work puzzle. To prevent DoS attacks, assume that so=
me amount of proof-of-work is done (hence the term 'weak block') to=
rate-limit how many 'weak block' messages are relayed across the n=
etwork.</div><div><br><div><br></div><div>Today, miners are incentivized to=
start mining an empty block as soon as they see a block with valid proof-o=
f-work, because they want to spend as little time as possible mining a not-=
best chain.</div><div><br></div><div>Imagine miners always pre-announce the=
blocks they're working on to their peers, and peers validate those =
9;weak blocks' as quickly as they are able.</div><div><br></div><div>Be=
cause weak blocks are pre-validated, when a full-difficulty block based on =
a previously announced weak block is found, block propagation should be ins=
anely fast-- basically, as fast as a single packet can be relayed across th=
e network the whole network could be mining on the new block.</div><div><br=
></div><div>I don't see any barrier to making accepting the full-diffic=
ulty block and CreateNewBlock() insanely fast, and if those operations take=
just a microsecond or three, miners will have an incentive to create block=
s with fee-paying transactions that weren't in the last block, rather t=
han mining empty blocks.</div><div><br></div><div>.................</div><d=
iv><br></div><div>A miner could try to avoid validation work by just taking=
a weak block announced by somebody else, replacing the coinbase and re-com=
puting the merkle root, and then mining. They will be at a slight disadvant=
age to fully validating miners, though, because they WOULD have to mine emp=
ty blocks between the time a full block is found and a fully-validating min=
er announced their next weak block.</div><div><br></div><div>..............=
...</div><div><br></div><div>Weak block announcements are great for the net=
work; they give transaction creators a pretty good idea of whether or not t=
heir transactions are likely to be confirmed in the next block. And if we&#=
39;re smart about implementing them, they shouldn't increase bandwidth =
or CPU usage significantly, because all the weak blocks at a given point in=
time are likely to contain the same transactions.</div><div><div><br></div=
>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div><div c=
lass=3D"gmail_signature"><br></div>
</div></div></div>
--001a11c3cdf2d39ee305206bf898--
|
