path: root/da/f8bdc975e3d5f01867040bafd3d75b5cb39ffa

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 D1A13E64
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Jan 2016 02:45:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com
	[209.85.160.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0E41E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Jan 2016 02:45:52 +0000 (UTC)
Received: by mail-yk0-f181.google.com with SMTP id y137so2480795yka.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jan 2016 18:45:52 -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
	:cc:content-type;
	bh=xxFpVp1B5nK/dSyqAMbbg90UT/g3sQa6qbODeYn/KAU=;
	b=s+haL6OeTdSJqR05bXOslde16W7VQTBdAzvBHaKYfiQwwyFT/o0OMb/l+RB5e548jd
	GnV3UvW0pbRw6KLbg5WLj2sZSt38p4qySTE+9GIZRkNmQqH//URXS4rX507bUpVim4k0
	K45GtcrVngXlKgo1Jl+FQpjI26MygVHph0XT1yoBAeW7Dr77Z3/6ynILH7jW6MzS6cUl
	bzM7yDwqdsxD7I9J9Oycn8pU7yMzpgNsJa/n6jQzWpx6iVnZC84RDU7ZpNirQkf1sItF
	Gv4rzHtjAmgFyRoTdb3OYirW9yZemtOnbc1cGbgYfEq2hoCtTbhw1v85IHnRzcg9Lsqx
	tx8Q==
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:cc:content-type;
	bh=xxFpVp1B5nK/dSyqAMbbg90UT/g3sQa6qbODeYn/KAU=;
	b=e0SQu4HppXM36PpCuUDRbKEGRsDbFlW1qTccZiATepKsV6nslEMOlSFbO7otWfNbWX
	t1b4+aC6tK8ilTNYVVzHbewxdm5Wwye1Adg0aBHOHRbr1dIvKSeRlEkVuvzwX5sv4lKw
	jJWdjKCWtVkx8AuhPShiP3Ia4SYiiK8+XXga1TfSg7vJRL+dnN195E1vJqBqlh+wCv/F
	FFhKBoKJ2DYQQqS7MLLgEwMiARvGBbqnFMiGlfyL5p/+arNTx6As4KIN2sW8TtfkALlF
	gazozElqzGCPDL5k944hELoJ1PXWkilzX0tbpj3zejxmeodm3Ww07cpn2nMtXqfJ8dx9
	eHkg==
X-Gm-Message-State: AG10YOQ4fuk+eAHWl35dWuTJf7eIokd8CetIrLDFawkuoOFXK1Ahxd9PIhEvg+/JC7nfsgtjL3OUbCrv8e+AbQ==
MIME-Version: 1.0
X-Received: by 10.129.20.212 with SMTP id 203mr13624847ywu.68.1453862751955;
	Tue, 26 Jan 2016 18:45:51 -0800 (PST)
Received: by 10.37.214.4 with HTTP; Tue, 26 Jan 2016 18:45:51 -0800 (PST)
In-Reply-To: <CAMuv0Z2gjNKc52UFV2n3H1ckt30chS7=fEUwO8OpfU1Vg7Ayzw@mail.gmail.com>
References: <CAMuv0Z2gjNKc52UFV2n3H1ckt30chS7=fEUwO8OpfU1Vg7Ayzw@mail.gmail.com>
Date: Tue, 26 Jan 2016 18:45:51 -0800
Message-ID: <CAEz79PrVfdy5g=XcajMvKtCMUCtG44A8N_UAM8NrzZL00cvjiA@mail.gmail.com>
From: "Warren Togami Jr." <wtogami@gmail.com>
To: Luzius Meisser <luzius.meisser@gmail.com>
Content-Type: multipart/alternative; boundary=001a1142865ee1f789052a47cc47
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,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
X-Mailman-Approved-At: Wed, 27 Jan 2016 03:23:17 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 02:45:53 -0000

--001a1142865ee1f789052a47cc47
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This post serves to convince you of the economic benefits of smoothing
> the payout of fees across blocks. It incentivizes decentralization and
> supports the establishment of a fee market.
>
> Idea: currently, the total amount of fees collected in a block is paid
> out in full to whoever mined that block. I propose to only pay out,
> say, 10% of the collected fees, and to add the remaining 90% to the
> collected fees of the next block. Thus, the payout to the miner
> constitutes a rolling average of collected fees from the current and
> past blocks. This
> *reduces the marginal benefit of including an additional transaction into
> a block* by an order of magnitude and thus
> aligns the incentives of individual miners better with those of the
> whole network. As a side-effect,
>
> *the disadvantage of mining with a slow connection is reduced.*


I do not believe your logic is correct.  Reducing the marginal benefit of
including an additional transaction is problematic because it
simultaneously increases the orphan risk while it reduces the reward.  90%
of the fee going to the next block would also create new incentive problems
like mining an empty block to minimize the chance of losing 90% of the fees
from the previous block to an orphan.  Another major issue with mandatory
sharing is if the miner doesn't want to share, nothing stops them from
taking payment out-of-band and confirming the transaction with little or no
fees visible in the block.

I had been thinking recently about fee deferral for a different reason.  In
the future when the subsidy is much smaller in proportion to the fees,
there may be little incentive to confirm on top of someone else's block in
cases when the expected value of replacing the current tip is higher.  I
think smoothing fees between the current and subsequent 5 blocks (for
example) might reduce the incentive of this type of behavior.  The main
risk here might be in weakening too far the incentive of adding more
transactions to the current block, as I believe your 10% current and 90%
subsequent reward split would do.  I think my idea of a mandatory split
between six blocks might also be a failure because of the high incentive to
conduct out-of-band payments.


> Benefits:
>
2. This is a step towards a free fee market. In an ideal market,
> prices form where supply and demand meet, with the fees asymptotically
> approaching the marginal costs of a transaction. Currently, supply is
> capped and only demand can adjust. Should we ever consider to let
> miners decide about supply, it is
>
> *essential that their marginal benefit of including an additional
> transaction is aligned with the global marginal cost incurred by that
> additional transaction.* Fee
> smoothing is a step in this direction.
>

While I don't agree with the rest of your logic, it is agreeable that you
care about aligning the miner's supply incentives with the global marginal
cost.  If you believe that is an important goal, you might like the Flex
Cap approach as presented by Mark Friedenbach at Scaling Bitcoin Hong Kong.

Under the general idea of the Flex Cap approach block size is no longer
fixed, it can be bursted higher on a per-block basis if the miner is
willing to defer a tiny portion of the current block subsidy to pay out to
the miner of later blocks.  If conditions are such that there is genuine
demand then some are willing to pay higher fees for time preference.  Some
formula would balance the cost and reward in some manner like: add the
value of newly included fees, subtract the expected marginal cost of orphan
risk, then subtract the portion of subsidy deferred.  Flex cap has periodic
block size retargets to allow for a temporary limit to rise or fall to
something resembling actual market demand.  This temporary limit is never a
"wall" that can be hit as miners can choose to burst past it if the cost is
worth the reward.

Flex Cap is an area of ongoing research that I strongly believe would
benefit Bitcoin in the long-term.  For this reason it requires careful
study and simulations to figure out specifics.

3. The incentive to form mining pools is reduced. Currently,
> solo-mining yields a very volatile income stream due to the random
> nature of mining, leading to the formation of pools. This volatility
> will increase to even higher levels once the amount of Bitcoins earned
> per block is dominated by (volatile) collected fees and not by
> (constant) freshly minted coins, thus increasing the economic pressure
> to join a large pool. Fee smoothing reduces that volatility and
> pressure.
>

You seem to not recognize that orphan cost is a major reason why pools are
attractive.

Warren Togami

--001a1142865ee1f789052a47cc47
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">This post serves to convince you of the economic benefits of sm=
oothing<br>
the payout of fees across blocks. It incentivizes decentralization and<br>
supports the establishment of a fee market.<br>
<br>
Idea: currently, the total amount of fees collected in a block is paid<br>
out in full to whoever mined that block. I propose to only pay out,<br>
say, 10% of the collected fees, and to add the remaining 90% to the<br>
collected fees of the next block. Thus, the payout to the miner<br>
constitutes a rolling average of collected fees from the current and<br>
past blocks. This <b>reduces the marginal benefit of including an<br>
additional transaction into a block</b> by an order of magnitude and thus<b=
r>
aligns the incentives of individual miners better with those of the<br>
whole network. As a side-effect, <b>the disadvantage of mining with a<br>
slow connection is reduced.<br></b></blockquote><div><br></div><div>I do no=
t believe your logic is correct.=C2=A0 Reducing the marginal benefit of inc=
luding an additional transaction is problematic because it simultaneously i=
ncreases the orphan risk while it reduces the reward. =C2=A090% of the fee =
going to the next block would also create new incentive problems like minin=
g an empty block to minimize the chance of losing 90% of the fees from the =
previous block to an orphan.=C2=A0 Another major issue with mandatory shari=
ng is if the miner doesn&#39;t want to share, nothing stops them from takin=
g payment out-of-band and confirming the transaction with little or no fees=
 visible in the block.</div><div><br></div><div>I had been thinking recentl=
y about fee deferral for a different reason.=C2=A0 In the future when the s=
ubsidy is much smaller in proportion to the fees, there may be little incen=
tive to confirm on top of someone else&#39;s block in cases when the expect=
ed value of replacing the current tip is higher.=C2=A0 I think smoothing fe=
es between the current and subsequent 5 blocks (for example) might reduce t=
he incentive of this type of behavior.=C2=A0 The main risk here might be in=
 weakening too far the incentive of adding more transactions to the current=
 block, as I believe your 10% current and 90% subsequent reward split would=
 do.=C2=A0 I think my idea of a mandatory split between six blocks might al=
so be a failure because of the high incentive to conduct out-of-band paymen=
ts.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">Benefits:=C2=A0<br></blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">
2. This is a step towards a free fee market. In an ideal market,<br>
prices form where supply and demand meet, with the fees asymptotically<br>
approaching the marginal costs of a transaction. Currently, supply is<br>
capped and only demand can adjust. Should we ever consider to let<br>
miners decide about supply, it is <b>essential that their marginal<br>
benefit of including an additional transaction is aligned with the<br>
global marginal cost incurred by that additional transaction.</b> Fee<br>
smoothing is a step in this direction.<br></blockquote><div><br></div><div>=
While I don&#39;t agree with the rest of your logic, it is agreeable that y=
ou care about aligning the miner&#39;s supply incentives with the global ma=
rginal cost.=C2=A0 If you believe that is an important goal, you might like=
 the Flex Cap approach as presented by Mark Friedenbach at Scaling Bitcoin =
Hong Kong.</div><div><br></div><div>Under the general idea of the Flex Cap =
approach block size is no longer fixed, it can be bursted higher on a per-b=
lock basis if the miner is willing to defer a tiny portion of the current b=
lock subsidy to pay out to the miner of later blocks.=C2=A0 If conditions a=
re such that there is genuine demand then some are willing to pay higher fe=
es for time preference.=C2=A0 Some formula would balance the cost and rewar=
d in some manner like: add the value of newly included fees, subtract the e=
xpected marginal cost of orphan risk, then subtract the portion of subsidy =
deferred.=C2=A0 Flex cap has periodic block size retargets to allow for a t=
emporary limit to rise or fall to something resembling actual market demand=
.=C2=A0 This temporary limit is never a &quot;wall&quot; that can be hit as=
 miners can choose to burst past it if the cost is worth the reward.</div><=
div><br></div><div>Flex Cap is an area of ongoing research that I strongly =
believe would benefit Bitcoin in the long-term.=C2=A0 For this reason it re=
quires careful study and simulations to figure out specifics.</div><div><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex">
3. The incentive to form mining pools is reduced. Currently,<br>
solo-mining yields a very volatile income stream due to the random<br>
nature of mining, leading to the formation of pools. This volatility<br>
will increase to even higher levels once the amount of Bitcoins earned<br>
per block is dominated by (volatile) collected fees and not by<br>
(constant) freshly minted coins, thus increasing the economic pressure<br>
to join a large pool. Fee smoothing reduces that volatility and<br>
pressure.<br></blockquote><div><br></div><div>You seem to not recognize tha=
t orphan cost is a major reason why pools are attractive.</div><div><br></d=
iv><div>Warren Togami</div></div></div></div>

--001a1142865ee1f789052a47cc47--