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 7C3B1FD9 for ; Wed, 27 Jan 2016 10:12:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C38DD106 for ; Wed, 27 Jan 2016 10:12:22 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id o124so2313387oia.3 for ; Wed, 27 Jan 2016 02:12:22 -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 :cc:content-type; bh=pTVoFachyOOmradh7gCdd3kw8NFjpGlr8hFNvBkb/4A=; b=kKEkQ0BUeZcQu7PupyfBeeJH7Wg6BLerqUDXDcZj8BG1ZEQHTjcHcIiNPFXQjQDwrl A1Lh7aR3bQpIy/2JQaEGnHvZ44yq8G60tjLFr7qFYlDayQI7rLCP8rfqxdVNwawviv7A AQwlDGmcTPkm/YJDXBOLv38LwWkOszk6rGa99ZozUfV6j17QejLvrg3SbHE7MoK0RIyw VcVDnSqwAU5SqzRKGZNyoM148bDwkK8DUFSJiKI0HI3ceJkPVGxN/gvXGmPne4VJQOex sDD4gGQ8gS3CaAbFttCmAbZ3AbFW2dlQBV1ukzD0dFTIEveGld3JuLkFlJQcUhhhdRdm FsPw== 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:cc:content-type; bh=pTVoFachyOOmradh7gCdd3kw8NFjpGlr8hFNvBkb/4A=; b=WXcrxX6+BOxiJHKxzjOKXoke7OZFSExYPzQum17nJE1tr2scqoAhvwB+PdcGnPE34U tZuatTkOb06xw9dtcjOTw0Q+tstc5nu2pqAPoK3y+P5B0Z/RZITDWS9NTdc1nW2JqnLh NZ6HX14+U+vVedKXsybEiGJslDhSuEGfHF97C66vl0IQKnBrBOEteQ1WC9/pQwlqLG37 kIqFwNzbCM7e+KNrZXPCoZn2XvSacoZ9f+oPJ4olTHIDf8DDpPDNGQes30sg9AXm3z5b /tcxD6AWHnPW2rib5Tw1FmFnIVpl0nWfBQrxjrjKDWwkpXOqDTnfbaeRvtgz+TwR3xEP dI9A== X-Gm-Message-State: AG10YOT+OnWEiZ6e/jlqEzeDOnN9dbTJPA5XH8UreDbnDD37d/tJpVyulMQZgLiH+ruZhaXvAlv2XjX3CmUsKQ== X-Received: by 10.202.64.8 with SMTP id n8mr20394986oia.112.1453889542172; Wed, 27 Jan 2016 02:12:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.168.144 with HTTP; Wed, 27 Jan 2016 02:12:02 -0800 (PST) In-Reply-To: References: From: Luzius Meisser Date: Wed, 27 Jan 2016 11:12:02 +0100 Message-ID: To: "Warren Togami Jr." Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 12:40:39 +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 10:12:23 -0000 2016-01-27 3:45 GMT+01:00 Warren Togami Jr. : > On Tue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev > wrote: >> >> 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. > > [...] 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. While I find the other points you raised debatable, the out-of-band argument looks strong enough to kill the idea. To work around it, one would need to create rules about the transactions that can be included in a block, for example by mandating that all included transactions must have a fee at least as high as 0.9 times the 5th percentile of the transactions in the previous 10 blocks. However, having to tell the miners what fees they are allowed to accept destroys some of the elegance of the idea. Maybe I should put it to rest for now and see if a more elegant solution comes to mind later. > 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. > [...] > 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. 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. Picking up your thoughts, I guess this is how flex cap should be done: 1. There is a flexible block cap (e.g. 1 MB). This first MB is free to fill. 2. Miners can buy additional space for an exponentially increasing fee. For example, the first KiB might cost 200 Satoshis, the second KiB 400 Satoshis, the tenth KiB 102400 Satoshis etc. 3. The price of the purchased space is subtracted from the collected fees and added to the reward of the next block. 4. The amount miners are willing to spend on additional space allows to calculate the marginal costs of a transaction of a miner. For example, if a miner pays 6000 Satoshis to include a 1 KB transaction with a fee of 6100 Satoshis, the marginal costs must be below 100 Satoshis, assuming a rational miner. This cost is multiplied by say 50 to account for the costs of decentralization to get a global cost estimate of 5000 Satoshis per KB. 5. Every 1000 blocks or so, the basic cap is adjusted upwards or downwards (e.g. by 10%) depending on whether the average fees per KB were above or below the global cost estimate. Under such a scheme, prices should get very close to free market prices. However, ruthless competition can get ugly in markets where fixed costs dominate. We can currently witness this in the oil industry. Thus, from an economic point of view, it might be more advisable to simply let miners vote on block size, as has been proposed by others. The drawback of voting is that it allows miners to enforce a cartel among themselves and to charge monopoly prices instead of competitive prices. However, monopoly prices would already be much better than having an artificial cap. Warren, thank you for your thoughts! I appreciate the opportunity to discuss ideas at such a high level. -- Luzius Meisser President of Bitcoin Association Switzerland MSc in Computer Science and MA in Economics