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
196
197
198
199
200
201
202
203
204
205
206
207
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B31231595
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 18:48:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com
[209.85.213.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F6E9294
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 18:48:39 +0000 (UTC)
Received: by vkfp126 with SMTP id p126so33702887vkf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 11:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=0iv5lWvOggCKKwAFahmLaGi5YPdzh6eiUVfuib3aKhY=;
b=q0P8QFsbU3cIkYKwnFMcR5+i/8ETg+lebw9TGdVWVzubngvA1vJYujTDayAofKYmgC
JgI2IuikjOS2RTwL/3ALLuClC5ifqq7Ksd/rQJwCUYjFKEsMtblZEbxQ0+e9wE4M/PEU
fTIBih3+UPem58luQXOaq4MeYeGnBrjNWRkVujBKDtrOe6mnU2fgGWIMSW5hQi2Gsv35
1VHiiNmnNqnQwO1OeSZBMXGzFE/Ec+6gbBYLhis/GbO/qnDlE+pW5VzAvgljGlGxUn7F
6xFl8nkPissW2BhKRrDiA3Iis1xwULCTrtID/8lB0OwMVSVD7fyLmLCyQvH3Ezhs+gWU
bpJA==
MIME-Version: 1.0
X-Received: by 10.31.5.205 with SMTP id 196mr23622386vkf.88.1443034118243;
Wed, 23 Sep 2015 11:48:38 -0700 (PDT)
Received: by 10.103.65.204 with HTTP; Wed, 23 Sep 2015 11:48:38 -0700 (PDT)
In-Reply-To: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
Date: Wed, 23 Sep 2015 19:48:38 +0100
Message-ID: <CAE-z3OXdMtu-G2JMYqmzhtJ0CMJh5Tj=zaYCXaGZtOR7h7rHsw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1143dda0044aaf05206e9065
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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 18:48:39 -0000
--001a1143dda0044aaf05206e9065
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
You can create these blocks in advance too.
- receive weak block
- validate
- create child block
It becomes a pure array lookup to get the new header that builds on top of
that block. The child blocks would need to be updated as the memory pool
changes though.
> 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.
>
This also speeds up propagation for the miner. The first weak block that
is broadcast could end up being copied by many other miners.
A miner who is copying a block could send coinbase + original header if he
hits a block. Weak blocks that are just coinbase + header could have lower
POW requirements, since they use up much less bandwidth.
Miners would mostly copy other miners once they had verified their blocks.
The IBLT system works well here. A miner could pick a weak block that is
close to what it actually wants to broadcast.
> 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.
>
Aggregator nodes could offer a service to show/prove how many weak blocks
that the transaction has been accepted in.
> 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.
>
This assumes other compression systems for handling block propagation.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1143dda0044aaf05206e9065
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <span d=
ir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=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">Imagine miners always pr=
e-announce the blocks they're working on to their peers, and peers vali=
date those 'weak blocks' as quickly as they are able.<div><div><br>=
</div><div>Because weak blocks are pre-validated, when a full-difficulty bl=
ock based on a previously announced weak block is found, block propagation =
should be insanely fast-- basically, as fast as a single packet can be rela=
yed across the 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 th=
e full-difficulty block and CreateNewBlock() insanely fast, and if those op=
erations take just a microsecond or three, miners will have an incentive to=
create blocks with fee-paying transactions that weren't in the last bl=
ock, rather than mining empty blocks.</div></div></div></blockquote><div><b=
r></div><div>You can create these blocks in advance too.<br><br></div><div>=
- receive weak block<br></div><div>- validate<br></div><div>- create child =
block <br></div><div><br></div><div>It becomes a pure array lookup to get t=
he new header that builds on top of that block.=C2=A0 The child blocks woul=
d need to be updated as the memory pool changes though.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A miner could=
try to avoid validation work by just taking a weak block announced by some=
body else, replacing the coinbase and re-computing the merkle root, and the=
n 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 fu=
ll block is found and a fully-validating miner announced their next weak bl=
ock.</div></div></blockquote><div><br></div><div>This also speeds up propag=
ation for the miner.=C2=A0 The first weak block that is broadcast could end=
up being copied by many other miners.<br><br></div><div>A miner who is cop=
ying a block could send coinbase + original header if he hits a block.=C2=
=A0 Weak blocks that are just coinbase + header could have lower POW requir=
ements, since they use up much less bandwidth.<br><br></div><div>Miners wou=
ld mostly copy other miners once they had verified their blocks.=C2=A0 The =
IBLT system works well here.=C2=A0 A miner could pick a weak block that is =
close to what it actually wants to broadcast.<br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Weak block announcements =
are great for the network; they give transaction creators a pretty good ide=
a of whether or not their transactions are likely to be confirmed in the ne=
xt block.</div></div></blockquote><div><br></div><div>Aggregator nodes coul=
d offer a service to show/prove how many weak blocks that the transaction h=
as been accepted in.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div> And if we're smart about implementing them, t=
hey shouldn't increase bandwidth or CPU usage significantly, because al=
l the weak blocks at a given point in time are likely to contain the same t=
ransactions.</div></div></blockquote><div><br></div><div>This assumes other=
compression systems for handling block propagation.<br></div>=C2=A0<blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><span class=3D"HOEnZb"><font =
color=3D"#888888"><div><div><br></div>-- <br><div>--<br>Gavin Andresen<br><=
/div><div><br></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></div>
--001a1143dda0044aaf05206e9065--
|
