From: Andrew Cann <shum@canndrew•org>
To: Dave Scotese <dscotese@litmocracy•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
Date: Mon, 23 Mar 2020 08:59:22 -0400 [thread overview]
Message-ID: <20200323125922.GA29881@canndrew.org> (raw)
In-Reply-To: <CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
Hi, noob question here: Is there a long-term plan for if the block reward drops
too low to ensure the security of the network?
IIUC miners only make profit from block rewards and transaction fees, and once
the block reward drop to zero we're merely hoping that transaction fees will
keep mining expensive enough to stop a state actor or someone from buying
enough hash power to attack the network. If that's the case, should we start
making plans now to change the protocol to allow an adjustable block reward?
Here's a half-baked idea I had of how that could work: Since the block reward
dilutes the value of the currency bitcoin holders have an incentive to keep the
reward low. However, since the block reward is also (partly) what incentivizes
mining, bitcoin holders also have an incentive to keep the reward high enough
to keep the network secure. So if bitcoin holders were able to vote to decide
the block reward they "should", hypothetically, reliably choose a value that
balances these two concerns. You could implement this voting by adding an
optional extra field to every txout that signals what the holder thinks the
inflation rate should be. If the field is missing you just assume the default
value based on the current protocol. Then, whenever a new block is mined, you
take the median inflation rate of all the pre-existing utxos, weighted by the
utxo value, to calculate the block's reward.
Is this idea fundamentally broken somehow? Or are there already better ideas
for how to tackle this problem (I don't follow this list very closely)? Or is
this actually a non-issue to start with?
- Andrew
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2020-03-23 13:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-21 18:40 Dave Scotese
2020-03-22 7:54 ` David A. Harding
2020-03-22 11:58 ` LORD HIS EXCELLENCY JAMES HRMH
2020-03-22 16:54 ` Eric Voskuil
2020-03-22 18:17 ` Dave Scotese
2020-03-23 12:59 ` Andrew Cann [this message]
2020-03-23 18:39 ` Dave Scotese
2020-03-24 7:42 ` ZmnSCPxj
2020-03-25 15:23 ` Andrew Cann
2020-03-26 1:42 ` ZmnSCPxj
2020-03-27 9:17 ` Andrew Cann
2020-03-28 2:12 ` ZmnSCPxj
2020-03-29 8:11 ` [bitcoin-dev] Block solving slowdown Andrew Cann
2020-03-30 2:59 ` ZmnSCPxj
2020-03-31 2:06 ` ZmnSCPxj
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=20200323125922.GA29881@canndrew.org \
--to=shum@canndrew$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dscotese@litmocracy$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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