From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Thomas Voegtlin <thomasv@electrum•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
Date: Thu, 14 May 2015 02:44:01 +0200 [thread overview]
Message-ID: <CAKaEYhJVH5g-M98tbpAQvTHi-OiGh91v22GZ+tixqXa7cntiKA@mail.gmail.com> (raw)
In-Reply-To: <5550D8BE.6070207@electrum.org>
[-- Attachment #1: Type: text/plain, Size: 5363 bytes --]
On 11 May 2015 at 18:28, Thomas Voegtlin <thomasv@electrum•org> wrote:
> The discussion on block size increase has brought some attention to the
> other elephant in the room: Long-term mining incentives.
>
> Bitcoin derives its current market value from the assumption that a
> stable, steady-state regime will be reached in the future, where miners
> have an incentive to keep mining to protect the network. Such a steady
> state regime does not exist today, because miners get most of their
> reward from the block subsidy, which will progressively be removed.
>
> Thus, today's 3 billion USD question is the following: Will a steady
> state regime be reached in the future? Can such a regime exist? What are
> the necessary conditions for its existence?
>
> Satoshi's paper suggests that this may be achieved through miner fees.
> Quite a few people seem to take this for granted, and are working to
> make it happen (developing cpfp and replace-by-fee). This explains part
> of the opposition to raising the block size limit; some people would
> like to see some fee pressure building up first, in order to get closer
> to a regime where miners are incentivised by transaction fees instead of
> block subsidy. Indeed, the emergence of a working fee market would be
> extremely reassuring for the long-term viability of bitcoin. So, the
> thinking goes, by raising the block size limit, we would be postponing a
> crucial reality check. We would be buying time, at the expenses of
> Bitcoin's decentralization.
>
> OTOH, proponents of a block size increase have a very good point: if the
> block size is not raised soon, Bitcoin is going to enter a new, unknown
> and potentially harmful regime. In the current regime, almost all
> transaction get confirmed quickly, and fee pressure does not exist. Mike
> Hearn suggested that, when blocks reach full capacity and users start to
> experience confirmation delays and confirmation uncertainty, users will
> simply go away and stop using Bitcoin. To me, that outcome sounds very
> plausible indeed. Thus, proponents of the block size increase are
> conservative; they are trying to preserve the current regime, which is
> known to work, instead of letting the network enter uncharted territory.
>
> My problem is that this seems to lacks a vision. If the maximal block
> size is increased only to buy time, or because some people think that 7
> tps is not enough to compete with VISA, then I guess it would be
> healthier to try and develop off-chain infrastructure first, such as the
> Lightning network.
>
> OTOH, I also fail to see evidence that a limited block capacity will
> lead to a functional fee market, able to sustain a steady state. A
> functional market requires well-informed participants who make rational
> choices and accept the outcomes of their choices. That is not the case
> today, and to believe that it will magically happen because blocks start
> to reach full capacity sounds a lot like like wishful thinking.
>
> So here is my question, to both proponents and opponents of a block size
> increase: What steady-state regime do you envision for Bitcoin, and what
> is is your plan to get there? More specifically, how will the
> steady-state regime look like? Will users experience fee pressure and
> delays, or will it look more like a scaled up version of what we enjoy
> today? Should fee pressure be increased jointly with subsidy decrease,
> or as soon as possible, or never? What incentives will exist for miners
> once the subsidy is gone? Will miners have an incentive to permanently
> fork off the last block and capture its fees? Do you expect Bitcoin to
> work because miners are altruistic/selfish/honest/caring?
>
> A clear vision would be welcome.
>
I am guided here by Satoshi's paper:
"Commerce on the Internet has come to rely almost exclusively on financial
institutions serving as trusted third parties to process electronic
payments. While the system works well enough for *most transactions*"
This suggests to me that most tx will occur off-block with the block chain
used for settlement. Indeed Satoshi was working on a trust based market
before he left.
If commerce works well enough off-block with zero trust settlement
supporting it, people might even forget that the block chain exists, like
with gold settlement. But it can be used for transactions. To this end I
welcome higher fees, so that the block chain becomes the reserve currency
of the internet and is used sparingly.
But as Gavin pointed out, bitcoin is still an experiment and we are all
still learning. We are also learning from alt coin mechanisms. I am
unsure there is huge urgency here, and would lean towards caution as
bitcoin infrastructure rapidly grows.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 6425 bytes --]
next prev parent reply other threads:[~2015-05-14 0:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 16:28 Thomas Voegtlin
2015-05-11 16:52 ` insecurity
2015-05-11 17:29 ` Gavin Andresen
2015-05-12 12:35 ` Thomas Voegtlin
[not found] ` <CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
[not found] ` <555210AF.3090705@electrum.org>
2015-05-12 16:10 ` Gavin Andresen
2015-05-12 16:21 ` Dave Hudson
2015-05-12 21:24 ` Pedro Worcel
2015-05-12 23:48 ` Adam Back
2015-05-13 15:41 ` Gavin Andresen
2015-05-13 20:05 ` Pedro Worcel
2015-05-13 9:49 ` Thomas Voegtlin
2015-05-13 10:14 ` Tier Nolan
2015-05-13 10:31 ` Alex Mizrahi
2015-05-13 11:29 ` Tier Nolan
2015-05-13 12:26 ` Alex Mizrahi
2015-05-13 13:24 ` Gavin
2015-05-13 13:28 ` Tier Nolan
2015-05-13 14:26 ` Alex Mizrahi
2015-05-13 23:46 ` Jorge Timón
2015-05-14 0:11 ` Jorge Timón
2015-05-14 0:48 ` Aaron Voisine
2015-05-14 0:58 ` Pieter Wuille
2015-05-14 1:13 ` Aaron Voisine
2015-05-14 1:19 ` Pieter Wuille
2015-05-14 1:31 ` Aaron Voisine
2015-05-14 2:34 ` Aaron Voisine
2015-05-16 20:35 ` Owen Gunden
2015-05-16 22:18 ` Tom Harding
2015-05-17 1:08 ` Aaron Voisine
2015-05-14 0:44 ` Melvin Carvalho [this message]
2015-05-25 18:31 ` Mike Hearn
2015-05-26 18:47 ` Thomas Voegtlin
2015-05-27 21:59 ` Mike Hearn
2015-05-27 22:22 ` Gregory Maxwell
2015-05-28 10:30 ` Mike Hearn
2015-05-13 17:49 Damian Gomez
2015-05-18 2:29 Michael Jensen
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=CAKaEYhJVH5g-M98tbpAQvTHi-OiGh91v22GZ+tixqXa7cntiKA@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=thomasv@electrum$(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