public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Karl <gmkarl@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reducing block reward via soft fork
Date: Sun, 23 May 2021 15:44:18 -0400	[thread overview]
Message-ID: <CALL-=e6deZdsA+LLWBXJwYDf9x2x4sRxC1s=8fb2wH1paXpMBA@mail.gmail.com> (raw)
In-Reply-To: <G3RgofdarOhSiEJjyDNaN2Dv27WCpb_0CSOpya6acUnPbpPQ-oygklpP_e0rLdxglK5FCo5dq7Qkv6GinA3qCXiOM6GzEcNvcxxM7kbwFhY=@protonmail.com>

>> 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.


  reply	other threads:[~2021-05-23 19:44 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     ` [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 [this message]
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='CALL-=e6deZdsA+LLWBXJwYDf9x2x4sRxC1s=8fb2wH1paXpMBA@mail.gmail.com' \
    --to=gmkarl@gmail.com \
    --cc=ZmnSCPxj@protonmail.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