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
|
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 62DEC10E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 09:42:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
[209.85.213.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 00C38A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 09:42:25 +0000 (UTC)
Received: by vkao3 with SMTP id o3so76803687vka.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 02:42:25 -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=cIFy/b/UkWRhIrmiCecltneKRwCSKdeRKolXq/lG0pM=;
b=DU+5/0XgUwQzze8uIcXhR79KznyvS7JuN//nMl/9TOnTLNbNt4L7XEn9sGe5iXhtCF
XD2VD8tt7/kY+4gjtqrQM3tOPE14eEIM5XphruXEDXHpc9PdR5JozZHc6csLHeUpAFEH
SLX+sj73exj6cvSJ8dRWSFXS5M2d3bJHANuVY4BhzxuV1ibfrZktg6x7RZIUjdv9h8xd
eW0Bi0i4YNlr505+AKfpjDImfxM77ILcz01pEQyPefBlLzv4SHc2Egv5gpoV+JsiRogs
YjSCbBZG4nKlh2tv7K7XWwL8h3VMwVFpxa2o9nqiD/K3+/wuH6BYwQUT466L6hJyH+3N
Vr3Q==
MIME-Version: 1.0
X-Received: by 10.31.129.85 with SMTP id c82mr8247206vkd.65.1443346945073;
Sun, 27 Sep 2015 02:42:25 -0700 (PDT)
Received: by 10.103.65.204 with HTTP; Sun, 27 Sep 2015 02:42:24 -0700 (PDT)
In-Reply-To: <CAAS2fgRj+fE+znXZzFsXXBivKSxnJ2Lheo_g9us4FXN_yCLhgw@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>
<CAAS2fgRj+fE+znXZzFsXXBivKSxnJ2Lheo_g9us4FXN_yCLhgw@mail.gmail.com>
Date: Sun, 27 Sep 2015 10:42:24 +0100
Message-ID: <CAE-z3OU50cZBR27QrQsRT5Gtb0AVkE6K33XR0GebsyNWNrbf+w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11459a40f2eb9b0520b7657a
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: Sun, 27 Sep 2015 09:42:26 -0000
--001a11459a40f2eb9b0520b7657a
Content-Type: text/plain; charset=UTF-8
On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Unless the weak block transaction list can be a superset of the block
> transaction list size proportional propagation costs are not totally
> eliminated.
>
The POW threshold could be dynamic. The first weak-block that builds on a
new block could be forwarded with a smaller target.
This reduces the window size until at least one weak block is propagated.
The change in threshold could be time based (for the first 30 seconds or
so). This would cause a surge of traffic when a new block once a new block
has propagated, so perhaps not so good an idea.
> 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).
>
If there is a transaction backlog, then miners could forward merkle
branches with transactions in the memory pool with a commitment in the
coinbase.
--001a11459a40f2eb9b0520b7657a
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 Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev <span =
dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>Unless the weak block transaction list can be a superset of the bloc=
k<br>
transaction list size proportional propagation costs are not totally<br>
eliminated.<br></blockquote><div><br></div><div>The POW threshold could be =
dynamic.=C2=A0 The first weak-block that builds on a new block could be for=
warded with a smaller target.<br><br></div><div>This reduces=C2=A0 the wind=
ow size until at least one weak block is propagated.=C2=A0 <br><br></div><d=
iv>The change in threshold could be time based (for the first 30 seconds or=
so).=C2=A0 This would cause a surge of traffic when a new block once a new=
block has propagated, so perhaps not so good an idea.<br></div><div><br></=
div><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<br>
As even if the weak block criteria is MUCH lower than the block<br>
criteria (which would become problematic in its own right at some<br>
point) the network will sometimes find blocks when there hasn't been<br=
>
any weak block priming at all (e.g. all prior priming has made it into<br>
blocks already).<br></blockquote><div><br></div><div>If there is a transact=
ion backlog, then miners could forward merkle branches with transactions in=
the memory pool with a commitment in the coinbase.<br></div></div></div></=
div>
--001a11459a40f2eb9b0520b7657a--
|
