From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D1A13E64 for ; 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 ; Wed, 27 Jan 2016 02:45:52 +0000 (UTC) Received: by mail-yk0-f181.google.com with SMTP id y137so2480795yka.2 for ; 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: References: Date: Tue, 26 Jan 2016 18:45:51 -0800 Message-ID: From: "Warren Togami Jr." To: Luzius Meisser 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
On T= ue, 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 sm= oothing
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 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'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.

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'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.
=C2=A0
Benefits:=C2=A0
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 y= ou care about aligning the miner'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.

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 "wall" that can be hit as= miners can choose to burst past it if the cost is worth the reward.
<= 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.
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 tha= t orphan cost is a major reason why pools are attractive.

Warren Togami
--001a1142865ee1f789052a47cc47--