path: root/22/ed018713de09f97379bc9a4fb75898e324c6b8

Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9BF4AC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 08:36:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8B9E783544
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 08:36:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20150623.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id eJNRzfqPtI1g
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 08:36:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
 [IPv6:2607:f8b0:4864:20::b2e])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 4F8F883AD1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 08:36:10 +0000 (UTC)
Received: by mail-yb1-xb2e.google.com with SMTP id z38so12295814ybh.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 01:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Vxf2LsppsVoZ+bSWbp8yvs1hfmOnk9IZn9afb7quQIU=;
 b=p7dh6GXD6DpDTMjCjwH4lYt6do5RWRJJ2JS4lD0tzZd3H1d4C6QLcAo8yLnoBc1A+N
 783YezClT0ky4w6KZiRj9K2y55hP90+Yc9hl5fM+xZenvItWjdCgGuG/TGr8iyB6YkZ+
 7vOvPZiddQtfyDWtE8QxoSqlYd7Tts45x+oVxA3EcLTIYk4gunaOd5jqO/P6exXgCz12
 703Hhg4yZe9Q/dfrFYkNjpcULJ1TIgFGwwk9GbVlUFFSnFW0zyMJ/CsPAcaoEZF+Njck
 SPGzjBsBMGZja8PAwj2W6d5kASDeLhG9C4XfETplYda+8SOmMGQfxq5W2H0HIVnEZgpB
 JzpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Vxf2LsppsVoZ+bSWbp8yvs1hfmOnk9IZn9afb7quQIU=;
 b=HrjOkzCpXiRU2LeHd/aCJBRnZmbcUveWdacXU81w0nuu0vCjA/xd20YLZ8OVgukwPV
 DvnE8goi0cpkP114GhD1x0CBBE3cPAgJ9S5ycEuH1z4vAPHAmWxsCRU5D/T+EbQt4Te7
 Pn4ZzMUwFuMMGQpksLCpAVChp2ph6vT+VGXteff8LwxVZjs4F6lX0muEilmaAaNRQyDg
 V319fCriKOwGZrDfkv6nlNnOQRNKqFc14nxd8YMmz26eZQdC7zmtF3SOwAk8v5meoyXD
 najPF4d0pdr292SBBaE1F2RX4slRigcgRFXPeUQXfBj2p2zbPg8f6xSv6oRaMvI4KPUi
 WYmg==
X-Gm-Message-State: AOAM533LZMBRahWljIKLpmLiSD+dHi05Dw2yJjG740yspITWIt4Jpvie
 UPkzjOCnsE2FTJpOxBbjZXm2rD9DcUT3sMXge1lHGQ==
X-Google-Smtp-Source: ABdhPJyRcuhmj71AuiqHybgv67J41dsMk6hTKz43BWcQ8Ya9f1NDoI6G72vhBNGiNbnXTreu0aTi9t6PPTP//P8o9Uo=
X-Received: by 2002:a25:664c:: with SMTP id z12mr18196625ybm.84.1621931769170; 
 Tue, 25 May 2021 01:36:09 -0700 (PDT)
MIME-Version: 1.0
References: <CANQHGB1N4E9=cqrkxDiUH5hAHgzURAJv+S7Vkf8xWEMJ=+T_AQ@mail.gmail.com>
 <KVDgWlVOrIW9ahW8jA8W1eSK-w0OzVEjx585MpJiNL-SuX9x-td_VzNEtFSDNj-bwulh_nLExtNBl4WD6x2Ipjp9bQvT4Jo3NIqoyDxoBBM=@protonmail.com>
 <CALL-=e7hHYm96KJEFEiTgEaSjK0VTcNcGypLVekmaxYNN+egEA@mail.gmail.com>
 <G3RgofdarOhSiEJjyDNaN2Dv27WCpb_0CSOpya6acUnPbpPQ-oygklpP_e0rLdxglK5FCo5dq7Qkv6GinA3qCXiOM6GzEcNvcxxM7kbwFhY=@protonmail.com>
 <CALL-=e6deZdsA+LLWBXJwYDf9x2x4sRxC1s=8fb2wH1paXpMBA@mail.gmail.com>
 <CAGpPWDYJHP1WsJA9Rymb3GwMomCipVV7UV_eSVb_g-DbBkw32w@mail.gmail.com>
In-Reply-To: <CAGpPWDYJHP1WsJA9Rymb3GwMomCipVV7UV_eSVb_g-DbBkw32w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Tue, 25 May 2021 09:35:56 +0100
Message-ID: <CABm2gDp4NvCRgu6EF=xfBf3XLzKHSAEFdftPSxEDbhEiacSn1w@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f39c8005c3236a81"
Subject: Re: [bitcoin-dev] Reducing block reward via soft fork
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2021 08:36:12 -0000

--000000000000f39c8005c3236a81
Content-Type: text/plain; charset="UTF-8"

Your analysis is correct.
In perfect competition, profits tend to zero, which means the costs of
mining tend to equal the reward.
Since the reward is fees plus subsidy, reducing the subsidy should reduce
mining costs.

I think convincing other users we need such a softfork to reeuce the
subsidy is going to be hard though.
Even among developers, these proposals seem to be kind of taboo, because
people tene to perceive them as "attacking miners".
Sadly the notion that miners decide consensus rules is pretty extended even
among developers. The recent bip8(true) vs bip8(false) discussions are
anundant evidence that this is the case. Most devs perceive that not giving
miners veto power over proposals somehow means that then developers become
dictators who can unilaterally decide the rules.
They don't accept the fact that it's users who decide the consensus rules.
For them, if it's not miners who decide, then it must be devs. That's
because they see users as a bunch of uninformed imbeciles who can't
understand anything or decide anything. And yet this arrogant position is
coming from people who seemingly don't understand section 11 of the
whitepaper when it says "even with a hashrate majority, that doesn't allow
one to arbitrarily change the rules or forge signatures" which can be
summarized to "miners DO NOT decide the rules.

Given these deeps misunderstandings, most devs (and who knows how many
users) will consider a softfork to reduce mining subsidy "impossible, since
miners will oppose it".
This incredibly sad situation is where we're at.

I personally would be in favor of a softfork to reduce the subsidy. That
would hopefully pacify some of the people concerned with bitcoin's energy
consumption. Bitcoin ecologists should defend this and not "proof of stake"
and other technical nonsense.







On Mon, May 24, 2021, 21:32 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000f39c8005c3236a81
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Your analysis is correct.=C2=A0<div dir=3D"auto">In perfe=
ct competition, profits tend to zero, which means the costs of mining tend =
to equal the reward.</div><div dir=3D"auto">Since the reward is fees plus s=
ubsidy, reducing the subsidy should reduce mining costs.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">I think convincing other users we need suc=
h a softfork to reeuce the subsidy is going to be hard though.</div><div di=
r=3D"auto">Even among developers, these proposals seem to be kind of taboo,=
 because people tene to perceive them as &quot;attacking miners&quot;.</div=
><div dir=3D"auto">Sadly the notion that miners decide consensus rules is p=
retty extended even among developers. The recent bip8(true) vs bip8(false) =
discussions are anundant evidence that this is the case. Most devs perceive=
 that not giving miners veto power over proposals somehow means that then d=
evelopers become dictators who can unilaterally decide the rules.</div><div=
 dir=3D"auto">They don&#39;t accept the fact that it&#39;s users who decide=
 the consensus rules. For them, if it&#39;s not miners who decide, then it =
must be devs. That&#39;s because they see users as a bunch of uninformed im=
beciles who can&#39;t understand anything or decide anything. And yet this =
arrogant position is coming from people who seemingly don&#39;t understand =
section 11 of the whitepaper when it says &quot;even with a hashrate majori=
ty, that doesn&#39;t allow one to arbitrarily change the rules or forge sig=
natures&quot; which can be summarized to &quot;miners DO NOT decide the rul=
es.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Given these deeps mi=
sunderstandings, most devs (and who knows how many users) will consider a s=
oftfork to reduce mining subsidy &quot;impossible, since miners will oppose=
 it&quot;.</div><div dir=3D"auto">This incredibly sad situation is where we=
&#39;re at.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I personally=
 would be in favor of a softfork to reduce the subsidy. That would hopefull=
y pacify some of the people concerned with bitcoin&#39;s energy consumption=
. Bitcoin ecologists should defend this and not &quot;proof of stake&quot; =
and other technical nonsense.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 24, 2021=
, 21:32 Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Before we can dec=
ide on tradeoffs that reduce security in favor of less energy usage, or les=
s inflation, or whatever goal you might have for reducing (or delaying) coi=
nbase rewards, we need to decide as a community how much security bitcoin=
=C2=A0*needs*.=C2=A0<div><br></div><div>Do we need to be secure against an =
attacker with a budget of $1 billion/year for an attack? $10 billion/year? =
More?=C2=A0</div><div><br></div><div>An upper limit would be the budget of =
the largest=C2=A0government: the US. The US federal budget is almost $5 tri=
llion/year. But they certainly couldn&#39;t spend all that budget attacking=
 bitcoin. About $3 trillion of that is mandatory spending, which couldn&#39=
;t be allocated to such an attack. About $1.5 trillion is discretionary, wh=
ich includes the military=C2=A0budget. 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 p=
ossible, since a 5% reduction in other activities is something other depart=
ments would likely be able to sustain with just a bit of downsizing. Or tha=
t money could simply come from more borrowing. 5% of $1.5 trillion is $75 b=
illion. 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 tri=
llion next year (and more the next, etc). A similar story is told if you ca=
lculate the amount of seigniorage banks get access to by their ability to u=
se fractional reserve to inflate the supply of M2 money.=C2=A0

It should be considered tho that this seigniorage doesn&#39;t give its bene=
ficiaries 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&#39;=
s enough to pay for an attack of at least that size ($75 billion).=C2=A0=20

</div><div><br></div><div>The budget for the government of China is about $=
3.6 trillion, the second largest in the world. And since they&#39;re an aut=
horitarian country, they can basically do whatever they want with that mone=
y. It still seems unlikely they would spend more than 5% of that budget on =
doing something like attacking bitcoin. However, consider that China&#39;s =
M2 money supply has been increasing at a rate of almost $3 trillion per yea=
r. 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 t=
heir 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.=
=C2=A0</div><div><br></div><div>So given the amount of seigniorage taken in=
 every year by these central banks, it would seem to justify large expendit=
ures. I&#39;m not sure how realistic it would be, politically speaking, to =
gather $720 billion in a single year to attack bitcoin. It seems far fetche=
d, even if the seigniorage they&#39;re protecting seems to justify it.=C2=
=A0</div><div><br></div><div>So is this the level of attack we want to be r=
esilient to? Nearly a $1 trillion attack? I don&#39;t know. But we should f=
igure that out as a community. And keep in mind, the level of attack we nee=
d to defend against depends on the size of bitcoin. The more valuable bitco=
ins are, the more damaging, more lucrative, and more valuable an attack wou=
ld be for attackers. Its seems reasonable to assume that this is a linear r=
elationship - that if bitcoins are worth twice as much, we need twice as mu=
ch security (ie we want to make attacking bitcoin twice as costly).=C2=A0</=
div><div><br></div><div>The next step is figuring out a reasonable lower bo=
und for how much it takes to attack bitcoin. There are many attacks that ca=
n be done on bitcoin, but the one relevant to the discussion here is a 51% =
attack. Bitcoin&#39;s PoW basically is attackable buy buying about 25% of t=
he existing mining power (for reasons like the=C2=A0<a href=3D"https://gith=
ub.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-ec=
onomic-attack" target=3D"_blank" rel=3D"noreferrer">selfish economic attack=
</a>=C2=A0and the <a href=3D"https://github.com/fresheneesz/quantificationO=
fConsensusProtocolSecurity#economic-mining-monopoly-attack" target=3D"_blan=
k" rel=3D"noreferrer">economic mining monopoly attack</a>), which is about =
40 exahashes/second.=C2=A0</div><div><br></div><div>If you bought 400,000=
=C2=A0<a href=3D"https://www.buybitcoinworldwide.com/mining/hardware/" targ=
et=3D"_blank" rel=3D"noreferrer">WhatsMiner M30S+ rigs</a>=C2=A0at current =
market price, you&#39;d need $1 billion to buy them all (which doesn&#39;t =
include the cost of setting up all that equipment, powering it, building th=
e network infrastructure for it, etc etc). Let&#39;s say all that infra dou=
bles the price to $2 billion. Even then, you couldn&#39;t simply buy half a=
 million mining rigs from the market. That many just aren&#39;t available. =
An attacker would have to spend year and years building up their mining ope=
ration before they could actually perform the attack. They&#39;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 o=
f the mining rigs (it could very well do significantly more than that). Tha=
t makes for $3 billion to build up this malicious mining operation. China c=
ould seize a mining pool, but likely couldn&#39;t do it quietly. They&#39;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 the=
m half the cost?=C2=A0</div><div><br></div><div>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-n=
apkin line of thinking, its not super clear that reducing bitcoin&#39;s sec=
urity is &quot;enough&quot; yet. There is also the question of: does a $1 t=
rillion currency need to be secure against a $720 billion attack? Probably =
not. But should it be secure against a $10 billion attack? Maybe.=C2=A0</di=
v><div><br></div><div>However, the security will go up with price. If bitco=
in goes up by 10x, as it is wont to do, that&#39;s nearly 10x the security =
(nearly, since coinbase rewards 10x, but the real value of fees almost cert=
ainly wouldn&#39;t go up as much). So that brings us to $15 billion of secu=
rity. Still not clear without doing some more accurate analysis to determin=
e more confidence in tighter bounds on cost of attack and likely attack bud=
gets.=C2=A0</div><div><br></div><div>But it certainly seems likely that my =
attack cost bounds are an order of magnitude too low, and its equally possi=
ble my estimates of potential available attack budgets are an order of magn=
itude too high. It doesn&#39;t seem quite as likely the reverse is true (th=
at my bounds aren&#39;t good bounds).</div><div><br></div><div>It seems pos=
sible that we currently have enough security, but seems likelier that we do=
n&#39;t. It just isn&#39;t clear to me. Maybe someone has done some more ac=
curate analysis that could help here.=C2=A0</div><div><br></div><div>But be=
fore 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&#39;t make an i=
nformed decision to reduce security.</div><div><br></div><div>&gt; I don&#3=
9;t think 99% of transactions need that level of security<br></div><div><br=
></div><div>Well you can&#39;t get security for the 1% of transactions that=
 need it without giving that security to all transactions on the chain. Als=
o, the blockchain security created by miners isn&#39;t really a per transac=
tion thing anyway. An attack would affect all bitcoins regardless of what t=
ransactions they do or do not take part in.</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 23, 2021 at 9:=
52 AM Karl via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">&gt;&gt; The turn-around time for that takes a population of bo=
th users and<br>
&gt;&gt; miners to cause. Increasing popularity of bitcoin has a far bigger=
<br>
&gt;&gt; impact here, and it is already raising fees and energy use at an<b=
r>
&gt;&gt; established rate.<br>
&gt;&gt;<br>
&gt;&gt; If it becomes an issue, as bandwidth increases block size could be=
<br>
&gt;&gt; raised to lower fees.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Which increases block rewards somewhat (at least to some level that ma=
tches<br>
&gt; the overall security of the network) and you still have the same amoun=
t of<br>
&gt; energy consumed.<br>
<br>
If you mean to implicitly propose that even if halved all the way with<br>
very large blocks, block rewards would just increase to the same<br>
level, meaning that any attempt to decrease them has no effect, I<br>
disagree.=C2=A0 =C2=A0 I expect that if you raise the block size, eventuall=
y<br>
there is so much supply for transactions that there are no fees at all<br>
(nor security).=C2=A0 The numbers are all things the devs, miners, and<br>
users can together control.<br>
<br>
&gt; How to prove this is not happening?<br>
&gt; The best you can do is to have some number of authorities sign off on<=
br>
&gt; whether or not they are doing this.<br>
&gt; The problem is that authorities are bribeable.<br>
<br>
You could make the proof of work be a proof of environmental kindness<br>
by coding incentives for people to place and verify proof on the<br>
chain, and then rewarding people for acting on it as desired.=C2=A0 You<br>
could code the chain to pay people to investigate and prove miners&#39;<br>
business practices, for example.=C2=A0 You could define the main chain as<b=
r>
one where everyone consents the proofs are valid.=C2=A0 There are a lot of<=
br>
issues to resolve and it would be a very different chain.<br>
<br>
There is not a single solution here.=C2=A0 There are innumerable possible<b=
r>
solutions, any one of which could be made to work with enough brains<br>
working on it.=C2=A0 To use one, we need to agree on what kinds of<br>
solutions are acceptable.<br>
<br>
&gt; Alternately, other entities in the locality can use force to require t=
he<br>
&gt; polluting entity to clean up or suffer significant consequences.<br>
&gt; This at least is better incentive-wise, as they others in the same loc=
ality<br>
&gt; are the ones most affected, but the ability to enforce may be difficul=
t due<br>
&gt; to various political constructions; the miners could be in such deep c=
ahoots<br>
&gt; with the local government that the local government would willingly hu=
rt<br>
&gt; other local entities in the vicinity of the polluting entity.<br>
<br>
As bitcoin grows, if people ask some locality to enforce behavior,<br>
they may need to be willing to enforce it themselves, too, or they<br>
might outcompete the locality.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000f39c8005c3236a81--