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 _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
