From: Benjamin <benjamin.l.cordes@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Sat, 27 Jun 2015 19:46:55 +0200 [thread overview]
Message-ID: <CAOoPuRbqdWWGRL7mRReMdSct2dsiFw_X9YtNJWquZS=fsCdCDQ@mail.gmail.com> (raw)
In-Reply-To: <20150627173724.GA30546@muck>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
There is no ensured Quality of service, is there? If you "bid" higher, then
you don't know what you are going to get. Also because you have no way of
knowing what *others* are bidding. Only if you have auctions (increasing
increments) you can establish a feedback loop to settle demand and supply.
And the supply side doesn't adapt. Adapting supply would help resolve parts
of the capacity problem.
On Sat, Jun 27, 2015 at 7:37 PM, Peter Todd <pete@petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 07:26:00PM +0200, Benjamin wrote:
> > "Thus we have a fixed capacity system where access is mediated by supply
> > and demand transaction fees."
> >
> > There is no supply and demand. That would mean users would be able to
> adapt
> > fees and get different quality of service depending on current capacity.
> > For example if peak load is 10x average load, then at those times fees
> > would be higher and users would delay transactions to smooth out demand.
>
> That's exactly how Bitcoin works already. See my article on how
> transaction fees work for more details:
>
> https://gist.github.com/petertodd/8e87c782bdf342ef18fb
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
[-- Attachment #2: Type: text/html, Size: 1883 bytes --]
next prev parent reply other threads:[~2015-06-27 17:46 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-27 14:39 [bitcoin-dev] A Proposed Compromise to the Block Size Limit Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29 ` Randi Joseph
2015-06-27 15:32 ` Peter Todd
2015-06-27 16:19 ` Michael Naber
2015-06-27 17:20 ` Peter Todd
2015-06-27 17:26 ` Benjamin
2015-06-27 17:37 ` Peter Todd
2015-06-27 17:46 ` Benjamin [this message]
2015-06-27 17:54 ` Peter Todd
2015-06-27 17:58 ` Venzen Khaosan
2015-06-27 19:34 ` Benjamin
2015-06-27 15:33 ` Adam Back
2015-06-27 16:09 ` Michael Naber
2015-06-27 16:28 ` Mark Friedenbach
2015-06-27 16:37 ` Peter Todd
2015-06-27 17:25 ` Michael Naber
2015-06-27 17:34 ` Peter Todd
2015-06-27 18:02 ` Jameson Lopp
2015-06-27 18:47 ` Peter Todd
2015-06-28 5:34 Raystonn
2015-06-28 10:07 ` Adam Back
2015-06-28 10:29 ` Benjamin
2015-06-28 12:37 ` Adam Back
2015-06-28 16:32 ` Raystonn .
2015-06-28 17:12 ` Mark Friedenbach
2015-06-28 17:18 ` Benjamin
2015-06-28 17:29 ` Gavin Andresen
2015-06-28 17:45 ` Mark Friedenbach
2015-06-28 17:51 ` Adam Back
2015-06-28 18:58 ` Adam Back
2015-06-28 21:05 ` Gavin Andresen
2015-06-28 21:23 ` Michael Naber
2015-06-28 22:07 ` Adam Back
2015-06-29 0:59 ` Eric Lombrozo
2015-06-29 1:13 ` Eric Lombrozo
2015-06-29 1:45 ` Andy Schroder
2015-06-30 0:42 ` Tom Harding
2015-07-10 2:55 ` Tom Harding
2015-06-28 17:53 ` Jorge Timón
2015-06-28 19:22 ` Andrew Lapp
2015-06-28 19:40 ` Benjamin
2015-06-28 12:32 ` Milly Bitcoin
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='CAOoPuRbqdWWGRL7mRReMdSct2dsiFw_X9YtNJWquZS=fsCdCDQ@mail.gmail.com' \
--to=benjamin.l.cordes@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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