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
|
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 8AFF4171C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 01:39:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
[209.85.213.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FA4A10F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 01:39:01 +0000 (UTC)
Received: by igxx6 with SMTP id x6so30815504igx.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Sep 2015 18:39:00 -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=SbDYo5wEeEuJiYLtZiL88w1quq6Pq4Gdm6c9jEQ70KU=;
b=rCdRVtEh59vbDp3AUf47cabu5U7dxUtaeYS3qtnQEqUecLa42YbKKZ0Obr3Efq2jME
zoTCpwKU2JP/nphIvr92Pbsv+VGqUXcfBIS+eF0wPq5wMiiriCxtdUo2kwewsMYJXlxE
W2zZm33+qqT1s5vZjuG6veIp+ZK0q9A8dHfopYTz50nTFnAGb3dvhGGAzHwU0yXYK3Jl
2kjDrkzJWBCYvAMrmYJoAsSXdW4F3bWZQ45JepkqFvJTbvJvzd0FfpylOwVTttPyo+Yy
ZI4LaIPSRRgHKo7KLz9PxuvboOU57L1E2h0CKj1gPJVTWxF2Z8PTHeIwlQ3WpxjaqEHE
Y3bQ==
MIME-Version: 1.0
X-Received: by 10.50.62.242 with SMTP id b18mr8257607igs.48.1443317940726;
Sat, 26 Sep 2015 18:39:00 -0700 (PDT)
Received: by 10.107.19.30 with HTTP; Sat, 26 Sep 2015 18:39:00 -0700 (PDT)
In-Reply-To: <CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
<CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
<CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
<CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
Date: Sun, 27 Sep 2015 01:39:00 +0000
Message-ID: <CAAS2fgRj+fE+znXZzFsXXBivKSxnJ2Lheo_g9us4FXN_yCLhgw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@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: Sun, 27 Sep 2015 01:39:01 -0000
On Wed, Sep 23, 2015 at 9:37 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
>> 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...
Unless the weak block transaction list can be a superset of the block
transaction list size proportional propagation costs are not totally
eliminated.
As even if the weak block criteria is MUCH lower than the block
criteria (which would become problematic in its own right at some
point) the network will sometimes find blocks when there hasn't been
any weak block priming at all (e.g. all prior priming has made it into
blocks already).
So if the weak block commitment must be exactly the block commitment
you end up having to add a small number of transactions to your block
above and beyond the latest well propagated weak-blocks... Could still
work, but then creates a pressure to crank up the weak block overhead
which could better be avoided.
|
