From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 31D805AE for ; Thu, 5 Nov 2015 23:03:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 090A9142 for ; Thu, 5 Nov 2015 23:03:33 +0000 (UTC) Received: from mail-ig0-f177.google.com ([209.85.213.177]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0LjtQF-1aR4Um1Nc1-00bgvx for ; Fri, 06 Nov 2015 00:03:33 +0100 Received: by igbhv6 with SMTP id hv6so22406220igb.0 for ; Thu, 05 Nov 2015 15:03:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.66.210 with SMTP id h18mr6260673igt.55.1446764612594; Thu, 05 Nov 2015 15:03:32 -0800 (PST) Received: by 10.50.180.199 with HTTP; Thu, 5 Nov 2015 15:03:32 -0800 (PST) Date: Fri, 6 Nov 2015 00:03:32 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Adam Back To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:stvmRCpXXWFloujvYOrUGLjw1Qlm3igDeMLPBDSfbNMfl4FcTQ1 Y4NiUhkWw4Nm0CB/TBFe2h1zS1OqiwXPhUybt9d3b7sEJPlyYyfKkZH6IPS4qL1WvBYlRq/ s6EZAnwlGBYzv9Uw9C0+v5AYOsB9b3VO50EKmHOvF8rVb971uumQvwfxhGWkvWm7GwXHDYT 8S9f7ewJzJnhh8JQLM9wA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kkfYt7vYthg=:lFpdIG+L59EQrTLdayY6u2 eZoGUc6hSGtbch9kfd1b03/1H7VhLCTdDLSJMrocgGGvDskgPLSUBvMYywAlCtPGGVySeOqFA xzEFAFJ2XdpJSMC+6aQd+f8+d16a1uf/5U1K/BlVrRwlc67tSxfJ8BUmKSkJfpSql1wCXkcpD j3nT04lq2MmgqyEdlxgb6JaCAK60lEzE249ImTJiqguyOknW4fz5MzEkqG0K96yjFnVXMASOL H5NCfqj1zOxbkRgXsAW5zjcLpkP3Q6PVD0g6BU6UQyx/NeNQoW7G0vftxeJjLq7F6VEcSkGPA deW38fODDLtTqjAx0crL+SmukdtQ1cpmj2pFnwAAs1G7LeVvLcKWQLpHWj14IIsPsasguzyKT AAodNP6EH6gMHxUteud5atq3EY3wyKEjUra1D1AlL87NMt9X0MQLj0Cp+N5WNXUGaT7cmBr1k Pc5GUnot4Z4XpKcRpIx6nX5emp+OgnIsGlUd8q8CylgOpd7togwY+hGyQPjtqsVgaumaTN/J4 8DptoJlClHgXP7SFheJuSdxTRaka+wgRDh+Snf7P8UEzZZ9U24KkLHs8DX/hygABtXtvHnWGH tSy0sd3AzjyHRdP3OK4Tke1e740ek64ApiolBTbAghWCiRJb8ytpNxIsmTE8D+ROb7AkCDE5C R8R4jazEF25sd2LadlGhXVORfDj77W49IjSXSwF3UqGcsJprd9RaP0C1QxROIYk6ewQ6/k//e +ZAauo162uW6OpfU X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] summarising security assumptions (re cost metrics) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 23:03:35 -0000 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