* [bitcoin-dev] Fee smoothing
@ 2016-01-26 17:42 Luzius Meisser
2016-01-27 2:45 ` Warren Togami Jr.
0 siblings, 1 reply; 5+ messages in thread
From: Luzius Meisser @ 2016-01-26 17:42 UTC (permalink / raw)
To: bitcoin-dev
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.
Example: currently, given a transaction with a fee of 1000 Satoshis
and global processing cost per transaction of 5000 Satoshis, an
individual miner would still include the transaction if it costs him
500 Satoshis to do so, as the remaining burden of 4500 Satoshis is
carried by others (a classic externality). However, with fee
smoothing, the immediate benefit of including that particular
transaction is reduced to 100 Satoshis, aligning the economic
incentives of the miner better with the whole network and leading the
miner to skip it. Generally, the fraction that is paid out immediately
(here 10%) can be used to adjust the incentive, but not arbitrarily.
Benefits:
1. The disadvantage of mining with a slow connection is reduced by an
order of magnitude. If it takes 30 seconds to download the latest
block, a miner loses 5% of the potential income from fees as he does
not know yet which transactions to include in the next block. With fee
smoothing, that loss is reduced to 0.5% as he would still earn 90% of
the average fees per block by mining an empty one based on the latest
header.
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.
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.
Problems: touching anything related to fee distribution is a political
minefield. This proposal probably requires a hard fork. Its technical
feasibility was only superficially verified.
This is my first post to this list and I am looking forward to your
comments. In case this proposal is received well, I plan to
specify/implement the idea more formally in order to kick off the
usual process for improvements.
--
Luzius Meisser
President of Bitcoin Association Switzerland
MSc in Computer Science and MA in Economics
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Fee smoothing
2016-01-26 17:42 [bitcoin-dev] Fee smoothing Luzius Meisser
@ 2016-01-27 2:45 ` Warren Togami Jr.
2016-01-27 10:12 ` Luzius Meisser
0 siblings, 1 reply; 5+ messages in thread
From: Warren Togami Jr. @ 2016-01-27 2:45 UTC (permalink / raw)
To: Luzius Meisser; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4801 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 6027 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Fee smoothing
2016-01-27 2:45 ` Warren Togami Jr.
@ 2016-01-27 10:12 ` Luzius Meisser
2016-01-27 23:11 ` Warren Togami Jr.
2016-01-28 20:16 ` Luzius Meisser
0 siblings, 2 replies; 5+ messages in thread
From: Luzius Meisser @ 2016-01-27 10:12 UTC (permalink / raw)
To: Warren Togami Jr.; +Cc: Bitcoin Dev
2016-01-27 3:45 GMT+01:00 Warren Togami Jr. <wtogami@gmail•com>:
> On Tue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Fee smoothing
2016-01-27 10:12 ` Luzius Meisser
@ 2016-01-27 23:11 ` Warren Togami Jr.
2016-01-28 20:16 ` Luzius Meisser
1 sibling, 0 replies; 5+ messages in thread
From: Warren Togami Jr. @ 2016-01-27 23:11 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1672 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Fee smoothing
2016-01-27 10:12 ` Luzius Meisser
2016-01-27 23:11 ` Warren Togami Jr.
@ 2016-01-28 20:16 ` Luzius Meisser
1 sibling, 0 replies; 5+ messages in thread
From: Luzius Meisser @ 2016-01-28 20:16 UTC (permalink / raw)
To: Warren Togami Jr.; +Cc: Bitcoin Dev
2016-01-28 13:00 GMT+01:00 Warren Togami Jr. <wtogami@gmail•com>:
> 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 <luzius.meisser@gmail•com>:
> 2016-01-27 3:45 GMT+01:00 Warren Togami Jr. <wtogami@gmail•com>:
>> On Tue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-28 20:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-26 17:42 [bitcoin-dev] Fee smoothing Luzius Meisser
2016-01-27 2:45 ` Warren Togami Jr.
2016-01-27 10:12 ` Luzius Meisser
2016-01-27 23:11 ` Warren Togami Jr.
2016-01-28 20:16 ` Luzius Meisser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox