From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Andrew Cann <shum@canndrew•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
Date: Thu, 26 Mar 2020 01:42:22 +0000 [thread overview]
Message-ID: <v1t2DhGSHFng23jy0XTRkoVJrhA_6x_QuHFWdrcxQnMS8Sdcbe7eksRtvjf6JCb8YLoHf2W5y29j3XbBIVfDALSBjoiMqxPUWKsQyGLOR_A=@protonmail.com> (raw)
In-Reply-To: <20200325152302.GA3355@canndrew.org>
Good morning Andrew,
>
> > 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.
There are changes of meaning, and then there are changes of meaning.
Smaller changes that puny humans can understand are better than larger changes beyond the ken of mortal man.
To change the supply is far too big a change.
> > 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?
What happens if I own a few million Bitcoin and then accidentally lose my private keys in a tragic ear-cleaning accident?
Then the vote of that UTXO containing a few million Bitcoins will remain forever fixed and unable to change according to whatever you believe would make us as a community decide to change the inflation rate.
If you enforce that only "recently-created" UTXOs get to vote, then in order for me to affect the vote (in the happy case where I do **not** lose all my privkeys in a tragic ear-cleaning accident), I would have to make a synthetic self-paying transaction.
How is it so different from me having to make up a synthetic transaction in order to pay fees and thus affect the current security of the blockchain?
--
It is helpful to remember that as a UTXO gets buried deeper, its security is inevitably better, and once I have a sufficient level of security in my ownership of the coin, I will not particularly care about any improved security and will not be interested in paying for more, hence why should I support any fork which makes me pay for my security continuously when I can simply support a fork that retains the current supply and does *not* make me pay for continued security?
--
If I want to *spend* my Bitcoins on something --- and nothing has value until I actually utilize it --- then I *will* pay transaction fees.
The receiver of the coin would want to ensure that the received UTXO is deeply buried to the point that it has sufficient security for the receiver, before releasing or providing me with whatever I am exchanging the coin for.
Thus, if I find that there are no miners at all, I could offer a high fee to get my transaction mined.
Of course, you might say that this only pays for one block.
But in most cases I will have more value remaining beyond what I spend to the receiver, i.e. I have a change output from that transaction.
In such a case, I can pay for more blocks by re-spending the change output to myself, paying a transaction fee each time, until the original transaction that spends to the receiver is deeply buried and the receiver credits it and then releases the product or service I am exchanging *for*.
Alternately the receiver can do the same for its *own* UTXO, and will increase the payment it demands from me in order to perform this itself; thus I still end up paying for the security of the *transaction* and not the security of the *holding*.
So there is really no need for any mechanism beyond transaction fees.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-03-26 1:42 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
2020-03-26 1:42 ` ZmnSCPxj [this message]
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='v1t2DhGSHFng23jy0XTRkoVJrhA_6x_QuHFWdrcxQnMS8Sdcbe7eksRtvjf6JCb8YLoHf2W5y29j3XbBIVfDALSBjoiMqxPUWKsQyGLOR_A=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=shum@canndrew$(echo .)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