public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail•com>
To: Karl <gmkarl@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reducing block reward via soft fork
Date: Mon, 24 May 2021 10:28:41 -1000	[thread overview]
Message-ID: <CAGpPWDYJHP1WsJA9Rymb3GwMomCipVV7UV_eSVb_g-DbBkw32w@mail.gmail.com> (raw)
In-Reply-To: <CALL-=e6deZdsA+LLWBXJwYDf9x2x4sRxC1s=8fb2wH1paXpMBA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 10549 bytes --]

Before we can decide on tradeoffs that reduce security in favor of less
energy usage, or less inflation, or whatever goal you might have for
reducing (or delaying) coinbase rewards, we need to decide as a community
how much security bitcoin *needs*.

Do we need to be secure against an attacker with a budget of $1
billion/year for an attack? $10 billion/year? More?

An upper limit would be the budget of the largest government: the US. The
US federal budget is almost $5 trillion/year. But they certainly couldn't
spend all that budget attacking bitcoin. About $3 trillion of that is
mandatory spending, which couldn't be allocated to such an attack. About
$1.5 trillion is discretionary, which includes the military budget. It
seems like an upper limit on the amount that could be siphoned from that
budget to attack bitcoin would be 5%. That would take massive political
cooperation and wheeling and dealing. Likely spending that much would not
be politically feasible, but it seems possible, since a 5% reduction in
other activities is something other departments would likely be able to
sustain with just a bit of downsizing. Or that money could simply come from
more borrowing. 5% of $1.5 trillion is $75 billion. So that seems like a
pretty solid upper limit on the amount the US could allocate to an attack
in a year, in that it seems incredibly unlikely that more money than that
could be allocated. Such an expenditure might be eventually seen as
justified since the federal reserve has been inflating the supply of
dollars by 17.5% on average every year, which would be $1 trillion next
year (and more the next, etc). A similar story is told if you calculate the
amount of seigniorage banks get access to by their ability to use
fractional reserve to inflate the supply of M2 money.  It should be
considered tho that this seigniorage doesn't give its beneficiaries that
full value, but rather some fraction of that value - say 5% earned by being
first to buy with that new money and earning interest on it. So 5% of a
trillion is $50 billion. Still, over just two years, that's enough to pay
for an attack of at least that size ($75 billion).

The budget for the government of China is about $3.6 trillion, the second
largest in the world. And since they're an authoritarian country, they can
basically do whatever they want with that money. It still seems unlikely
they would spend more than 5% of that budget on doing something like
attacking bitcoin. However, consider that China's M2 money supply has been
increasing at a rate of almost $3 trillion per year. Protecting the ability
to do this is seems like something worth spending some (printed) money on.
So perhaps at some point, spending 10 or 20% of their budget for a year or
two to attack bitcoin might seem like a good idea to some mickey mouse in
the government. That would be $720 billion/year.

So given the amount of seigniorage taken in every year by these central
banks, it would seem to justify large expenditures. I'm not sure how
realistic it would be, politically speaking, to gather $720 billion in a
single year to attack bitcoin. It seems far fetched, even if the
seigniorage they're protecting seems to justify it.

So is this the level of attack we want to be resilient to? Nearly a $1
trillion attack? I don't know. But we should figure that out as a
community. And keep in mind, the level of attack we need to defend against
depends on the size of bitcoin. The more valuable bitcoins are, the more
damaging, more lucrative, and more valuable an attack would be for
attackers. Its seems reasonable to assume that this is a linear
relationship - that if bitcoins are worth twice as much, we need twice as
much security (ie we want to make attacking bitcoin twice as costly).

The next step is figuring out a reasonable lower bound for how much it
takes to attack bitcoin. There are many attacks that can be done on
bitcoin, but the one relevant to the discussion here is a 51% attack.
Bitcoin's PoW basically is attackable buy buying about 25% of the existing
mining power (for reasons like the selfish economic attack
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack>
and
the economic mining monopoly attack
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#economic-mining-monopoly-attack>),
which is about 40 exahashes/second.

If you bought 400,000 WhatsMiner M30S+ rigs
<https://www.buybitcoinworldwide.com/mining/hardware/> at current market
price, you'd need $1 billion to buy them all (which doesn't include the
cost of setting up all that equipment, powering it, building the network
infrastructure for it, etc etc). Let's say all that infra doubles the price
to $2 billion. Even then, you couldn't simply buy half a million mining
rigs from the market. That many just aren't available. An attacker would
have to spend year and years building up their mining operation before they
could actually perform the attack. They'd basically have to mine at a
slight (probably insignificant) loss for that time. Their demand would push
up the price of these mining rigs for at least a year or two until supply
comes up to meet it. So lets say this doubles the price of the mining rigs
(it could very well do significantly more than that). That makes for $3
billion to build up this malicious mining operation. China could seize a
mining pool, but likely couldn't do it quietly. They'd have to seize the
pool and immediately use it to attack before miners stop using the pool
(which might take a week or two). Maybe this would save them half the cost?

So, lower bound on cost of attack is $1.5 billion. Upper bound on US govt
attack is $72 billion. Upper bound on China govt attack is $720 billion. So
based on this back-of-the-napkin line of thinking, its not super clear that
reducing bitcoin's security is "enough" yet. There is also the question of:
does a $1 trillion currency need to be secure against a $720 billion
attack? Probably not. But should it be secure against a $10 billion attack?
Maybe.

However, the security will go up with price. If bitcoin goes up by 10x, as
it is wont to do, that's nearly 10x the security (nearly, since coinbase
rewards 10x, but the real value of fees almost certainly wouldn't go up as
much). So that brings us to $15 billion of security. Still not clear
without doing some more accurate analysis to determine more confidence in
tighter bounds on cost of attack and likely attack budgets.

But it certainly seems likely that my attack cost bounds are an order of
magnitude too low, and its equally possible my estimates of potential
available attack budgets are an order of magnitude too high. It doesn't
seem quite as likely the reverse is true (that my bounds aren't good
bounds).

It seems possible that we currently have enough security, but seems
likelier that we don't. It just isn't clear to me. Maybe someone has done
some more accurate analysis that could help here.

But before we talk about whether we should reduce our security to save
costs, we need to determine how much security we need and how much security
we have. Without good estimates with confident bounds, we simply can't make
an informed decision to reduce security.

> I don't think 99% of transactions need that level of security

Well you can't get security for the 1% of transactions that need it without
giving that security to all transactions on the chain. Also, the blockchain
security created by miners isn't really a per transaction thing anyway. An
attack would affect all bitcoins regardless of what transactions they do or
do not take part in.

On Sun, May 23, 2021 at 9:52 AM Karl via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> >> The turn-around time for that takes a population of both users and
> >> miners to cause. Increasing popularity of bitcoin has a far bigger
> >> impact here, and it is already raising fees and energy use at an
> >> established rate.
> >>
> >> If it becomes an issue, as bandwidth increases block size could be
> >> raised to lower fees.
> >>
> >
> > Which increases block rewards somewhat (at least to some level that
> matches
> > the overall security of the network) and you still have the same amount
> of
> > energy consumed.
>
> If you mean to implicitly propose that even if halved all the way with
> very large blocks, block rewards would just increase to the same
> level, meaning that any attempt to decrease them has no effect, I
> disagree.    I expect that if you raise the block size, eventually
> there is so much supply for transactions that there are no fees at all
> (nor security).  The numbers are all things the devs, miners, and
> users can together control.
>
> > How to prove this is not happening?
> > The best you can do is to have some number of authorities sign off on
> > whether or not they are doing this.
> > The problem is that authorities are bribeable.
>
> You could make the proof of work be a proof of environmental kindness
> by coding incentives for people to place and verify proof on the
> chain, and then rewarding people for acting on it as desired.  You
> could code the chain to pay people to investigate and prove miners'
> business practices, for example.  You could define the main chain as
> one where everyone consents the proofs are valid.  There are a lot of
> issues to resolve and it would be a very different chain.
>
> There is not a single solution here.  There are innumerable possible
> solutions, any one of which could be made to work with enough brains
> working on it.  To use one, we need to agree on what kinds of
> solutions are acceptable.
>
> > Alternately, other entities in the locality can use force to require the
> > polluting entity to clean up or suffer significant consequences.
> > This at least is better incentive-wise, as they others in the same
> locality
> > are the ones most affected, but the ability to enforce may be difficult
> due
> > to various political constructions; the miners could be in such deep
> cahoots
> > with the local government that the local government would willingly hurt
> > other local entities in the vicinity of the polluting entity.
>
> As bitcoin grows, if people ask some locality to enforce behavior,
> they may need to be willing to enforce it themselves, too, or they
> might outcompete the locality.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11834 bytes --]

  reply	other threads:[~2021-05-24 20:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-23  1:00 James Lu
2021-05-23 10:42 ` Anton Ragin
     [not found]   ` <CANQHGB2pD57cZzcuTqr25Pg-Bvon_=G=_5901to2esrcumk-GA@mail.gmail.com>
2021-05-23 14:40     ` [bitcoin-dev] Fwd: " James Lu
2021-05-23 11:26 ` [bitcoin-dev] " ZmnSCPxj
2021-05-23 12:08   ` Karl
2021-05-23 13:35     ` ZmnSCPxj
2021-05-23 19:44       ` Karl
2021-05-24 20:28         ` Billy Tetrud [this message]
2021-05-24 21:55           ` Erik Aronesty
2021-05-25  0:55           ` Karl
2021-05-25  8:01             ` Billy Tetrud
2021-05-25  8:35           ` Jorge Timón
2021-05-25  8:53           ` Melvin Carvalho
2021-05-25 19:40             ` Billy Tetrud
2021-05-24 22:03 ` Phuoc Do

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGpPWDYJHP1WsJA9Rymb3GwMomCipVV7UV_eSVb_g-DbBkw32w@mail.gmail.com \
    --to=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=gmkarl@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox