The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher.
**the ones moving more sats will win the top spots and will pay as much as is reasonable** Smaller blocks produce better security for the network both in validation, and in fees. Without a bidding war for space, everyone can post 1 SAT/byte With a bidding war for space, larger transactions will pay much higher rates. There have been a number of papers written on this but you can concoct a trivial example to prove it. On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <e...@voskuil.org> wrote: > It’s not clear how reducing block size changes the fee aspect of the block > reward. Assuming half the space implies twice the fee per avg tx the > reward remains constant. > > Any additional cost of processing more or less bytes would not matter, > because of course this is just a cost that gets nulled out by difficulty — > average profit (net income) is the cost of capital. > > The reason for smaller vs. larger blocks is to ensure that individuals can > afford to validate. That’s a threshold criteria. > > Given unlimited size blocks, miners would still have to fix a point in > time to mine, gathering as much fee as they can optimize in some time > period presumably less than 10 minutes. The produces a limit to transaction > volume, yet neither reward nor profit would be affected given the above > assumptions. The difference would be in a tradeoff of per tx fee against > the threshold. > > Given Moore’s Law, that threshold is constantly decreasing, which will > make it cheaper over time for more individuals to validate. But the > difference for miners for smaller blocks is largely inconsequential > relative to their other costs. > > Increasing demand is the only thing that increases double spend security > (and censorship resistance assuming fee-based reward). With rising demand > there is rising overall hash rate, despite block reward and profit > remaining constant. This makes the cost of attempting to orphan a block > higher, therefore lowering the depth/time requirement implied to secure a > given tx amount. > > These are the two factors, demand and time. Less demand implies more time > to secure a given amount against double spend, and also implies a lower > cost to subsidize a censorship regime. But the latter requires a > differential in reward between the censor and non-censoring miners. While > this could be paid in side fees, that is a significant anonymity issue. > > e > > On Jul 7, 2022, at 10:37, Erik Aronesty <e...@q32.com> wrote: > > > > > We should not imbue real technology with magical qualities. > > > Precisely. It is economic forces (people), not technology, that provide > security. > > Yes, and these forces don't prevent double-spend / 51% attacks if the > amounts involved are greater than the incentives. > > In addition to "utility", lowering the block size could help prevent this > issue as well... increasing fee pressure and double-spend security while > reducing the burden on node operators. > > Changes to inflation are, very likely, off the table. > > > > On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via >> bitcoin-dev wrote: >> >> Billy, >> >> >> >> Proof of work and the difficulty adjustment function solve literally >> >> everything you are talking about already. >> > >> > Unfortunately you are quite wrong: the difficulty adjustment function >> merely >> > adjusts for changes in the amount of observable, non-51%-attacking, >> hashing >> > power. In the event of a chain split, the difficulty adjustment >> function does >> > nothing; against a 51% attacker, the difficulty adjustment does nothing; >> > against a censor, the difficulty adjustment does nothing. >> >> Consider falling hash rate due to a perpetual 51% attack. Difficulty >> falls, possibly to min difficulty if all non-censors stop mining and with >> all censors collaborating (one miner). Yet as difficulty falls, so does the >> cost of countering the censor. At min difficulty everyone can CPU mine >> again. >> >> Given the presumption that fees rise on unconfirmed transactions, there >> is inherent economic incentive to countering at any level of difficulty. >> Consequently the censor is compelled to subsidize the loss resulting from >> forgoing higher fee transactions that are incentivizing its competition. >> >> With falling difficulty this incentive is compounded. >> >> Comparisons of security in different scenarios presume a consistent level >> of demand. If that demand is insufficient to offset the censor’s subsidy, >> there is no security in any scenario. >> >> Given that the block subsidy (inflation) is paid equally to censoring and >> non-censoring miners, it offers no security against censorship whatsoever. >> Trading fee-based block reward for inflation-based is simply trading >> censorship resistance for the presumption of double-spend security. But of >> course, a censor can double spend profitably in any scenario where the >> double spend value (to the censor) exceeds that of blocks orphaned (as the >> censor earns 100% of all block rewards). >> >> Banks and state monies offer reasonable double spend security. Not sure >> that’s a trade worth making. >> >> It’s not clear to me that Satoshi understood this relation. I’ve seen no >> indication of it. However the decision to phase out subsidy, once a >> sufficient number of units (to assure divisibility) had been issued, is >> what transitions Bitcoin from a censorable to a censorship resistant money. >> If one does not believe there is sufficient demand for such a money, there >> is no way to reconcile that belief with a model of censorship resistance. >> >> > We should not imbue real technology with magical qualities. >> >> Precisely. It is economic forces (people), not technology, that provide >> security. >> >> e >> >> >> Bitcoin does not need active economic governanance by devs or meddlers. >> > >> > Yes, active governance would definitely be an exploitable mechanism. On >> the >> > other hand, the status quo of the block reward eventually going away >> entirely >> > is obviously a risky state change too. >> > >> >>>> There is also zero agreement on how much security would constitute >> such >> >>> an optimum. >> >>> >> >>> This is really step 1. We need to generate consensus on this long >> before >> >>> the block subsidy becomes too small. Probably in the next 10-15 >> years. I >> >>> wrote a paper >> > >> > The fact of the matter is that the present amount of security is about >> 1.7% of >> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% >> is also >> > already an amount low enough that it's much smaller than economic >> volatility. >> > >> > Obviously 0% is too small. >> > >> > There's zero reason to stress about finding an "optimal" amount. An >> amount low >> > enough to be easily affordable, but non-zero, is fine. 1% would be >> fine; 0.5% >> > would probably be fine; 0.1% would probably be fine. >> > >> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a >> 31% tax on >> > savings; 0.1% works out to be 7.2% >> > >> > These are all amounts that are likely to be dwarfed by economic shifts. >> > >> > -- >> > https://petertodd.org 'peter'[:-1]@petertodd.org >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
