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
|
Return-Path: <wtogami@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BD5D510FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jan 2016 23:11:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com
[209.85.160.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 54BD8126
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jan 2016 23:11:05 +0000 (UTC)
Received: by mail-yk0-f177.google.com with SMTP id v14so10716989ykd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Jan 2016 15:11:05 -0800 (PST)
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
:content-type; bh=b7idAddpc5TeP2eFH7HM6gSJabYQ/N+0jLyFo19rVlM=;
b=dTAkiBSmpsU+ffA8alZP4tEUs9tcUv7x+lXxc0nwzpsMr9WejLecGbOEj8aKXJ6Ido
EBgdnEjneMkyU2Oa+HYGPFOjJZdKrMFVY6Hs8qYENl/6RQaUthU96nqyMyeZ3S7B5Oj2
eoqYWUY8x6+Cb6o5Qsnx3hZGK8uS7nS7bdfysv1oNEKnKkSziQUR87pXlLiZxwB9MKLf
/ACCNgN3JAu8gFxNq82KRFGmw3eYBpK0vRjEpLe1JP4Jh+vwkFzY8aO9Ngw4AwOUXlaR
7XsOY8LH6SCRxjDBxCCxHUJuhdi91ilcVjwzPTipPyEC++NviGuIPJiHUgotjoE2il2f
iu4A==
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:date
:message-id:subject:from:to:content-type;
bh=b7idAddpc5TeP2eFH7HM6gSJabYQ/N+0jLyFo19rVlM=;
b=Yy6xtRYIIs1sIIpIW8XI3T+1oajc1l55rhuQpj2O7JSKDLMsCadBpxx4wV/2JTYis7
1VhxOoZDGHY8kzRX3le/ksjwUo+J5vcQYM4IYsr2vnBMc5o8zdQHKygMRWSiMr2MPhLD
Jd8ikhR3fXPWStNenmZhAQAX2UlNZfF4sm8Sdp8DXD26nxop0pQNllP4n8NnXuvWV/T2
BM6Za5DIo0P6pegki6ntv7/wPqLkUOzhTj67AEtHALMlZ34R/l7SvxMDkBoCPKRvGls1
/5ZfgOk5QPn6y4sXOlT9FKiLaoKntFiP0RAL6L+td1zmKnFsnEb+Vi4NhophGtI5l4u+
CxDw==
X-Gm-Message-State: AG10YOSLMk6CBK88teY40KRRKk92SD7zjRrnH8GNAvMGrUY6rD4wxJ9qtJEc+q6sY12ItJS+muRJWjhKBWlbug==
MIME-Version: 1.0
X-Received: by 10.129.157.209 with SMTP id u200mr15621630ywg.199.1453936264470;
Wed, 27 Jan 2016 15:11:04 -0800 (PST)
Received: by 10.37.214.4 with HTTP; Wed, 27 Jan 2016 15:11:04 -0800 (PST)
In-Reply-To: <CAMuv0Z1yo7-zzj75nXFf9kJNJfmxOoxqHMpDmmNM9uQzFKZ_xQ@mail.gmail.com>
References: <CAMuv0Z2gjNKc52UFV2n3H1ckt30chS7=fEUwO8OpfU1Vg7Ayzw@mail.gmail.com>
<CAEz79PrVfdy5g=XcajMvKtCMUCtG44A8N_UAM8NrzZL00cvjiA@mail.gmail.com>
<CAMuv0Z1yo7-zzj75nXFf9kJNJfmxOoxqHMpDmmNM9uQzFKZ_xQ@mail.gmail.com>
Date: Wed, 27 Jan 2016 15:11:04 -0800
Message-ID: <CAEz79Pq7AEmSfDZr0jc0JjdeH9asyGXXhJGMXc43OHJcj8Vrsw@mail.gmail.com>
From: "Warren Togami Jr." <wtogami@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0baa3c91ec0b052a58eabe
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
Subject: Re: [bitcoin-dev] Fee smoothing
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, 27 Jan 2016 23:11:05 -0000
--94eb2c0baa3c91ec0b052a58eabe
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 27, 2016 at 2:12 AM, Luzius Meisser <luzius.meisser@gmail.com>
wrote:
> I agree that flex cap is promising. However, for it to be a viable
> long-term solution, it must not depend on significant block subsidies
> to work as the block subsidy will become less and less relevant over
> time
There is another variant of the Flex Cap approach that allows miners to pay
with a slightly higher difficulty target instead of deferring a portion of
subsidy to later blocks. I think the HK presentation was about the subsidy
deferral variant because of miner feedback that they preferred that
approach.
Myself and a few other developers think proposals like BIP100 where the
block size is subject to a vote by the miners is suboptimal because this
type of vote is costless. You were astute in recognizing in your post it's
a good thing to somehow align the global marginal cost with the miner's
incentive. I feel a costless vote is not great because it aligns only to
the miner's marginal cost, and not the marginal cost to the entire flood
network. Flex Cap is superior as "vote" mechanism as there is an actual
cost associated, allowing block size to grow with actual demand.
Warren
--94eb2c0baa3c91ec0b052a58eabe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jan 27, 2016 at 2:12 AM, Luzius Meisser <span dir=3D"ltr"><<a hr=
ef=3D"mailto:luzius.meisser@gmail.com" target=3D"_blank">luzius.meisser@gma=
il.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">I agree that flex cap is p=
romising. However, for it to be a viable<br>
long-term solution, it must not depend on significant block subsidies<br>
to work as the block subsidy will become less and less relevant over<br>
time</blockquote><div><br></div><div>There is another variant of the Flex C=
ap approach that allows miners to pay with a slightly higher difficulty tar=
get instead of deferring a portion of subsidy to later blocks.=C2=A0 I thin=
k the HK presentation was about the subsidy deferral variant because of min=
er feedback that they preferred that approach.</div><div><br></div><div>Mys=
elf and a few other developers think proposals like BIP100 where the block =
size is subject to a vote by the miners is suboptimal because this type of =
vote is costless.=C2=A0 You were astute in recognizing in your post it'=
s a good thing to somehow align the global marginal cost with the miner'=
;s incentive.=C2=A0 I feel a costless vote is not great because it aligns o=
nly to the miner's marginal cost, and not the marginal cost to the enti=
re flood network.=C2=A0 Flex Cap is superior as "vote" mechanism =
as there is an actual cost associated, allowing block size to grow with act=
ual demand.</div><div><br></div><div>Warren</div><div><br></div></div></div=
></div>
--94eb2c0baa3c91ec0b052a58eabe--
|
