public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: James Lu <jamtlu@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Fwd:  Reducing block reward via soft fork
Date: Sun, 23 May 2021 10:40:31 -0400	[thread overview]
Message-ID: <CANQHGB1TWKfpNe2f6CsFKooRtbUeRbRSePGgd+w7COT55U3KZQ@mail.gmail.com> (raw)
In-Reply-To: <CANQHGB2pD57cZzcuTqr25Pg-Bvon_=G=_5901to2esrcumk-GA@mail.gmail.com>

[-- 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 --]

  parent reply	other threads:[~2021-05-23 14:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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     ` James Lu [this message]
2021-05-23 11:26 ` 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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=CANQHGB1TWKfpNe2f6CsFKooRtbUeRbRSePGgd+w7COT55U3KZQ@mail.gmail.com \
    --to=jamtlu@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox