Adam Back via bitcoin-dev
2015-11-05 23:03:32 UTC
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
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