From: "Jorge Timón" <jtimon@jtimon•cc>
To: Tom Harding <tomh@thinlink•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader
Date: Thu, 30 Jul 2015 20:14:47 +0200 [thread overview]
Message-ID: <CABm2gDoh69a0335uLhwVndwwLiYtZEVdCvNsrCtHiRAVrSqkaQ@mail.gmail.com> (raw)
In-Reply-To: <55BA2329.1080700@thinlink.com>
On Thu, Jul 30, 2015 at 3:14 PM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 7/29/2015 9:48 PM, Ryan Butler via bitcoin-dev wrote:
> ... more evidence that conclusively refutes the conjecture that a
> production quota is necessary for a "functioning fee market." A
> production quota merely pushes up fees. We have a functioning market,
> and so far, it shows that wider bitcoin usage is even more effective
> than a quota at pushing up fees.
The blocksize limit (your "production quota") is necessary for
decentralization, not for having a functioning fee market.
But I have the hope that hitting the limit would help with getting rid
of all that special-case or at least would encourage miners to
implement their own policies.
If we can agree that hitting the limit will JUST cause higher fees and
not bitcoin to fail, puppies to die or the sky to turn purple I think
that's a great step forward in this debate.
From that perspective, hitting the limit is not something terribly bad
(as said, I think it can even have positive consequences; for example,
higher fees may be just what is needed for more scalable solutions
[like payment channels] to be adopted by bitcoin companies). Hitting
the limit may produce a more healthy market, but it is true that a
market for fast confirmations already exists.
Unless we want to completely get rid of the blocksize limit (which I
would consider another debate entirely), we will eventually hit the
limit anyway. Why not now so that we can make sure the software is
completely compatible with having a limit?
Why we can hit the limit eventually but not now?
(As said, unless you think the limit should be completely removed forever).
next prev parent reply other threads:[~2015-07-30 18:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CADZB0_ZgDMhVgCUh2PTAPDL7k_W8QGt_HLYdkwv_qQ5xEMn8HA@mail.gmail.com>
2015-07-29 14:09 ` Vali Zero
2015-07-29 17:47 ` Raystonn .
2015-07-29 22:54 ` s7r
2015-07-30 3:41 ` Ryan Butler
2015-07-30 4:00 ` Adam Back
2015-07-30 4:05 ` Adam Back
2015-07-30 4:48 ` Ryan Butler
2015-07-30 13:14 ` Tom Harding
2015-07-30 14:25 ` Dave Hudson
2015-07-30 14:57 ` Tom Harding
2015-07-30 18:14 ` Jorge Timón [this message]
2015-07-30 18:16 ` Jorge Timón
2015-07-30 20:53 ` Tom Harding
2015-07-31 1:21 ` Jorge Timón
2015-07-31 1:29 ` Jorge Timón
2015-07-31 9:56 ` Thomas Zander
2015-07-31 12:32 ` Oleg Andreev
2015-07-31 15:24 ` Jorge Timón
2015-07-30 12:45 ` Ivan Brightly
2015-07-30 4:07 ` Jean-Paul Kogelman
2015-07-30 9:52 ` odinn
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=CABm2gDoh69a0335uLhwVndwwLiYtZEVdCvNsrCtHiRAVrSqkaQ@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(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