From: Adam Back <adam@cypherspace•org>
To: Ross Nicoll <jrn@jrn•me.uk>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] game-theory, miner incentive alignment vs current proposals
Date: Tue, 23 Jun 2015 21:42:37 +0200 [thread overview]
Message-ID: <CALqxMTFu6DRVMSLsGDa6AgVX1Xamj_X4HhJaTKNTZCAgj6hXNg@mail.gmail.com> (raw)
We shouldnt lose track of the aspect that miner's interests are not
directly aligned with user interests. Users want security,
decentralisation properties and reasonably cheap fees, miners profit
from fees. Particular miners may profit from centralisation. Miners
are in competition with each other in a complex game.
We could do with some analysis on Jeff's BIP and Greg Maxwell's
flexcap (or Meni Rosenfeld's somewhat similar pay for size variant) --
and Gavin's proposal of what miner game-theory is anticipated and how
the proposals hold up under those attacks.
In Gavin's proposal why would we assume that 8MB wont be used? Or the
huge 8GB later. It is free even for a miner to create blocks of any
size up to the cap (zero fees or fees paid to himself).
The stale rate of propagation delay maybe hidden by the relay-network
or by collusion, or advantage of a miner already knowing its own
block.
Will a group of network topology close miners try to create big blocks
that disadvantage other miners?
Or will miners keep blocks small to extract switching-cost fees from
users. (Regardless of cap).
Jeff's proposal has a cost free miner vote for cap increase with a
25%-ile and 90% threshold. But in the second attack (keeping blocks
small) it alternatively becomes easy for an advantaged 10% to force
the block to stay small, in order to extract switching cost fees from
users. Maybe users really love the decentralised features of bitcoin
and are willing to pay a lot! Of course overlaid as Jeff observes by
meta-incentive that miners need to sell mined bitcoin to pay
electricity bills, and want Bitcoin to be in demand and therefore
indirectly to satisfy user demand. But that may still result in a
fair bit of switching cost. Switching cost economics is common in
many networks.
I submit that in terms of robustness of mechanism assuring security,
it be ordered something like:
1. consensus rule
2. aligned economic interest
3. attack requires miner collusion
4. meta-incentive
Then we could evaluate proposals for how robustly they can enforce
user interests vs miner game-theory attack or collusion scenarios.
Adam
On 23 June 2015 at 09:59, Ross Nicoll <jrn@jrn•me.uk> wrote:
> Also, before that's turned into "8MB blocks are infeasible", my presumption is that blocks are not expected to jump suddenly to 8MB, and that most will have time to ramp up storage and bandwidth.
>
> The point about not outright replacing existing test data is the more critical one, anyway, although in retrospect we could simply add spam transactions on top of existing transactions.
reply other threads:[~2015-06-23 19:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CALqxMTFu6DRVMSLsGDa6AgVX1Xamj_X4HhJaTKNTZCAgj6hXNg@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jrn@jrn$(echo .)me.uk \
/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