From: Adam Back <adam@cypherspace•org>
To: Hector Chu <hectorchu@gmail•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 11:57:54 +0200 [thread overview]
Message-ID: <CALqxMTGiSdh64G9LVLoCCio3fLNaXUY9v0BeMZV+ZiN6ShY0Ew@mail.gmail.com> (raw)
In-Reply-To: <CAAO2FKGPeBnpB0X3fvqkX+Wy6wOO+m1ZPhEup0Hvv4_nhcRUKA@mail.gmail.com>
On 5 August 2015 at 11:18, Hector Chu via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Miners would be uniquely placed to know how best to vary the block size to maximize their
> profit resulting from these two prices. [...]
> In that respect a dynamic block size voted on by miners periodically would
> go some way to rectify this inefficiency.
This kind of thing has been discussed here, even recently. It is not
without problems.
You may find the flexcap idea summarised in outline by Greg Maxwell
and Mark Friedenbach a month or so back interesting in showing that
one can achieve such effects without handing over a free vote to
miners and hence avoid many (though probably not all) of the
side-effects inherent in giving miners control.
About side-effects, I think we can make argument that there are limits
because other than in an extremis sense, miners are not necessarily in
alignment with security, nor maximising user utility and value
delivered.
For example switching cost economics are common in networks (cell
phone service pricing), maybe Bitcoin would have a really high
switching cost if miners would cartelise.
Also miners are in a complex game competing with each other, and this
degree of control risks selfish mining issues or other cartel attacks
or bandwidth/verification/latency related attacks being made worse.
eg see the recent paper by Aviv Zohar.
Generally speaking economically dependent full nodes are holding
miners honest by design. Changing that dynamic by shifting influence
can have security and control impacting side-effects, and needs to be
thought about carefully.
About security to try to make those comparisons a bit more formal I
posted this taxonomy of types of security that proposals could be
compared against, in order of security:
1. consensus rule (your block is invalid if you attack)
2. economic incentive alignment (you tend to lose money if you attack)
3. overt (attack possible but detectable, hence probably less likely
to happen for reputation or market signal reasons even if possible
anonymously)
4. meta incentive (assume people would not attack if they have an
investment or interest in seeing Bitcoin continue to succeed)
Adam
next prev parent reply other threads:[~2015-08-05 9:57 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
2015-08-05 9:18 ` Hector Chu
2015-08-05 9:57 ` Adam Back [this message]
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=CALqxMTGiSdh64G9LVLoCCio3fLNaXUY9v0BeMZV+ZiN6ShY0Ew@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hectorchu@gmail$(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