From: Benjamin <benjamin.l.cordes@gmail.com>
To: Peter R <peter_r@gmx.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests
Date: Wed, 5 Aug 2015 10:33:13 +0200 [thread overview]
Message-ID: <CAOoPuRb=wDKOoRXuqktDypyJ_gs1w5WORx4+LH84AOEv_PY1ZQ@mail.gmail.com> (raw)
In-Reply-To: <BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com>
[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]
Very interesting paper. When you talk about a market, what are you
referring to exactly? A market means that demand and supply are matched
continuously, and Bitcoin has no such mechanism. A lot of discussion has
been around fixing the "supply" of blocksize. A floating number would mean
that a hardcoded number or function would be replaced by a decision process
involving users (demand). I don't think a fee market exists and that demand
or supply are not easily definable. Ideally supply of transaction
capability would completely depend on demand, and a price would exist such
that demand can react to longterm or shorterm supply constraints. In such a
scenario there would be no scalability concerns, as scale would be almost
perfectly elastic.
On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Dear Bitcoin-Dev Mailing list,
>
> I’d like to share a research paper I’ve recently completed titled “A
> Transaction Fee Market Exists Without a Block Size Limit.” In addition to
> presenting some useful charts such as the cost to produce large spam
> blocks, I think the paper convincingly demonstrates that, due to the
> orphaning cost, a block size limit is not necessary to ensure a functioning
> fee market.
>
> The paper does not argue that a block size limit is unnecessary in
> general, and in fact brings up questions related to mining cartels and the
> size of the UTXO set.
>
> It can be downloaded in PDF format here:
>
> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>
> Or viewed with a web-browser here:
>
>
> https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
>
> *Abstract. *This paper shows how a rational Bitcoin miner should select
> transactions from his node’s mempool, when creating a new block, in order
> to maximize his profit in the absence of a block size limit. To show this,
> the paper introduces the block space supply curve and the mempool demand
> curve. The former describes the cost for a miner to supply block space by
> accounting for orphaning risk. The latter represents the fees offered by
> the transactions in mempool, and is expressed versus the minimum block size
> required to claim a given portion of the fees. The paper explains how the
> supply and demand curves from classical economics are related to the
> derivatives of these two curves, and proves that producing the quantity of
> block space indicated by their intersection point maximizes the miner’s
> profit. The paper then shows that an unhealthy fee market—where miners are
> incentivized to produce arbitrarily large blocks—cannot exist since it
> requires communicating information at an arbitrarily fast rate. The paper
> concludes by considering the conditions under which a rational miner would
> produce big, small or empty blocks, and by estimating the cost of a spam
> attack.
>
> Best regards,
> Peter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 4070 bytes --]
next prev parent reply other threads:[~2015-08-05 8:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-03 15:22 [bitcoin-dev] Eli Dourado on "governance" Gavin Andresen
[not found] ` <1438640036.2828.0.camel@auspira.com>
2015-08-03 22:21 ` Gavin Andresen
2015-08-04 6:40 ` [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests Peter R
2015-08-04 18:41 ` Dave Hudson
2015-08-04 21:18 ` Peter Todd
2015-08-04 21:30 ` Gavin Andresen
2015-08-04 21:46 ` Peter Todd
2015-08-05 0:26 ` Milly Bitcoin
2015-08-05 0:40 ` Neil Fincham
2015-08-04 23:37 ` Dave Hudson
2015-08-05 22:15 ` Peter R
2015-08-05 22:44 ` Dave Hudson
2015-08-05 23:45 ` Tom Harding
2015-08-05 8:33 ` Benjamin [this message]
2015-08-05 9:18 ` Hector Chu
2015-08-05 9:57 ` Adam Back
2015-08-05 10:51 ` Hector Chu
2015-08-05 11:07 ` Adam Back
2015-08-05 11:35 ` Hector Chu
2015-08-05 19:04 ` Hector Chu
2015-08-05 10:26 ` Peter R
[not found] ` <CAAS2fgTzeFnmnr2ScZvf1pDUtF+M3HhF9xo0yhjVPObpqhgz0A@mail.gmail.com>
[not found] ` <6ED57388-6EC3-4515-BF3F-E753301537AB@gmx.com>
[not found] ` <CAAS2fgRoFna4i-d=hpmz-CpV35VQ=J1aEoTTT6B1oD4f15C1KA@mail.gmail.com>
[not found] ` <C8B38FEC-0EF2-483F-9E53-43AB937455A0@gmx.com>
[not found] ` <CAAS2fgQjXNTi9Y_YwLg2dR8baYZhvmEjw43ictt749zR2AOEWw@mail.gmail.com>
[not found] ` <6FED5604-4A6F-4CE1-B42E-36626375D557@gmx.com>
[not found] ` <CAAS2fgQ7hRRvRtD8igcZ2aWBmnqre6iM27peCFGxgC8ODb9jgw@mail.gmail.com>
[not found] ` <6BA86443-7534-4AAA-92BC-EC9B1603DE5F@gmx.com>
[not found] ` <CAAS2fgTTZKD9LQHpMmEH0OU=T8Ta7cCaavWzhM1yQ68-MAT8UQ@mail.gmail.com>
[not found] ` <27B16AB4-0DAD-4665-BF08-7A0C0A70D8D8@gmx.com>
[not found] ` <CAAS2fgRm_CSmWgr7CGmBUD0nX+V0fJ8N4TQN01Vchgip9-s6uQ@mail.gmail.com>
[not found] ` <CAAS2fgT+DP+DaoCMG276uF4=Yoi-w40YyNP-RDRG7NQgOmtpGw@mail.gmail.com>
[not found] ` <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCm ph5FJQhhoLcV1zw@mail.gmail.com>
[not found] ` <CAEgR2PGn_SER18sMuKPJJz5RT=1K=346eCmph5FJQhhoLcV1zw@mail.gmail.com>
2015-08-30 20:08 ` Peter R
2015-08-30 21:02 ` Daniele Pinna
2015-08-04 14:22 ` [bitcoin-dev] Eli Dourado on "governance" Anthony Towns
2015-08-04 18:28 ` Owen
2015-08-05 3:07 ` Eric Lombrozo
2015-08-05 6:32 ` Mashuri Clark
2015-08-05 13:28 ` Mashuri Clark
2015-08-07 16:26 ` Thomas Zander
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='CAOoPuRb=wDKOoRXuqktDypyJ_gs1w5WORx4+LH84AOEv_PY1ZQ@mail.gmail.com' \
--to=benjamin.l.cordes@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=peter_r@gmx.com \
/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