Erik Aronesty [ARCHIVE] on Nostr: đź“… Original date posted:2022-07-07 đź“ť Original message:> > We should not imbue ...
đź“… Original date posted:2022-07-07
đź“ť Original message:> > 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 at lists.linuxfoundation.org> wrote:
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/45a46fbd/attachment.html>;
đź“ť Original message:> > 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 at lists.linuxfoundation.org> wrote:
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/45a46fbd/attachment.html>;