From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Dave Scotese <dscotese@litmocracy•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
Date: Tue, 24 Mar 2020 07:42:46 +0000 [thread overview]
Message-ID: <C_qo1AhQuklVr4owEXVgLXsvJomb9Usd1NP2zf_D_23r6Cmz9-iB7ygSfNihJp3FIfAf4c1P41fT3qQP7SFiKdCfXxpogcstHsOnpgLgbok=@protonmail.com> (raw)
In-Reply-To: <CAGLBAhcUgTEWnraFem0YwODc61B4nwbzddHJtE0D7ZCjUNWfYg@mail.gmail.com>
Good morning Andrew,
> > 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.
They already do so, via an implicit "field", known as the transaction fee.
This is "implicit" since it is only the difference of the sum of all inputs with the sum of all outputs, but any Bitcoin HODLer spending their coins always need to make this decision.
This makes the vote for how much security is needed to be costly to the voter, which is appropriate: you pay for your security.
This mechanism is the same mechanism as well that is the long-term plan for the lowered block rewards in the future, and is already the best known idea to tackle this problem as well.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-03-24 7:43 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
2020-03-23 18:39 ` Dave Scotese
2020-03-24 7:42 ` ZmnSCPxj [this message]
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='C_qo1AhQuklVr4owEXVgLXsvJomb9Usd1NP2zf_D_23r6Cmz9-iB7ygSfNihJp3FIfAf4c1P41fT3qQP7SFiKdCfXxpogcstHsOnpgLgbok=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--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