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
|
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 B391F11B3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 21:37:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com
[209.85.215.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD29D128
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 21:37:27 +0000 (UTC)
Received: by lahg1 with SMTP id g1so66734185lah.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 14:37:26 -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:to
:cc:content-type;
bh=k8Yy8ygGCXK/pwjHrnHwTvKJT5kySdp5X3L9ENyO2bA=;
b=pu2tjBBXsaJAXr6P86Zql61OCOqiRpl+yHJNa4qVGYkSQC4QJm4P2LpgEzKAeWnxFK
mX3Z3V22+gXY/Wm2pKCui/bLrtKd4JQ06T/PsNenirgiMj91DfM0uTAf8OfcsOY+7mm6
7cfcnblhdEdFR5ZDqg81iyaL3KWb4wEFn/dUdyolC6vjfarEgSRPhcfmvvI2nLGNIJb7
NF4b/btdUM72rtFq9bEI7iZ3D+SL4tfPPiNapv4ygSKJGs2EBjvsR6DdCwXiIX5QQuDr
XY48QSnbdnMIgOZ8USMEQlkYa3tjbGio1Zuzp/LqxVCD6VpZCv8Lw/M7chmI0zD+ojas
ZnKg==
MIME-Version: 1.0
X-Received: by 10.152.43.202 with SMTP id y10mr12213085lal.75.1443044246040;
Wed, 23 Sep 2015 14:37:26 -0700 (PDT)
Received: by 10.25.200.214 with HTTP; Wed, 23 Sep 2015 14:37:25 -0700 (PDT)
In-Reply-To: <CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
<CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
<CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
Date: Wed, 23 Sep 2015 17:37:25 -0400
Message-ID: <CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c223d8ae3c40052070eb81
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
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 21:37:28 -0000
--001a11c223d8ae3c40052070eb81
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> [...]
> > 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
>
> Take care, here-- if a scheme is used where e.g. the full solution had
> to be exactly identical to a prior weak block then the result would be
> making mining not progress free because bigger miners would have
> disproportionately more access to the weak/strong one/two punch. I
> think what you're thinking here is okay, but it wasn't clear to me if
> you'd caught that particular potential issue.
>
I'm assuming the optimized protocol would be forward-error-coded (e.g.
using IBLTs) and NOT require the full solution (or follow-on weak blocks)
to be exactly the same.
> Avoiding this is why I've always previously described this idea as
> merged mined block DAG (with blocks of arbitrary strength) which are
> always efficiently deferentially coded against prior state. A new
> solution (regardless of who creates it) can still be efficiently
> transmitted even if it differs in arbitrary ways (though the
> efficiency is less the more different it is).
>
Yup, although I don't get the 'merge mined' bit; the weak blocks are
ephemeral, probably purged out of memory as soon as a few full blocks are
found...
> I'm unsure of what approach to take for incentive compatibility
> analysis. In the worst case this approach class has no better delays
> (and higher bandwidth); but it doesn't seem to me to give rise to any
> immediate incrementally strategic behavior (or at least none worse
> than you'd get from just privately using the same scheme).
>
I don't see any incentive problems, either. Worst case is more miners
decide to skip validation and just mine a variation of the
highest-fee-paying weak block they've seen, but that's not a disaster--
invalid blocks will still get rejected by all the non-miners running full
nodes.
If we did see that behavior, I bet it would be a good strategy for a big
hashrate miner to dedicate some of their hashrate to announcing invalid
weak blocks; if you can get your lazy competitors to mine it, then you
win....
--
--
Gavin Andresen
--001a11c223d8ae3c40052070eb81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, S=
ep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br></span>[...]<br>
<span class=3D"">> A miner could try to avoid validation work by just ta=
king a weak block<br>
> announced by somebody else, replacing the coinbase and re-computing th=
e<br>
> merkle root, and then mining. They will be at a slight disadvantage to=
fully<br>
<br>
</span>Take care, here-- if a scheme is used where e.g. the full solution h=
ad<br>
to be exactly identical to a prior weak block then the result would be<br>
making mining not progress free because bigger miners would have<br>
disproportionately more access to the weak/strong one/two punch. I<br>
think what you're thinking here is okay, but it wasn't clear to me =
if<br>
you'd caught that particular potential issue.<br></blockquote><div><br>=
</div><div>I'm assuming the optimized protocol would be forward-error-c=
oded (e.g. using IBLTs) =C2=A0and NOT require the full solution (or follow-=
on weak blocks) to be exactly the same.</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><br>
Avoiding this is why I've always previously described this idea as<br>
merged mined block DAG (with blocks of arbitrary strength) which are<br>
always efficiently deferentially coded against prior state. A new<br>
solution (regardless of who creates it) can still be efficiently<br>
transmitted even if it differs in arbitrary ways (though the<br>
efficiency is less the more different it is).<br></blockquote><div><br></di=
v><div>Yup, although I don't get the 'merge mined' bit; the wea=
k blocks are ephemeral, probably purged out of memory as soon as a few full=
blocks are found...</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I=
'm unsure of what approach to take for incentive compatibility<br>
analysis. In the worst case this approach class has no better delays<br>
(and higher bandwidth); but it doesn't seem to me to give rise to any<b=
r>
immediate incrementally strategic behavior (or at least none worse<br>
than you'd get from just privately using the same scheme).<br></blockqu=
ote><div><br></div><div>I don't see any incentive problems, either. Wor=
st case is more miners decide to skip validation and just mine a variation =
of the highest-fee-paying weak block they've seen, but that's not a=
disaster-- invalid blocks will still get rejected by all the non-miners ru=
nning full nodes.</div><div><br></div><div>If we did see that behavior, I b=
et it would be a good strategy for a big hashrate miner to dedicate some of=
their hashrate to announcing invalid weak blocks; if you can get your lazy=
competitors to mine it, then you win....</div><div><br></div></div>-- <br>=
<div class=3D"gmail_signature">--<br>Gavin Andresen<br></div><div class=3D"=
gmail_signature"><br></div>
</div></div>
--001a11c223d8ae3c40052070eb81--
|
