From: Adam Back <adam@cypherspace•org>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] summarising security assumptions (re cost metrics)
Date: Fri, 6 Nov 2015 00:03:32 +0100 [thread overview]
Message-ID: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com> (raw)
Some thoughts, hope this is not off-topic.
Maybe we should summarise the security assumptions and design
requirements. It is often easier to have clear design discussions by
first articulating assumptions and requirements.
Validators: Economically dependent full nodes are an important part of
Bitcoin's security model because they assure Bitcoin security by
enforcing consensus rules. While full nodes do not have orphan
risk, we also dont want maliciously crafted blocks with pathological
validation cost to erode security by knocking reasonable spec full
nodes off the network on CPU (or bandwidth grounds).
Miners: Miners are in a commodity economics competitive environment
where various types of attacks and collusion, even with small
advantage, may see actual use due to the advantage being significant
relative to the at times low profit margin
It is quite important for bitcoin decentralisation security that small
miners not be significantly disadvantaged vs large miners. Similarly
it is important that there not be significant collusion advantages
that create policy centralisation as a side-effect (for example what
happened with "SPV mining" or validationless mining during BIP66
deployment). Examples of attacks include selfish-mining and
amplifying that kind of attack via artificially large or
pathologically expensive to validate blocks. Or elevating orphan risk
for others (a miner or collusion of miners is not at orphan risk for a
block they created).
Validators vs Miner decentralisation balance:
There is a tradeoff where we can tolerate weak miner decentralisation
if we can rely on good validator decentralisation or vice versa. But
both being weak is risky. Currently given mining centralisation
itself is weak, that makes validator decentralisation a critical
remaining defence - ie security depends more on validator
decentralisation than it would if mining decentralisation was in a
better shape.
Security:
We should consider the pathological case not average or default behaviour
because we can not assume people will follow the defaults, only the
consensus-enforced rules.
We should not discount attacks that have not seen exploitation to
date. We have maybe benefitted from universal good-will (everybody
thinks Bitcoin is cool, particularly people with skills to find and
exploit attacks).
We can consider a hierarchy of defences most secure to least:
1. consensus rule enforced (attacker loses block reward)
2. economic alignment (attacker loses money)
3. overt (profitable, but overt attacks are less likely to be exploited)
4. meta-incentive (relying on meta-incentive to not damage the ecosystem only)
Best practices:
We might want to list some best practices that are important for the
health and security of the Bitcoin network.
Rule of thumb KISS stuff:
We should aim to keep things simple in general and to avoid creating
complex optimisation problems for transaction processors, wallets,
miners.
We may want to consider an incremental approach (shorter-time frame or
less technically ambitious) in the interests of simplifying and
getting something easier to arrive at consensus, and thus faster to
deploy.
We should not let the perfect be the enemy of the good. But we should
not store new problems for the future, costs are stacked in favour of
getting it right vs A/B testing on the live network.
Not everything maybe fixable in one go for complexity reasons or for
the reason that there is no clear solution for some issues. We should
work incrementally.
Adam
next reply other threads:[~2015-11-05 23:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 23:03 Adam Back [this message]
2015-11-05 23:33 ` Eric Voskuil
2015-11-06 1:56 ` Jeremy
2015-11-06 8:05 ` Chris Priest
2015-11-06 14:08 ` Adam Back
2015-11-06 23:41 ` Chris Priest
2015-11-07 0:44 ` Eric Voskuil
2015-11-08 14:54 ` Gavin Andresen
2015-11-08 17:19 ` Bryan Bishop
2015-11-09 16:27 ` Gavin Andresen
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=CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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