On Thu, Nov 5, 2015 at 11:03 PM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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).
>
Agreed. That is why BIP101 / BitcoinXT includes code to limit the relay and
validation cost of blocks.
>
> 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
>
Agreed, with a quibble: mining economics means they will ALWAYS have a 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).
>
Okey dokey-- perhaps we should have another discussion about SPV mining, as
far as I know it harmed nobody besides the miners who mindlessly created
invalid, empty blocks (well, and besides being very annoying for developers
who had to figure out what was happening and get the offending miners to do
the right thing).
In any case, it seems to me all of this (except perhaps selfish mining) is
independent of the maximum block size, and solutions for all of the above
(including selfish mining) should be pursued regardless of what is done
with the max block size (e.g. I sent Ittay and Gun email a few minutes ago
with some might-be-wong-ideas for how weak block announcements might be
used to detect selfish mining).
>
> 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.
>
I'm very disappointed you don't mention the tradeoff at "the other end of
the bathtub" -- Key-holder versus Validator decentralization balance. Did
you see the excellent Poon/Dryja "bathtub" presentation at Montreal?
https://scalingbitcoin.org/montreal2015/presentations/Day2/3-JosephPoonAndThaddeusDryja.pdf
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.
>
Agreed, which is why BIP101/XT consider pathological behavior.
>
> 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).
>
Disagree on wording: we should not ignore attacks that have not seen
exploitation. But in the never-ending-list of things to be worried about
and to write code for, attacks that have not been seen should be lower
priority than attacks that have been seen, either in Bitcoin or elsewhere.
E.g. Bitcoin has never seen a buffer-overflow attack, but we absolutely
positively need to put a very high priority on the network attack surface
-- we know buffer-overflow attacks are commonly exploited.
On the other hand, Bitcoin has never seen a "Goldfinger attack" (take a big
short position on Bitcoin, then find a way to destroy confidence so the
price drops and you can profit), and "Goldfinger attacks" don't seem to be
common anywhere (you don't see people taking huge short positions in
companies and then bombing their factories). There might be a reason
Bitcoin is more vulnerable, or the same checks-and-balances (e.g. whoever
took the other side of the large short has a strong incentive to report
you, and assuming you got paid in something other than Bitcoin that is
probably possible).
(Aside: anybody who wants to talk about the likelihood of
