Re: [bitcoin-dev] Total fees have almost crossed the block reward

[rhavar@protonmail.com]

> This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game
>theory optimal.  Possibly over the short term it is, but over a longer period, those
> wishing to increase the longevity of proof of work in general might wish to consider
> more progressive fee approaches. 

The constraining factor for blocks is the max-block weight. So miners are already optimizing for the right thing (creating a block that gives the most immediate reward). If miners want to start a cartel-like behavior of charging more for more value-transfer it would be incredibly harmful and even likely promote centralization (the cartel would likely not look kindly on any miner who doesn't follow their rules, and perhaps start orphaning their blocks).

Now I guess in theory you could add consensus rules that apply restrictions on the amount of "value transfer" in a block, such that miners are motivated to charge more for high-value transactions. However there's going to be almost 0 appetite from anyone to want to do anything like this, and the amount of unintended and harmful side effects would be profound.  (Personally, I'd lose any interest in bitcoin if such a change was ever instated)


​-Ryan

​

-------- Original Message --------
 On February 12, 2018 12:23 PM, Melvin Carvalho via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
>On 21 December 2017 at 22:30, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>I asked adam back at hcpp how the block chain would be secured in the long term, once the reward goes away.  The base idea has always been that fees would replace the block reward.
>>At that time fees were approximately 10% of the block reward, but have now reached 45%, with 50% potentially being crossed soon
>>
>>https://fork.lol/reward/feepct
>>
>>While this bodes well for the long term security of the coin, I think there is some legitimate concern that the fee per tx is prohibitive for some use cases, at this point in the adoption curve.
>>
>>Observations of segwit adoption show around 10% at this point
>>
>>http://segwit.party/charts/
>>
>>Watching the mempool shows that the congestion is at a peak, though it's quite possible this will come down over the long weekend.  I wonder if this is of concern to some.
>>
>>https://dedi.jochen-hoenicke.de/queue/more/#24h
>>
>>I thought these data points may be of interest and are mainly FYI.  Though if further discussion is deemed appropriate, it would be interesting to hear thoughts.
>>
>Just following up on this, for no other reason than I've had my eyes glued to these stats the last few weeks.  I'll share a few more stats links.
>Mempool has come down significantly, as have fees.  Tho, of course, this could spike any time.  
>
>https://bitinfocharts.com/bitcoin/
>Typically fees are :
>
> $2.06 on tx $543 (median) # 0.38%
> $3.47 on tx $75,000 (mean) # 0.005%
>Aside: An observation on this.  High value transactors seems to be getting a much better deal, than the mean.  This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game theory optimal.  Possibly over the short term it is, but over a longer period, those wishing to increase the longevity of proof of work in general might wish to consider more progressive fee approaches.  Naively, it might be possible to imagine some kind of gaussian distribution that picks tx according to a blended combination of sats/byte and %transacted.  Perhaps something for miners and fee estimation algorithms to develop over time.
>Segwit adoption has increased, and anecdotal evidence shows that trend to continue.  The release of 0.16 will I think also have a positive effect.
>Finally, I came across this wonderful site that shows lightning network adoption on mainnet
>
>http://shabang.io/
>LN is increasing well.  Some blocks are not far off 1% lightning funding, which I think bodes well.  I'll go out on a limb and predict that over 1% of btc tx will be lightning based by year end.
>Since such posts are not strictly development, I'll keep them to a minimum.  However, I hope these stats provide useful data points for project evolution.
>
>