path: root/2b/5c8a15b5e53e31ee18b3308831e65ad533b46f

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1A4DCC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 19:41:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 08EC483CCE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 19:41:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.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 Qh7segeu6he8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 19:41:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [IPv6:2a00:1450:4864:20::534])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 716E5824CE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 19:41:19 +0000 (UTC)
Received: by mail-ed1-x534.google.com with SMTP id g7so25468732edm.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 12:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Exw5ME0VzW0a5hURVviQOtu4wihh4QjwY/stfe+VB5Q=;
 b=fNQ0uUSl8xZcCOTPDJvGKDWyZQxgRTG5/QgZYGhgmSAJ7Miyhf+IJjVEH/iwGqmNcd
 1HxifNB8fDC1wmZohx1BKc8exHFmxLGeAnYNIu6BeEqihw9oWs3Wl5hNwVFUXWbuKpWX
 asDnPz3BVV3/UcEnCoSqbkoD6FoZcencCm2a6yJLXxbL9A0hCLsa+HMGycGxNEZY6yLW
 hepVPJH9KL1YNQbmdYO9kkYjA+EJjXH7nOtMcs7SqmwpoEqMj2JROyAE/baSn/aqdhgr
 47CYR5cczchjSpgIrLU5tlqRoxtiN3ib5PiTRAPoNzABJ8JMdAlhiQCZzT/IF6z2JY+j
 90pQ==
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=Exw5ME0VzW0a5hURVviQOtu4wihh4QjwY/stfe+VB5Q=;
 b=t3ikQcOCkj9JwIECuEOGRpct5Aae3w1cb6RZx9Td4tfWL54Wmh4Qr3lqOpPAXrFbCK
 P+Drkgpc3lQ89zJkoo7mOoVeyw7Men2q/Ymr0q/4V0d5ViXDE5TsucawGClv7FOZcjPP
 hg7qQWBCSx2NdY1mvXPRT4tOgeCz+JRll21tQHyqPEZqpTEem12vL2GJEtxjg4ZWewfM
 5LDbHKxy9MqIUfSKXXrleDepapaMgkgCgdvqllcQYU9nbNd9ByI8D0f6r4cOVV/eIe+N
 aE6SnrN+9NyBhW21BWP9QoXILjZH86F1zPYXMZl984uso9k0xkCaP+iJNDdf/Ixi/Uto
 C9UQ==
X-Gm-Message-State: AOAM530DqkePN3AEGJGBs3rdteJNzhNt2jSZy4P78e0KuBUzI5qpXMtY
 P+UeS16aPRJ4ZKL8HAVzqiwXsq27+00aFp9VV4B8yPEUAj229Q==
X-Google-Smtp-Source: ABdhPJz9GfqpWeeaJuIgqGBiUSwtmVCssTqdY4gWi0oezjU0u3Pny4lyUR4vTk7cyHpVAPXabGnziUmMmUKQnPSgrDE=
X-Received: by 2002:a50:fb17:: with SMTP id d23mr32817846edq.338.1621971677533; 
 Tue, 25 May 2021 12:41:17 -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>
 <CAKaEYhJLQ80fno_fUouOd+bxNEh9W60H9XubSRQufOYh8OsmXw@mail.gmail.com>
In-Reply-To: <CAKaEYhJLQ80fno_fUouOd+bxNEh9W60H9XubSRQufOYh8OsmXw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 25 May 2021 09:40:58 -1000
Message-ID: <CAGpPWDbcdfyrXJ68kK1U81BfxWjRedFvYPLo8vaYy=QY64Wkwg@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000acdaa905c32cb54a"
X-Mailman-Approved-At: Tue, 25 May 2021 19:46:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 19:41:22 -0000

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

@Phuoc "Bitcoin, for now, is heading for destruction when inflation stops.
As a self-contained system, this happens when the block reward (plus fee)
decreases faster than the price rise."

Well, the block reward decreases less and less in comparison to fees every
halving. So it seems reasonably likely that will never happen because of
halvings, but might happen because of increased on-chain space. Block space
doesn't have a linear relationship with fees. I believe at any given point
in time, there should be an amount of on-chain space that will maximize
total fees collected per block, and either less space or more space will
reduce the total collected fees. I think at some point in the future, we
will have to find a way to modulate the blocksize in order to target a
particular band of security. I would be very surprised if fees couldn't
support enough security in the system by themselves in that future, at the
blocksize where maximum block reward occurs. Fees already contribute over
10% of the block rewards.

@Jorge "Sadly the notion that miners decide consensus rules is pretty
extended even among developers."

We don't currently have a good mechanism to decide by users in a verifiably
decentralized way. Polls are exploitable because of the Sybil problem (the
very problem bitcoin was invented to solve). I think one solution would be
to have the ability for users to sign an upgrade support petition with
their keys, proving how much coin supports the upgrade. The problem is
doing that now exposes people's public keys, which a lot of bitcoin has
been designed to keep safe until used to spend. It seems more recent things
(like in taproot) might be relaxing that protection, so I'm not sure what
the consensus on how important keeping public keys hidden is. But even if
keeping them hidden is important, we could create a new address that
encodes two public keys: one for spending and one for signing upgrade
petitions. That way people could expose the key for signing petitions
without exposing the public key for spending. Of course, that itself would
require a soft fork ; ) But there are real technical issues here. Saying
the devs are simply arrogantly dismissing the unwashed masses from upgrade
consensus gathering I don't think is something I've seen any evidence of.

@Melvin Its interesting that you point out that one kind of block reward is
steady and the other fluctuates. I think you're saying that fees fluctuate
and the coinbase rewards are steady. At first tho, I thought you might have
meant it the other way around ; ) On longer time scales (eg months rather
than days), fees have generally a more steady market-value than coinbase
rewards, since price fluctuates a lot, but people almost certainly set fees
somewhat based on the buying power of the fee rather than the absolute
bitcoin amount.

But I wouldn't think attacks are likely to be easier to perform at certain
times of the week that fees are lowest. Do miners actually mine less on
days when fees are lower? I wouldn't think they do. They already bought all
the hardware for mining, they might as well use it. It seems unlikely that
the cost of electricity and wear on the hardware would exceed the block
rewards even on low fee days. And looking to the future when there's no
significant coinbase subsidy, it seems rather likely that the daily/hourly
variance of the fee market will reduce, since there's an economic incentive
to delay transactions in order to pay a lower fee.

> how large a reorg would constitute an attack

Since the standard is 6 blocks, isn't 6 blocks sufficient for an attack to
be very disruptive? However, if an attack happens, the attacker likely has
>50% hashpower and can create much longer reorgs if they want, so I'm not
sure the length of the reorg is significant actually.




On Mon, May 24, 2021 at 10:53 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Mon, 24 May 2021 at 22: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.
>>
>
> Agree that it is valuable to find a reasonable lower bound to how much it
> take to 'attack' bitcoin
>
> Two observations:
>
> 1. The security model of bitcoin is dual and heterogeneous.  There is both
> a block subsidy and a fee model.  These are not like for like.  One is
> steady, and one fluctuates.  You might make the analogy with steady nuclear
> power, and intermittent wind power.  That means that an attack is more
> effective when fees are at their lowest.  We observe that fees tend to
> build up during the week and are cleared during the weekend, right now.
> Less of an issue right now, but in 3, 7, 11 years fees will make up a
> larger proportion of the total block reward, so maybe something to factor in
>
> 2. From the point of view of bitcoin an 'attack' is simply making the
> chain stronger (or longer) by increasing the accumulated proof of work.
> From the point of view of applications that rely on bitcoin blocks (layer2,
> exchanges, markets etc.) a reorg could be seen as disruptive, requiring
> more confirmations for larger transactions.  We might want to take a view
> on what a planned 'attack' or regorg might look like.  Satoshi when he put
> the first checkpoint in used 200 blocks as a guide.  Straw polling the
> community on this question has lead me to believe that there is a wide
> range of views on how large a reorg would constitute an attack
>
> IMHO it's valuable to work out what the community feels an attack might
> look like, and a lower bound to the cost. over time.  Bearing in mind
> there's going to be a wide spectrum of opinion, on the topic
>
> But, given that there's not been a successful attack in the last decade,
> we probably have a decent amount of time to figure this out
>
>
>>
>> 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
>>
>

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

<div dir=3D"ltr">@Phuoc &quot;Bitcoin, for now, is heading for destruction =
when inflation stops. As a self-contained system, this happens when the blo=
ck reward (plus fee) decreases faster than the price rise.&quot;<br><div><b=
r></div><div>Well, the block reward decreases less and less in comparison t=
o fees every halving. So it seems reasonably likely that will never happen =
because of halvings, but might happen because of increased on-chain space. =
Block space doesn&#39;t have a linear relationship with fees.=20

I believe at any given point in time, there should be an amount of on-chain=
 space that will maximize total fees collected per block, and either less s=
pace or more space will reduce the total collected fees. I think at some po=
int in the future, we will have to find a way to modulate the blocksize in =
order to target a particular band of security. I would be very surprised if=
 fees couldn&#39;t support enough security in the system by themselves in t=
hat future, at the blocksize=C2=A0where maximum block reward occurs. Fees a=
lready contribute over 10% of the block rewards.=C2=A0</div><div><br></div>=
<div>@Jorge &quot;Sadly the notion that miners decide consensus rules is pr=
etty extended even among developers.&quot;</div><div><br></div><div>We don&=
#39;t currently have a good mechanism to decide by users in a verifiably de=
centralized way. Polls are exploitable because of the Sybil problem (the ve=
ry problem bitcoin was invented to solve). I think one solution would be to=
 have the ability for users to sign an upgrade support petition with their =
keys, proving how much coin supports the upgrade. The problem is doing that=
 now exposes people&#39;s public keys, which a lot of bitcoin has been desi=
gned to keep safe until used to spend. It seems more recent things (like in=
 taproot) might be relaxing that protection, so I&#39;m not sure what the c=
onsensus on how important keeping public keys hidden is. But even if keepin=
g them hidden is important, we could create a new address that encodes two =
public keys: one for spending and one for signing upgrade petitions. That w=
ay people could expose the key for signing petitions without exposing the p=
ublic key for spending. Of course, that itself would require a soft fork ; =
) But there are real technical issues here. Saying the devs are simply arro=
gantly dismissing the unwashed masses from upgrade consensus gathering I do=
n&#39;t think is something I&#39;ve seen any evidence of.</div><div><br></d=
iv><div>@Melvin Its interesting that you point out that one kind of block r=
eward is steady and the other fluctuates. I think you&#39;re saying that fe=
es fluctuate and the coinbase rewards are steady. At first tho, I thought y=
ou might have meant it the other way around ; ) On longer time scales (eg m=
onths rather than days), fees have generally a more steady=20

market-value than coinbase rewards, since price fluctuates a lot, but peopl=
e almost certainly set fees somewhat based on the buying power of the fee r=
ather than the absolute bitcoin amount.=C2=A0<br></div><div><br></div><div>=
But I wouldn&#39;t think attacks are likely to be easier to perform at cert=
ain times of the week that fees are lowest. Do miners actually mine less on=
 days when fees are lower? I wouldn&#39;t think they do. They already bough=
t all the hardware for mining, they might as well use it. It seems unlikely=
 that the cost of electricity and wear on the hardware would exceed the blo=
ck rewards even on low fee days. And looking to the future when there&#39;s=
 no significant coinbase subsidy, it seems rather likely that the daily/hou=
rly variance of the fee market will reduce, since there&#39;s an economic i=
ncentive to delay transactions in order to pay a lower fee.=C2=A0</div><div=
><br></div><div>&gt; how large a reorg would constitute an attack</div><div=
><br></div><div>Since the standard is 6 blocks, isn&#39;t 6 blocks sufficie=
nt for an attack to be very disruptive? However, if an attack happens, the =
attacker likely has &gt;50% hashpower and can create much longer reorgs if =
they want, so I&#39;m not sure the length of the reorg is significant=C2=A0=
actually.=C2=A0</div><div><br></div><div><br></div><div><br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, M=
ay 24, 2021 at 10:53 PM Melvin Carvalho &lt;<a href=3D"mailto:melvincarvalh=
o@gmail.com">melvincarvalho@gmail.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Mon, 24 May 2021 at 22:32, Billy Tetrud via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr">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, w=
e 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 b=
udget 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=A0=
government: the US. The US federal budget is almost $5 trillion/year. But t=
hey certainly couldn&#39;t spend all that budget attacking bitcoin. About $=
3 trillion of that is mandatory spending, which couldn&#39;t be allocated t=
o such an attack. About $1.5 trillion is discretionary, which 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 tak=
e massive political cooperation and wheeling and dealing. Likely spending t=
hat much would not be politically feasible, but it seems possible, since a =
5% reduction in other activities is something other departments would likel=
y be able to sustain with just a bit of downsizing. Or that money could sim=
ply come from more borrowing. 5% of $1.5 trillion is $75 billion. So that s=
eems 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 dol=
lars 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 amoun=
t of seigniorage banks get access to by their ability to use fractional res=
erve 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">selfish economic attack</a>=C2=A0and the <=
a href=3D"https://github.com/fresheneesz/quantificationOfConsensusProtocolS=
ecurity#economic-mining-monopoly-attack" target=3D"_blank">economic mining =
monopoly attack</a>), which is about 40 exahashes/second.=C2=A0</div></div>=
</blockquote><div><br></div><div>Agree that it is valuable to find a reason=
able lower bound to how much it take to &#39;attack&#39; bitcoin</div><div>=
<br></div><div>Two observations:</div><div><br></div><div>1. The security m=
odel of bitcoin is dual and heterogeneous.=C2=A0 There is both a block subs=
idy and a fee model.=C2=A0 These are not like for like.=C2=A0 One is steady=
, and one fluctuates.=C2=A0 You might make the analogy with steady nuclear =
power, and intermittent wind power.=C2=A0 That means that an attack is more=
 effective when fees are at their lowest.=C2=A0 We observe that fees tend t=
o build up during the week and are cleared during the weekend, right now.=
=C2=A0 Less of an issue right now, but in 3, 7, 11 years fees will make up =
a larger proportion of the total block reward, so maybe something to factor=
 in<br></div><div><br></div><div>2. From the point of view of bitcoin an &#=
39;attack&#39; is simply making the chain stronger (or longer) by increasin=
g the accumulated proof of work.=C2=A0 From the point of view of applicatio=
ns that rely on bitcoin blocks (layer2, exchanges, markets etc.) a reorg co=
uld be seen as disruptive, requiring more confirmations for larger transact=
ions.=C2=A0 We might want to take a view on what a planned &#39;attack&#39;=
 or regorg might look like.=C2=A0 Satoshi when he put the first checkpoint =
in used 200 blocks as a guide.=C2=A0 Straw polling the community on this qu=
estion has lead me to believe that there is a wide range of views on how la=
rge a reorg would constitute an attack</div><div><br></div><div>IMHO it&#39=
;s valuable to work out what the community feels an attack might look like,=
 and a lower bound to the cost. over time.=C2=A0 Bearing in mind there&#39;=
s going to be a wide spectrum of opinion, on the topic</div><div><br></div>=
<div>But, given that there&#39;s not been a successful attack in the last d=
ecade, we probably have a decent amount of time to figure this out<br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div><br></div><div>If you bought 400,000=C2=A0<a href=3D"https:/=
/www.buybitcoinworldwide.com/mining/hardware/" target=3D"_blank">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 equ=
ipment, powering it, building the network infrastructure for it, etc etc). =
Let&#39;s say all that infra doubles the price to $2 billion. Even then, yo=
u 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 ye=
ars building up their mining operation before they could actually perform t=
he attack. They&#39;d basically have to mine at a slight (probably insignif=
icant) loss for that time. Their demand would push up the price of these mi=
ning rigs for at least a year or two until supply comes up to meet it. So l=
ets say this doubles the price of the mining rigs (it could very well do si=
gnificantly more than that). That makes for $3 billion to build up this mal=
icious mining operation. China could 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 them 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 g=
ovt 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&#39;s security is &quot;enough&quot; yet. There is a=
lso 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.=C2=A0</div><div><br></div><div>However, the security=
 will go up with price. If bitcoin goes up by 10x, as it is wont to do, tha=
t&#39;s nearly 10x the security (nearly, since coinbase rewards 10x, but th=
e real value of fees almost certainly wouldn&#39;t go up as much). So that =
brings us to $15 billion of security. Still not clear without doing some mo=
re accurate analysis to determine more confidence in tighter bounds on cost=
 of attack and likely attack budgets.=C2=A0</div><div><br></div><div>But it=
 certainly seems likely that my attack cost bounds are an order of magnitud=
e too low, and its equally possible my estimates of potential available att=
ack budgets are an order of magnitude too high. It doesn&#39;t seem quite a=
s likely the reverse is true (that my bounds aren&#39;t good bounds).</div>=
<div><br></div><div>It seems possible that we currently have enough securit=
y, but seems likelier that we don&#39;t. It just isn&#39;t clear to me. May=
be someone has done some more accurate analysis that could help here.=C2=A0=
</div><div><br></div><div>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 bound=
s, we simply can&#39;t make an informed decision to reduce security.</div><=
div><br></div><div>&gt; I don&#39;t think 99% of transactions need that lev=
el 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 al=
l transactions on the chain. Also, the blockchain security created by miner=
s isn&#39;t really a per transaction thing anyway. An attack would affect a=
ll bitcoins regardless of what transactions they do or do not take part in.=
</div></div><br><div class=3D"gmail_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"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">&gt;&gt; The turn-around time for that takes a pop=
ulation of both 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">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/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">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</blockquote></div>

--000000000000acdaa905c32cb54a--