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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F5A1170C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 19:24:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80D83163
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 19:24:07 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so125862504igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 12:24:07 -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=L7MVjlIck11OBbeb52UfmHvStu1Tg/MDdw1l0DOB1fk=;
b=yfwc371O6DvxO/jvQT+3StKsEe48EsPjQse3QhmdSESXyXkzUw4kkF/GKSZm+lkR63
vrpIa9Ay7K9DJyaLHcrEhjMK4nHh8gGVAjtpr8+gYy+y50ubztOZG7cuTAZxnDDYFZ7n
qHYuAOWjaECpAwoOol24Y8/W//1wxv+Qtk6F9rsv5cf92hQGXRO98VdbTN74YUeuWZlc
MYxYn5aEfRDFOaEQppL918Bcs936cwlx7sWN/rMZr4hbRVDjGELx6IUAcfGDp+Ixhbll
i3L9WfdimpNtqO5OAgsxyVNOc40AR4d+CfLcFSSpDPGgcKkMEHNia7PcqS0aVtEp3C/k
GvAA==
MIME-Version: 1.0
X-Received: by 10.50.27.5 with SMTP id p5mr25410749igg.66.1443036247004; Wed,
23 Sep 2015 12:24:07 -0700 (PDT)
Received: by 10.107.19.30 with HTTP; Wed, 23 Sep 2015 12:24:06 -0700 (PDT)
In-Reply-To: <CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
<CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
Date: Wed, 23 Sep 2015 19:24:06 +0000
Message-ID: <CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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 19:24:08 -0000
On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> more recently:
> http://gnusha.org/bitcoin-wizards/2015-09-20.log
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
See also my response to Peter R's paper that was republished to the
list at http://pastebin.com/jFgkk8M3
(See sections at "For example, imagine if miners only include
transactions that were previously committed" and especially "Miners
volutarily participate in a fast consensus mechenism which commits to
transactions")
On Wed, Sep 23, 2015 at 3: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--
[...]
> 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.
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).
There is a cost to these schemes-- additional overhead from
communicating the efficiently encoded weak blocks. But participation
in this overhead is optional and doesn't impact the history.
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).
On Wed, Sep 23, 2015 at 4:28 PM, Peter R via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Shouldn't mining pools and miners be paying you guys for coding solutions
> that improve their profitability?
The income to miners as a whole doesn't depend on these sorts of
optimizations, competitive advantages do... so better common open
infrastructure helps mostly in the case of putting propagation
disadvantaged miners on an equal playing field. You'll note that none
of them are exactly sharing their SPV mining source code right now....
in any case, there are simple, expedient, and low risk ways to improve
their equality in that respect: centralize (e.g. use bigger pools).
|
