đź“… 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>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 23:11:02
in reply to nevent1q…w7ue
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:11:02Event JSON
{
"id": "14a961e9837aa951f97ccffda37182671b6af92ddb501c014d10cc897118e0b0",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686179462,
"kind": 1,
"tags": [
[
"e",
"7b48b1d81caa6040c3accea765079d236c2aa24c40321303ab071f7798b24c6d",
"",
"root"
],
[
"e",
"e5d0a40db763229b7a08270e5b05b234a9bd9818eee64066ffce321b6c2af793",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2022-07-07\n📝 Original message:\u003e \u003e We should not imbue real technology with magical qualities.\n\n\u003e Precisely. It is economic forces (people), not technology, that provide\nsecurity.\n\nYes, and these forces don't prevent double-spend / 51% attacks if the\namounts involved are greater than the incentives.\n\nIn addition to \"utility\", lowering the block size could help prevent this\nissue as well... increasing fee pressure and double-spend security while\nreducing the burden on node operators.\n\nChanges to inflation are, very likely, off the table.\n\n\n\nOn Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e \u003e On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev\n\u003e wrote:\n\u003e \u003e\u003e Billy,\n\u003e \u003e\u003e\n\u003e \u003e\u003e Proof of work and the difficulty adjustment function solve literally\n\u003e \u003e\u003e everything you are talking about already.\n\u003e \u003e\n\u003e \u003e Unfortunately you are quite wrong: the difficulty adjustment function\n\u003e merely\n\u003e \u003e adjusts for changes in the amount of observable, non-51%-attacking,\n\u003e hashing\n\u003e \u003e power. In the event of a chain split, the difficulty adjustment function\n\u003e does\n\u003e \u003e nothing; against a 51% attacker, the difficulty adjustment does nothing;\n\u003e \u003e against a censor, the difficulty adjustment does nothing.\n\u003e\n\u003e Consider falling hash rate due to a perpetual 51% attack. Difficulty\n\u003e falls, possibly to min difficulty if all non-censors stop mining and with\n\u003e all censors collaborating (one miner). Yet as difficulty falls, so does the\n\u003e cost of countering the censor. At min difficulty everyone can CPU mine\n\u003e again.\n\u003e\n\u003e Given the presumption that fees rise on unconfirmed transactions, there is\n\u003e inherent economic incentive to countering at any level of difficulty.\n\u003e Consequently the censor is compelled to subsidize the loss resulting from\n\u003e forgoing higher fee transactions that are incentivizing its competition.\n\u003e\n\u003e With falling difficulty this incentive is compounded.\n\u003e\n\u003e Comparisons of security in different scenarios presume a consistent level\n\u003e of demand. If that demand is insufficient to offset the censor’s subsidy,\n\u003e there is no security in any scenario.\n\u003e\n\u003e Given that the block subsidy (inflation) is paid equally to censoring and\n\u003e non-censoring miners, it offers no security against censorship whatsoever.\n\u003e Trading fee-based block reward for inflation-based is simply trading\n\u003e censorship resistance for the presumption of double-spend security. But of\n\u003e course, a censor can double spend profitably in any scenario where the\n\u003e double spend value (to the censor) exceeds that of blocks orphaned (as the\n\u003e censor earns 100% of all block rewards).\n\u003e\n\u003e Banks and state monies offer reasonable double spend security. Not sure\n\u003e that’s a trade worth making.\n\u003e\n\u003e It’s not clear to me that Satoshi understood this relation. I’ve seen no\n\u003e indication of it. However the decision to phase out subsidy, once a\n\u003e sufficient number of units (to assure divisibility) had been issued, is\n\u003e what transitions Bitcoin from a censorable to a censorship resistant money.\n\u003e If one does not believe there is sufficient demand for such a money, there\n\u003e is no way to reconcile that belief with a model of censorship resistance.\n\u003e\n\u003e \u003e We should not imbue real technology with magical qualities.\n\u003e\n\u003e Precisely. It is economic forces (people), not technology, that provide\n\u003e security.\n\u003e\n\u003e e\n\u003e\n\u003e \u003e\u003e Bitcoin does not need active economic governanance by devs or meddlers.\n\u003e \u003e\n\u003e \u003e Yes, active governance would definitely be an exploitable mechanism. On\n\u003e the\n\u003e \u003e other hand, the status quo of the block reward eventually going away\n\u003e entirely\n\u003e \u003e is obviously a risky state change too.\n\u003e \u003e\n\u003e \u003e\u003e\u003e\u003e There is also zero agreement on how much security would constitute\n\u003e such\n\u003e \u003e\u003e\u003e an optimum.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e This is really step 1. We need to generate consensus on this long\n\u003e before\n\u003e \u003e\u003e\u003e the block subsidy becomes too small. Probably in the next 10-15 years.\n\u003e I\n\u003e \u003e\u003e\u003e wrote a paper\n\u003e \u003e\n\u003e \u003e The fact of the matter is that the present amount of security is about\n\u003e 1.7% of\n\u003e \u003e the total coin supply/year, and Bitcoin seems to be working fine. 1.7%\n\u003e is also\n\u003e \u003e already an amount low enough that it's much smaller than economic\n\u003e volatility.\n\u003e \u003e\n\u003e \u003e Obviously 0% is too small.\n\u003e \u003e\n\u003e \u003e There's zero reason to stress about finding an \"optimal\" amount. An\n\u003e amount low\n\u003e \u003e enough to be easily affordable, but non-zero, is fine. 1% would be fine;\n\u003e 0.5%\n\u003e \u003e would probably be fine; 0.1% would probably be fine.\n\u003e \u003e\n\u003e \u003e Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31%\n\u003e tax on\n\u003e \u003e savings; 0.1% works out to be 7.2%\n\u003e \u003e\n\u003e \u003e These are all amounts that are likely to be dwarfed by economic shifts.\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/45a46fbd/attachment.html\u003e",
"sig": "2b05801db5120277e9e957699cc7ae1a06dc86b81ba8d5bde8a84f758b194d2bb702f1dc62f82594ab82183483dd5d665749af064c709d55c6ef47534d8528d5"
}