From: Andrew Cann <shum@canndrew•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
Date: Wed, 25 Mar 2020 11:23:02 -0400 [thread overview]
Message-ID: <20200325152302.GA3355@canndrew.org> (raw)
In-Reply-To: <C_qo1AhQuklVr4owEXVgLXsvJomb9Usd1NP2zf_D_23r6Cmz9-iB7ygSfNihJp3FIfAf4c1P41fT3qQP7SFiKdCfXxpogcstHsOnpgLgbok=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
Hi, thanks for the replies.
> Anyway, yes, your idea is fundamentally broken because a zero block reward
> happens because creating even one more satoshi will push the amount of
> bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you
> like, creating a fundamental contradiction in our use of the term.
I wouldn't really consider that fundamentally broken. It changes the meaning of
"bitcoin", but so does every upgrade to the protocol. The worst problem I can
see with this is that there's probably a lot of software out there which
assumes a cap of 21M. But we'd have years to find and fix those bugs.
> They already do so, via an implicit "field", known as the transaction fee.
> 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 isn't the same thing though, economically / game-theoretically speaking.
Transaction fees are only paid when bitcoins get moved. There's no on-going
cost for people holding bitcoins (assuming they're doing their day-to-day
transactions almost entirely off-chain, which is something that's only going to
become more common). More to the point, the transaction fee is only set by the
current demand for block space. If transaction fees drop too low to maintain a
secure hash rate then people *could* willingly pay more than they need to to
get their transactions mined, but it's unlikely they will since it'd be cheaper
to just pay the minimum and hope that everyone else covers the costs of keeping
the network secure for them.
With the voting idea everyone decides what everyone pays (via dilution) to keep
the network secure. Choosing to signal a high inflation rate doesn't mean you
pay more than everyone else, just that you might shift the median, so there's
no tragedy-of-the-commons problem. Also, votes are weighted by the value of
the utxo, so people both vote and pay in proportion to the amount of bitcoin
they're holding.
Does this make sense? Or is there some game-theoretic reason I'm not seeing for
why transaction fees can never drop dangerously low in the first place?
- Andrew
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2020-03-25 15:24 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
2020-03-25 15:23 ` Andrew Cann [this message]
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=20200325152302.GA3355@canndrew.org \
--to=shum@canndrew$(echo .)org \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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