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 B95151114 for ; Thu, 28 Jan 2016 20:17:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 87DED117 for ; Thu, 28 Jan 2016 20:17:01 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wb13so12445838obb.1 for ; Thu, 28 Jan 2016 12:17:01 -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=bD8wioED71Lns6uA5+/Gmkan/Aoc5ecTVXFD1lle6TE=; b=kgbLCxSn+VXDi6YW3mXOmw9mJTBrNY1a8P92Vyn6mj5jBB5TG1Qv+NSnvwhXcDMttj pDrumRAGw0xzkB0N+uAELd47mZPkAvaTR1gsHFbYoQtoEmQDkQunr5GhV3VW/RpV4k+U wgP6RdSlZApvDHhyK4a/XigrghgsWmqAMomnE0rrVBao4h4xyMxSJngxYlMDFOK3KX7s N8tkH2xBSEkreB0bpMbG4Fk2T5B4P5gk10g6cur4lczHYbKEFrLTEp/VkHOW3H0Grz/Q pvlxUjOGVUYrvCFNOQgg5COtbndj8G2CG40DTZc1EQ4kAXDjfd0s1qJMOLYiccwRWkDv gwEA== 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=bD8wioED71Lns6uA5+/Gmkan/Aoc5ecTVXFD1lle6TE=; b=licn3tNkAU7+yIN+gul83/dI9vYaUZ5bpyG2q5MS2YeAgDnF0xuL9Dg5gRfKj/4tJ4 reANeYvZsLyuHuXHa9ODyaeGOkV4NPE+cBGpTxJoLoO+W5rTRZCDgaYLBp1OFQlgXUdQ LQC1KNWpMN7oiAJnjquYWnOLzbVT2044UdaP1MDlXkPJKuc8hq/MCyf3v/3Hr1ruOAX4 gqSAHPXqafgxoTJ0qmm6GvnBftUkMP5uCZsdtebU4lWy8Zud3Q0KsYDTsJpzc3spVjZ3 ATdrP+xd8FzB/eXp4rhWwD8Y5Da4FMZUlmANviM6IK4IxD3Io229FW0LmxqQ1WuvSZeQ sV8Q== X-Gm-Message-State: AG10YOQgsagpL1tN25cDLjU77VA59AV0RsP+nUvylESASsILf1a/N3cg2Q76II9OQ0oJb+Q4fw6NcjtrwzpGBQ== X-Received: by 10.60.58.103 with SMTP id p7mr3938131oeq.2.1454012220968; Thu, 28 Jan 2016 12:17:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.168.144 with HTTP; Thu, 28 Jan 2016 12:16:41 -0800 (PST) In-Reply-To: References: From: Luzius Meisser Date: Thu, 28 Jan 2016 21:16:41 +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: Thu, 28 Jan 2016 20:20:28 +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: Thu, 28 Jan 2016 20:17:02 -0000 2016-01-28 13:00 GMT+01:00 Warren Togami Jr. : > 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. The cost of the vote is completely irrelevant. What matters are the resulting block sizes and transaction fees. Assuming rational, profit-maximizing miners, BIP100 would allow them to effectively enforce a cartel and to set block sizes (and thereby indirectly also fees) at monopoly price levels. Charging something for a vote would not affect that equilibrium and thus also neither affect block sizes nor fees. Also note that monopoly prices are always at least as high as competitive market prices. In other words: the transaction fees that emerge under BIP100 will be higher than those that would emerge with a flex cap mechanism that is based on the total marginal costs of the miners. If you do not believe that, I'll happily go into the gory details. > 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. There are two types of flex cap mechanisms: First, there mechanisms like the one I described previously which ensures that supply is based on the actual costs of the miners. If done right, they can lead to a competitive equilibrium with free market prices. Second, there are flex cap mechanisms that simply replace todays centrally planned constant cap with a centrally planned supply curve. If you believe in central planning, that's ok. I for one prefer to avoid it. Also, it is not much better than the constant cap, maybe even worse. Note that neither type of flex cap adjusts to the marginal cost of the entire network, simply because none of them can measure the cost of running a full node, yet alone reliably detect the number of running full nodes. Any attempt to do so would be futile anyway because it would too easy to pretend-run full nodes in order to manipulate the mechanism. When reasoning about full nodes, completely different forces are at play. The only connection between full nodes and the fee market is that larger blocks make it more expensive to run a full node. However, a holistic analysis must also reason about the benefits of running a full node. I often see one-sided arguments saying that increasing block sizes will make running one more expensive and thus there will be fewer nodes. This logic is flawed because the economic reasons for running a full node are not understood and taken into account. An example reason could be the ability to monitor the network and to verify transactions, which is very valuable to exchanges, merchants and wallet services. To them, this value of running a full node even grows with the number of customers. Thus, depending on the circumstances, increase block sizes can counter-intuitively make it more attractive to run a full node. The big picture from a systemic perspective can look completely different than the conventional micro-view that only sees first-order effects. Unfortunately, most people are not great systems-thinkers. 2016-01-27 11:12 GMT+01:00 Luzius Meisser : > 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 -- Luzius Meisser luzius.meisser@gmail.com