* [bitcoin-dev] Reducing block reward via soft fork
@ 2021-05-23 1:00 James Lu
2021-05-23 10:42 ` Anton Ragin
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: James Lu @ 2021-05-23 1:00 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
Background
===
Reducing the block reward reduces the incentive to mine. It reduces the
maximum energy price at which mining is profitable, reducing the energy use.
Bitcoins have value because they are accepted by full node users, from
individual node operators, to exchanges and custodians like Coinbase.
Anything else and the Bitcoins don't exist and are worthless. Like all
currencies, Bitcoin has value because others recognize that they have value.
Idea
===
Reduce the block reward by adding fewer coins to the UTXO set per block.
This should be done gradually
Consensus layer
===
This is a soft fork, because it tightens the
Some Possible Weaknesses
===
- It will cost less than a nation-state of energy to reverse recent Bitcoin
transactions.
- Some miners may protest and lobby exchanges.
- By pushing mining towards the cheapest energy sources, centralization
increases towards Chinese miners.
- The Bitcoin network may split if consensus is not built before flag day.
However, given the current political headwinds and widespread public
discussion around Bitcoin's energy use, it may be socially possible to ask
individual users and major exchanges to install a version of Bitcoin with a
reduced block reward.
Alternatives
===
Instead of outright rejecting transactions (and the blocks that contain
them) that attempt to spend increased block rewards, treat them as no-ops.
[-- Attachment #2: Type: text/html, Size: 4538 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 1:00 [bitcoin-dev] Reducing block reward via soft fork James Lu
@ 2021-05-23 10:42 ` Anton Ragin
[not found] ` <CANQHGB2pD57cZzcuTqr25Pg-Bvon_=G=_5901to2esrcumk-GA@mail.gmail.com>
2021-05-23 11:26 ` [bitcoin-dev] " ZmnSCPxj
2021-05-24 22:03 ` Phuoc Do
2 siblings, 1 reply; 15+ messages in thread
From: Anton Ragin @ 2021-05-23 10:42 UTC (permalink / raw)
To: James Lu, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]
Well, it is done automatically every 4 years :) It is a self-balancing
system - more people shout about Bitcoin being dirty -> less adoption ->
lower the price -> less energy consumption. Add on top the fact that in
2024 block rewards will fall 50% anyway and someday it will be zero.
I am all for making Bitcoin green(er), but IMHO there shall be no
short-termism of the sort "Elon complained + price dropped 40% - lets go
radically change things".
IMHO if we want to make BTC cleaner we can add functionality where users
can prioritise some miners over the others, with the view that users will
prioritise "green" miners and they will get more TX fees, and there will be
economic incentive to go green.
On Sun, 23 May 2021, 09:49 James Lu via bitcoin-dev, <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Background
> ===
> Reducing the block reward reduces the incentive to mine. It reduces the
> maximum energy price at which mining is profitable, reducing the energy use.
>
> Bitcoins have value because they are accepted by full node users, from
> individual node operators, to exchanges and custodians like Coinbase.
> Anything else and the Bitcoins don't exist and are worthless. Like all
> currencies, Bitcoin has value because others recognize that they have value.
>
> Idea
> ===
> Reduce the block reward by adding fewer coins to the UTXO set per block.
> This should be done gradually
>
> Consensus layer
> ===
> This is a soft fork, because it tightens the
>
> Some Possible Weaknesses
> ===
> - It will cost less than a nation-state of energy to reverse recent
> Bitcoin transactions.
> - Some miners may protest and lobby exchanges.
> - By pushing mining towards the cheapest energy sources, centralization
> increases towards Chinese miners.
> - The Bitcoin network may split if consensus is not built before flag day.
>
> However, given the current political headwinds and widespread public
> discussion around Bitcoin's energy use, it may be socially possible to
> ask individual users and major exchanges to install a version of Bitcoin
> with a reduced block reward.
>
> Alternatives
> ===
> Instead of outright rejecting transactions (and the blocks that contain
> them) that attempt to spend increased block rewards, treat them as no-ops.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6154 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 1:00 [bitcoin-dev] Reducing block reward via soft fork James Lu
2021-05-23 10:42 ` Anton Ragin
@ 2021-05-23 11:26 ` ZmnSCPxj
2021-05-23 12:08 ` Karl
2021-05-24 22:03 ` Phuoc Do
2 siblings, 1 reply; 15+ messages in thread
From: ZmnSCPxj @ 2021-05-23 11:26 UTC (permalink / raw)
To: James Lu, Bitcoin Protocol Discussion
Good morning James,
> Background
> ===
> Reducing the block reward reduces the incentive to mine. It reduces the maximum energy price at which mining is profitable, reducing the energy use.
>
If people want to retain previous levels of security, they can offer to pay higher fees, which increases the miner reward and thereby increasing the energy use again.
The only difference is that the security is paid for directly by transactors rather than slowly extracted from HODLers.
Thus, I expect that the energy use of Bitcoin will fairly closely match its security usage, even with this change.
Really, though:
* The issue is not energy use.
* The issue is the energy *efficiency*.
Everything important requires energy.
What is needed is to get the most amount of work for the least amount of entropy-increase.
Deleterious environmental effects (pollution, temperature rise, and so on) are symptoms of entropy-increase in the local universe.
These have long-term negative effects from the simple fact that we are producing entropy and dumping it into our surroundings.
If these effects are properly charged to their instigators (e.g. carbon emissions fines), then the negative environmental effects will become economic disincentives, that miners will now naturally avoid in order to increase their profitability.
This holds no matter how much block rewards are, and how much comes from the block subsidy or from mining fees.
The trope that the "free market" is somehow opposed to "environmentalism" is about as accurate to real life as Hollywood hacking "I can crack AES-256 in exactly 30 minutes".
Properly account for the entropy increase (energy usage) of all kinds of pollution, and the free market will naturally seek sustainable and renewable processes --- because that maximizes profitability in the long run.
Anyone who pushes for environmentalism but refuses to use Bitcoin should be treated with suspicion of either hypocrisy or massive ignorance --- Bitcoin is the most honest currency in accounting for its energy usage and consumption, and I suspect most other currencies have far worse efficiencies, that happen to be hidden because they are not properly accounted for.
What is needed is to enforce that pollution be paid for by those who cause it --- this can require significant political influence to do (a major world government is a major polluter, willing to pay for high fuel costs just to ship their soldiers globally, polluting the environments of foreign countries), and should be what true environmentalists would work towards, not rejecting Bitcoin as an environmental disaster (which is frankly laughable).
Remember, the free market only works correctly if all its costs are accounted correctly --- otherwise it will treat costs subsidized by the community of human beings as a resource to pump.
> Alternatives
> ===
> Instead of outright rejecting transactions (and the blocks that contain them) that attempt to spend increased block rewards, treat them as no-ops.
That is inefficient --- the "no-op" transactions reduce the available block space for operational transactions, thus this alternative is strictly inferior to a simple acceleration of block subsidy reduction.
Regards,
ZmnSCPXj
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 11:26 ` [bitcoin-dev] " ZmnSCPxj
@ 2021-05-23 12:08 ` Karl
2021-05-23 13:35 ` ZmnSCPxj
0 siblings, 1 reply; 15+ messages in thread
From: Karl @ 2021-05-23 12:08 UTC (permalink / raw)
To: ZmnSCPxj, Anton Ragin, Bitcoin Protocol Discussion
On 5/23/21, ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Good morning James,
>
>> Background
>> ===
>> Reducing the block reward reduces the incentive to mine. It reduces the
>> maximum energy price at which mining is profitable, reducing the energy
>> use.
>>
>
> If people want to retain previous levels of security, they can offer to pay
> higher fees, which increases the miner reward and thereby increasing the
> energy use again.
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.
> Properly account for the entropy increase (energy usage) of all kinds of
> pollution, and the free market will naturally seek sustainable and renewable
> processes --- because that maximizes profitability in the long run.
There is little economic incentive to fine carbon emissions because
there is no well-established quick path to gain profit from reducing
them. The feedback paths you describe take decades if not hundreds of
years.
But it sounds like you are saying you would rather the energy issue
stay a political one that does not involve bitcoin. Your point is
quite relevant because bitcoin is not the largest consumer of energy;
those who care about reducing energy use would be better put to look
at other concerns.
The reason to reduce _bitcoin's_ energy use, would simply be to aid
its popularity and quell public concern. Without doing this, people
move to an altcoin, because increasing the value of bitcoin via
spreading its use, increases the demand for mining. That human
decision is part of the honesty you describe.
> What is needed is to enforce that pollution be paid for by those who cause
> it --- this can require significant political influence to do (a major world
> government is a major polluter, willing to pay for high fuel costs just to
> ship their soldiers globally, polluting the environments of foreign
> countries), and should be what true environmentalists would work towards,
> not rejecting Bitcoin as an environmental disaster (which is frankly
> laughable).
>
> Remember, the free market only works correctly if all its costs are
> accounted correctly --- otherwise it will treat costs subsidized by the
> community of human beings as a resource to pump.
It sounds like you would prefer a proof-of-work function that directly
proved carbon offsetting? And an on-chain tax for environmental harm?
On 5/23/21, Anton Ragin via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Well, it is done automatically every 4 years :) It is a self-balancing
> system - more people shout about Bitcoin being dirty -> less adoption ->
> lower the price -> less energy consumption. Add on top the fact that in
> 2024 block rewards will fall 50% anyway and someday it will be zero.
Is hashrate rising slower than the block reward is dropping, that you
mention the 4 years halving? Do you see a problem with dropping the
block reward to make faster change to the hashrate curve, that you
mention the existing system's weaker approach?
I personally wasn't aware that Elon had complained; I've been hearing
the complaint from scads of people for many years.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 12:08 ` Karl
@ 2021-05-23 13:35 ` ZmnSCPxj
2021-05-23 19:44 ` Karl
0 siblings, 1 reply; 15+ messages in thread
From: ZmnSCPxj @ 2021-05-23 13:35 UTC (permalink / raw)
To: Karl; +Cc: Bitcoin Protocol Discussion
Good morning Karl,
> On 5/23/21, ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists•linuxfoundation.org wrote:
>
> > Good morning James,
> >
> > > Background
> > >
> > > ===========
> > >
> > > Reducing the block reward reduces the incentive to mine. It reduces the
> > > maximum energy price at which mining is profitable, reducing the energy
> > > use.
> >
> > If people want to retain previous levels of security, they can offer to pay
> > higher fees, which increases the miner reward and thereby increasing the
> > energy use again.
>
> 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.
> > Properly account for the entropy increase (energy usage) of all kinds of
> > pollution, and the free market will naturally seek sustainable and renewable
> > processes --- because that maximizes profitability in the long run.
>
> There is little economic incentive to fine carbon emissions because
> there is no well-established quick path to gain profit from reducing
> them. The feedback paths you describe take decades if not hundreds of
> years.
>
> But it sounds like you are saying you would rather the energy issue
> stay a political one that does not involve bitcoin. Your point is
> quite relevant because bitcoin is not the largest consumer of energy;
> those who care about reducing energy use would be better put to look
> at other concerns.
Precisely.
> > What is needed is to enforce that pollution be paid for by those who cause
> > it --- this can require significant political influence to do (a major world
> > government is a major polluter, willing to pay for high fuel costs just to
> > ship their soldiers globally, polluting the environments of foreign
> > countries), and should be what true environmentalists would work towards,
> > not rejecting Bitcoin as an environmental disaster (which is frankly
> > laughable).
> > Remember, the free market only works correctly if all its costs are
> > accounted correctly --- otherwise it will treat costs subsidized by the
> > community of human beings as a resource to pump.
>
> It sounds like you would prefer a proof-of-work function that directly
> proved carbon offsetting? And an on-chain tax for environmental harm?
The problem is that the only proof of efficiency here is implicit: any inefficiency will eventually be rooted out of the network, as any inefficiency will translate to reduced profitability.
However, at short-term, a miner can pollute its locality, and then exit the business and leave its crap lying around for others to deal with and abscond with pure profit.
This translates to a theft in the profitability of others in the locality.
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.
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.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 15+ messages in thread
* [bitcoin-dev] Fwd: Reducing block reward via soft fork
[not found] ` <CANQHGB2pD57cZzcuTqr25Pg-Bvon_=G=_5901to2esrcumk-GA@mail.gmail.com>
@ 2021-05-23 14:40 ` James Lu
0 siblings, 0 replies; 15+ messages in thread
From: James Lu @ 2021-05-23 14:40 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]
> Well, it is done automatically every 4 years :)
Bitcoin's price has always been increasing exponentially faster than the
block size has been exponentially decreasing.
> It is a self-balancing system - more people shout about Bitcoin being
dirty -> less adoption -> lower the price -> less energy consumption.
Surely we can strive for adoption and be environmentally friendly?
Bitcoin currently consumes as much power as a small nation-state, giving it
nation-state security. A 51% attack can reverse recent transactions. I
don't think 99% of transactions need that level of security– and if we
don't improve environmental-friendliness, adoption will decrease, so the
price will decrease, so less mining will happen, so security will be hurt
anyway.
> I am all for making Bitcoin green(er), but IMHO there shall be no
short-termism of the sort "Elon complained + price dropped 40% - lets go
radically change things".
I agree, Bitcoin shouldn't do anything just because a celebrity said
something. However, this would be the ideal time to make such a change,
riding off the public attitude to build social consensus around such a
change.
Also, this reduces inflation, good for Bitcoin hodlers ;)
> IMHO if we want to make BTC cleaner we can add functionality where users
can prioritise some miners over the others, with the view that users will
prioritise "green" miners and they will get more TX fees, and there will be
economic incentive to go green.
This proposal would be great too.
On Sun, May 23, 2021 at 6:42 AM Anton Ragin <anton@etc-group•com> wrote:
> Well, it is done automatically every 4 years :) It is a self-balancing
> system - more people shout about Bitcoin being dirty -> less adoption ->
> lower the price -> less energy consumption. Add on top the fact that in
> 2024 block rewards will fall 50% anyway and someday it will be zero.
>
> I am all for making Bitcoin green(er), but IMHO there shall be no
> short-termism of the sort "Elon complained + price dropped 40% - lets go
> radically change things".
>
> IMHO if we want to make BTC cleaner we can add functionality where users
> can prioritise some miners over the others, with the view that users will
> prioritise "green" miners and they will get more TX fees, and there will be
> economic incentive to go green.
>
> On Sun, 23 May 2021, 09:49 James Lu via bitcoin-dev, <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Background
>> ===
>> Reducing the block reward reduces the incentive to mine. It reduces the
>> maximum energy price at which mining is profitable, reducing the energy use.
>>
>> Bitcoins have value because they are accepted by full node users, from
>> individual node operators, to exchanges and custodians like Coinbase.
>> Anything else and the Bitcoins don't exist and are worthless. Like all
>> currencies, Bitcoin has value because others recognize that they have value.
>>
>> Idea
>> ===
>> Reduce the block reward by adding fewer coins to the UTXO set per block.
>> This should be done gradually
>>
>> Consensus layer
>> ===
>> This is a soft fork, because it tightens the
>>
>> Some Possible Weaknesses
>> ===
>> - It will cost less than a nation-state of energy to reverse recent
>> Bitcoin transactions.
>> - Some miners may protest and lobby exchanges.
>> - By pushing mining towards the cheapest energy sources, centralization
>> increases towards Chinese miners.
>> - The Bitcoin network may split if consensus is not built before flag day.
>>
>> However, given the current political headwinds and widespread public
>> discussion around Bitcoin's energy use, it may be socially possible to
>> ask individual users and major exchanges to install a version of Bitcoin
>> with a reduced block reward.
>>
>> Alternatives
>> ===
>> Instead of outright rejecting transactions (and the blocks that contain
>> them) that attempt to spend increased block rewards, treat them as no-ops.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 9981 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 13:35 ` ZmnSCPxj
@ 2021-05-23 19:44 ` Karl
2021-05-24 20:28 ` Billy Tetrud
0 siblings, 1 reply; 15+ messages in thread
From: Karl @ 2021-05-23 19:44 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
>> 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 19:44 ` Karl
@ 2021-05-24 20:28 ` Billy Tetrud
2021-05-24 21:55 ` Erik Aronesty
` (3 more replies)
0 siblings, 4 replies; 15+ messages in thread
From: Billy Tetrud @ 2021-05-24 20:28 UTC (permalink / raw)
To: Karl, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-24 20:28 ` Billy Tetrud
@ 2021-05-24 21:55 ` Erik Aronesty
2021-05-25 0:55 ` Karl
` (2 subsequent siblings)
3 siblings, 0 replies; 15+ messages in thread
From: Erik Aronesty @ 2021-05-24 21:55 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
> > 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.
yes, and this is what lightning is for. to secure the 99% of
transactions that *don't* need billions of dollars and years in lead
time of security.
at current prices, and even with the current known issues, lightning
is perfectly acceptable for small transactions.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-23 1:00 [bitcoin-dev] Reducing block reward via soft fork James Lu
2021-05-23 10:42 ` Anton Ragin
2021-05-23 11:26 ` [bitcoin-dev] " ZmnSCPxj
@ 2021-05-24 22:03 ` Phuoc Do
2 siblings, 0 replies; 15+ messages in thread
From: Phuoc Do @ 2021-05-24 22:03 UTC (permalink / raw)
To: James Lu, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]
I think security and inflation are intertwined aspects of a monetary system
[1]. They are both necessary. Many Bitcoin articles discussed energy and
security. More energy translates to more security. The other dimension is
inflation. Bitcoin block reward is constant and reduced every 4 years. But
its price has increased exponentially. The price rise compensates for
reduced inflation.
I don't think a fee market is enough to sustain the system. 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. The Fed has an inflation target of 2% per year. This is
conventional wisdom. The USD M2 money base historically grows at 7% per
year [2]. We didn't know why inflation is necessary. I think Bitcoin shows
us that inflation and security are related. Inflation ensures there'll be
security.
Without inflation, the system will collapse. Cutting block rewards will
reduce energy spend. But it likely will destroy the system. Instead, we
need to ask:
1. How much energy we should spend on mining?
2. How we can use renewable energy?
[1] https://bitflate.org/post/2021/05/21/inflation-and-security.html
[2] https://ycharts.com/indicators/us_m2_money_supply_yoy
On Sun, May 23, 2021 at 1:49 AM James Lu via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Background
> ===
> Reducing the block reward reduces the incentive to mine. It reduces the
> maximum energy price at which mining is profitable, reducing the energy use.
>
> Bitcoins have value because they are accepted by full node users, from
> individual node operators, to exchanges and custodians like Coinbase.
> Anything else and the Bitcoins don't exist and are worthless. Like all
> currencies, Bitcoin has value because others recognize that they have value.
>
> Idea
> ===
> Reduce the block reward by adding fewer coins to the UTXO set per block.
> This should be done gradually
>
> Consensus layer
> ===
> This is a soft fork, because it tightens the
>
> Some Possible Weaknesses
> ===
> - It will cost less than a nation-state of energy to reverse recent
> Bitcoin transactions.
> - Some miners may protest and lobby exchanges.
> - By pushing mining towards the cheapest energy sources, centralization
> increases towards Chinese miners.
> - The Bitcoin network may split if consensus is not built before flag day.
>
> However, given the current political headwinds and widespread public
> discussion around Bitcoin's energy use, it may be socially possible to
> ask individual users and major exchanges to install a version of Bitcoin
> with a reduced block reward.
>
> Alternatives
> ===
> Instead of outright rejecting transactions (and the blocks that contain
> them) that attempt to spend increased block rewards, treat them as no-ops.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Phuoc Do
[-- Attachment #2: Type: text/html, Size: 7075 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-24 20:28 ` Billy Tetrud
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
3 siblings, 1 reply; 15+ messages in thread
From: Karl @ 2021-05-25 0:55 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
If bitcoin were to ever consider changing their PoW algorithm a
little, it seems that would immediately make purchased ASIC mining
equipment partially or wholly unusable to compromise the chain (and
temporarily reduce energy usage without necessarily reducing
security). One possible plan to deter a multibillionaire attack.
Also regarding the word "security" here, a 51% attack impacts some
parts of chain operations, but not others.
It seems to me bitcoin's biggest vulnerabilities are either covert
compromise of mining pool operations, or widespread compromise of
networked mining systems and client nodes. Far easier than
outcompeting the mining network with hardware.
I don't see why it would necessarily be made public if a government
compromised their nation's mining farms. Governments have skilled
operatives for things like that. People would guess it happened, and
the government would cover up the guesses with more powerful stories.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-25 0:55 ` Karl
@ 2021-05-25 8:01 ` Billy Tetrud
0 siblings, 0 replies; 15+ messages in thread
From: Billy Tetrud @ 2021-05-25 8:01 UTC (permalink / raw)
To: Karl; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
> It seems to me bitcoin's biggest vulnerabilities are either covert
compromise of mining pool operations, or widespread compromise of networked
mining systems and client node
Stratum v2 will solve the mining pool problem. Widespread compromise of
mining systems seems far fetched. That would involve compromising hundreds
of thousands or perhaps millions of systems in disparate areas with
disparate operating systems and security procedures, run by people who
probably understand computer security better than most (given their
involvement in bitcoin).
I think the biggest vulnerability bitcoin has is a sybil attack draining
the resources of public full nodes. We only have like 10,000 public full
nodes serving the whole network. It wouldn't take that much money to create
a sybil botnet of 100,000 or 1 million nodes that connect to the bitcoin
network and simply take up public node resources, denying service to most
people's full nodes.
> I don't see why it would necessarily be made public if a government
compromised their nation's mining farms. Governments have skilled
operatives for things like that.
Skilled operatives have their limits. It could be kept secret if spies were
hired as employees and then systematically infected all the machines in a
mining operation's machines. But spies aren't magic, no matter how skilled.
One mistake and the jig is up. It would be more likely to be a backroom
deal, which would be harder to keep secret, especially in large operations.
Propaganda has its limits too, sure you could convince some people things
are fine, but sophisticated people like miners? I doubt it.
On Mon, May 24, 2021 at 2:55 PM Karl <gmkarl@gmail•com> wrote:
> If bitcoin were to ever consider changing their PoW algorithm a
> little, it seems that would immediately make purchased ASIC mining
> equipment partially or wholly unusable to compromise the chain (and
> temporarily reduce energy usage without necessarily reducing
> security). One possible plan to deter a multibillionaire attack.
>
> Also regarding the word "security" here, a 51% attack impacts some
> parts of chain operations, but not others.
>
> It seems to me bitcoin's biggest vulnerabilities are either covert
> compromise of mining pool operations, or widespread compromise of
> networked mining systems and client nodes. Far easier than
> outcompeting the mining network with hardware.
>
> I don't see why it would necessarily be made public if a government
> compromised their nation's mining farms. Governments have skilled
> operatives for things like that. People would guess it happened, and
> the government would cover up the guesses with more powerful stories.
>
[-- Attachment #2: Type: text/html, Size: 3244 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-24 20:28 ` Billy Tetrud
2021-05-24 21:55 ` Erik Aronesty
2021-05-25 0:55 ` Karl
@ 2021-05-25 8:35 ` Jorge Timón
2021-05-25 8:53 ` Melvin Carvalho
3 siblings, 0 replies; 15+ messages in thread
From: Jorge Timón @ 2021-05-25 8:35 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 12966 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 15107 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-24 20:28 ` Billy Tetrud
` (2 preceding siblings ...)
2021-05-25 8:35 ` Jorge Timón
@ 2021-05-25 8:53 ` Melvin Carvalho
2021-05-25 19:40 ` Billy Tetrud
3 siblings, 1 reply; 15+ messages in thread
From: Melvin Carvalho @ 2021-05-25 8:53 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 12834 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 14764 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Reducing block reward via soft fork
2021-05-25 8:53 ` Melvin Carvalho
@ 2021-05-25 19:40 ` Billy Tetrud
0 siblings, 0 replies; 15+ messages in thread
From: Billy Tetrud @ 2021-05-25 19:40 UTC (permalink / raw)
To: Melvin Carvalho; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 17002 bytes --]
@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
>>
>
[-- Attachment #2: Type: text/html, Size: 19279 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-05-25 19:41 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-23 1:00 [bitcoin-dev] Reducing block reward via soft fork 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox