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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DDCA6258
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 17:39:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com
[209.85.217.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 691FB156
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 17:39:59 +0000 (UTC)
Received: by mail-ua0-f169.google.com with SMTP id 12so46651636uas.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 09:39:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=ZPMZSpmJTeTpjE51KFUfCP2rPOQgj+JdAVOtvb1+0f0=;
b=a2PFTBS22XmP7RtrLvKEniTF0uvqJpBuAjKCAXwPrZre5pciG/0q7EkaITYyCoklUS
/QweMmhNVFOYpS6UPNd65ykwNex6SFjCCDjSoPEWzbO3FUHSwuSuwOAlg7AJ3XTlohn4
9vWVxKeYCucmsg+fpCSY5TtpSKzqBCUzapnMQcVMEcXuqGc2Mw5vmMTiTFNgbb54T9Bs
AjleoSObivDOff83X/YunoUFEB8CrZYpxP2oYs55vbMk2K2Vkj3zpLWcLiuvjK2iLsyT
dvQmr6DMACP0neRxWMYP2uqxTHf2zvpUKY6+I1K9M2//emFQJwfE8E14w6QgDkLaUvaF
wnfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=ZPMZSpmJTeTpjE51KFUfCP2rPOQgj+JdAVOtvb1+0f0=;
b=T5q2bxRLHgmF4hkN1hW2V8WGlNjxFOk/mkXhwiab/9B5Gzce/RavCwXXPZ4twqEiHG
KOzPjXATC5yCDZxmrZsr5UTEWf7DmwD/YIVSyT26uvj4+JS7zYI5+Vnm7cN1Odzu8VYu
yspTMXYs5uB4xZSQPMUjPsrzXEqfNF2U5oANHyVpYUxadtDcx9ysJREq/WByLZQB9+/S
xNOEVyoJIPFExYE0JGMlP4ad8xVohUmlDIUVPTJfvaCKGLAXYgZHfEaJcUGUyNLN3phN
X1cTvzL5Ti6zlYFFTQ1V7/0gRUzyyMuRHEi9vJgw3AdYMsTUtxNQAt630ODxcTLLlTuz
Pmmw==
X-Gm-Message-State: AKaTC03sk7q9qHJygXgX5sw0QphC/nUXl2gOf/q9JH8sbSwUsS8O5PbUk676Oxbd95pNa1VflZBBy53XMAVZjQ==
X-Received: by 10.176.65.33 with SMTP id j30mr67086490uad.94.1481391598507;
Sat, 10 Dec 2016 09:39:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.108.202 with HTTP; Sat, 10 Dec 2016 09:39:57 -0800 (PST)
In-Reply-To: <CAEgR2PEvpEwv=a0syn43negEnvGcoQ8LBxKRp4-JpnxCNORJSg@mail.gmail.com>
References: <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
<CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
<CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
<CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
<CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
<CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
<CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
<CAEgR2PEvpEwv=a0syn43negEnvGcoQ8LBxKRp4-JpnxCNORJSg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Sat, 10 Dec 2016 09:39:57 -0800
Message-ID: <CAPg+sBiZmRdLOgG9iN2hOWVr_eCLTwDrbuETd_w9-bUJOfTjgw@mail.gmail.com>
To: Daniele Pinna <daniele.pinna@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c124644009c960543515c81
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
(aka Block75)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 10 Dec 2016 17:40:00 -0000
--94eb2c124644009c960543515c81
Content-Type: text/plain; charset=UTF-8
On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> We have models for estimating the probability that a block is orphaned
> given average network bandwidth and block size.
>
> The question is, do we have objective measures of these two quantities?
> Couldn't we target an orphan_rate < max_rate?
>
Models can predict orphan rate given block size and network/hashrate
topology, but you can't control the topology (and things like FIBRE hide
the effect of block size on this as well). The result is that if you're
purely optimizing for minimal orphan rate, you can end up with a single
(conglomerate of) pools producing all the blocks. Such a setup has no
propagation delay at all, and as a result can always achieve 0 orphans.
Cheers,
--
Pieter
--94eb2c124644009c960543515c81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin=
-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><span sty=
le=3D"font-size:13.696px;font-family:sans-serif">We have models for estimat=
ing the probability that a block is orphaned given average network bandwidt=
h and block size.=C2=A0</span><br></div><div dir=3D"auto"><span style=3D"fo=
nt-size:13.696px;font-family:sans-serif"><br></span></div><div dir=3D"auto"=
><span style=3D"font-family:sans-serif;font-size:13.696px">The question is,=
do we have objective measures of these two quantities? Couldn't we tar=
get an orphan_rate < max_rate?=C2=A0</span><span style=3D"font-size:13.6=
96px;font-family:sans-serif"><br></span></div></div></blockquote><div><br><=
/div><div>Models can predict orphan rate given block size and network/hashr=
ate topology, but you can't control the topology (and things like FIBRE=
hide the effect of block size on this as well). The result is that if you&=
#39;re purely optimizing for minimal orphan rate, you can end up with a sin=
gle (conglomerate of) pools producing all the blocks. Such a setup has no p=
ropagation delay at all, and as a result can always achieve 0 orphans.<br><=
br></div><div>Cheers,<br><br>-- <br></div><div>Pieter<br><br></div></div></=
div></div>
--94eb2c124644009c960543515c81--
|
