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
194
195
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C15E614BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 16:07:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com
[209.85.220.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8E4F1B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 16:07:51 +0000 (UTC)
Received: by qkdw123 with SMTP id w123so19092875qkd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 09:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=GA/Z/s8vPfgZh3B7VhutQvuklQQnMHMpNMb9U4FwB3Y=;
b=vATieeB0f7zk/L+/87FhQgfEYk831oz6eNqLtDo3RfG1MQ8uTeFLFYX2MGLpwKuIqz
WpSQE3BfT4/GrzlQOLinpD7lt6wCp0fu/RFc/sERWHdJvPFg0gApkFxdS3y11ff4VT9w
J215YW4eIqtAmGhEqNVG3LddqNm7YLoH10sKRaqOafs0U99r4UNNX7NuwL4HQLXmgYxw
TY/rtgu9e4cq8lOAku7fN0J4Kyz6eWwGqfVzqch/+my6SEOVhU/9IGw7ufIWfpmJYvUT
5usFyG6fRRn+Ly9unO0G7Tsl7mMKoRkF624EhLWxNLvryIPC3qli271WWMt3TjCcRnq/
81uA==
X-Received: by 10.55.214.217 with SMTP id p86mr37278077qkl.75.1443024471111;
Wed, 23 Sep 2015 09:07:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.154.132 with HTTP; Wed, 23 Sep 2015 09:07:31 -0700 (PDT)
In-Reply-To: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Wed, 23 Sep 2015 17:07:31 +0100
Message-ID: <CADJgMzt9xYdaVnvj96YicrcNGj_RWObKTFUsCeWUaP7Apnzwjw@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1149af1a00d65a05206c5180
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 16:07:52 -0000
--001a1149af1a00d65a05206c5180
Content-Type: text/plain; charset=UTF-8
For anyone who missed the discussions of weak blocks, here are the Scaling
Bitcoin's transcripts:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
(under Network Propagation).
On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1149af1a00d65a05206c5180
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">For anyone who missed the discussions of weak blocks, here=
are the Scaling Bitcoin's transcripts:<div><br></div><div><a href=3D"h=
ttp://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-i=
blt-rusty-russell/">http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoi=
n-block-propagation-iblt-rusty-russell/</a>=C2=A0<br></div><div><a href=3D"=
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/">htt=
p://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/</a> (un=
der Network Propagation).<br></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via=
bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I=
9;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 mi=
ning code a little bit.<div><br></div><div>First: =C2=A0the idea of 'we=
ak blocks' (hat tip to Rusty for the term) is for miners to pre-announc=
e blocks that they're working on, before they've solved the proof-o=
f-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 &=
#39;weak block' messages are relayed across the network.</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-of-work, because they w=
ant 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 wo=
rking on to their peers, and peers validate those 'weak blocks' as =
quickly as they are able.</div><div><br></div><div>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 ne=
twork could be mining on the new block.</div><div><br></div><div>I don'=
t see any barrier to making accepting the full-difficulty block and CreateN=
ewBlock() insanely fast, and if those operations take just a microsecond or=
three, miners will have an incentive to create blocks with fee-paying tran=
sactions that weren't in the last block, rather than mining empty block=
s.</div><div><br></div><div>.................</div><div><br></div><div>A mi=
ner could try to avoid validation work by just taking a weak block announce=
d by somebody else, replacing the coinbase and re-computing the merkle root=
, and then mining. They will be at a slight disadvantage to fully validatin=
g 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 nex=
t weak block.</div><div><br></div><div>.................</div><div><br></di=
v><div>Weak block announcements are great for the network; they give transa=
ction 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 impl=
ementing them, they shouldn't increase bandwidth or CPU usage significa=
ntly, because all the weak blocks at a given point in time are likely to co=
ntain the same transactions.</div><span class=3D"HOEnZb"><font color=3D"#88=
8888"><div><div><br></div>-- <br><div>--<br>Gavin Andresen<br></div><div><b=
r></div>
</div></font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a1149af1a00d65a05206c5180--
|
