Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5108F97 for ; Fri, 6 Nov 2015 01:57:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D060D2 for ; Fri, 6 Nov 2015 01:57:12 +0000 (UTC) X-AuditID: 1209190c-f79c96d00000038e-fe-563c08f7b6db Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id EC.EA.00910.7F80C365; Thu, 5 Nov 2015 20:57:11 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tA61vA25001871 for ; Thu, 5 Nov 2015 20:57:11 -0500 Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA61v9tq014423 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 Nov 2015 20:57:10 -0500 Received: by ykek133 with SMTP id k133so165909280yke.2 for ; Thu, 05 Nov 2015 17:57:08 -0800 (PST) X-Received: by 10.129.132.86 with SMTP id u83mr1037300ywf.111.1446775028917; Thu, 05 Nov 2015 17:57:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.156.69 with HTTP; Thu, 5 Nov 2015 17:56:49 -0800 (PST) In-Reply-To: <563BE746.5030406@voskuil.org> References: <563BE746.5030406@voskuil.org> From: Jeremy Date: Thu, 5 Nov 2015 20:56:49 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary=001a114f25fcab307b0523d58f9c X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6novudwybMYMpNMYum17YOjB6/f0xm DGCM4rJJSc3JLEst0rdL4MrYtuQte8Flw4p7E26yNjDO0Opi5OSQEDCRWHqzlRXCFpO4cG89 WxcjF4eQwGImifkTO6CcO4wSzXNnMUM4H5gkLj/qZYFwJjFKtD+ewQzRXyLxduZ6dhCbV0BQ 4uTMJ0BFHEBFXhKfvxqChDkFtCX2rrrGBmILCRRKzPi0hR2khE1ATuLDL1MQk0VARWLnUW6I gYkSn37MZoIYGCDxe+EcsEOFBXwlbt1cwApSLiKgLNF8oRokzCyQJLHg6HdmCNtL4smaGSwT GIVnITlnFpLULKBuZgF1ifXzhCDCahK3t11lh7C1JZYtfM28gJF1FaNsSm6Vbm5iZk5xarJu cXJiXl5qka6hXm5miV5qSukmRlAUcEry7GB8c1DpEKMAB6MSD6/BcuswIdbEsuLK3EOMkhxM SqK8Lr+BQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR45ZhtwoR4UxIrq1KL8mFS0hwsSuK8m37w hQgJpCeWpGanphakFsFkZTg4lCR4o9iBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGZ4DU8BYXJOYW Z6ZD5E8xWnKsm3FtLRPHlt8gctvUe2uZhFjy8vNSpcR5i0AaBEAaMkrz4GaCktrF0AXbXjGK A70ozNsLUsUDTIhwU18BLWQCWsjUagGysCQRISXVwLiobFuKAIvTEsWq9IIzSmflqi5aJ8WU /NsYMWGzy7LpxYZt3LILBG7UNHcavpv77vUKDZv1FQ+39sYHK12LuvO47PvE457P5lc+2PmI 4+P9z3Prkjd67Nsk5qH5d6LyV0OxlSx/j170jNyZ6seWYPapd77bKqdHtk7Xbxzaz6GrxfEj ctO+9W1KLMUZiYZazEXFiQAxr+0bRQMAAA== X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [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: Fri, 06 Nov 2015 01:57:13 -0000 --001a114f25fcab307b0523d58f9c Content-Type: text/plain; charset=UTF-8 I'd also like to see some more formal analysis of the notion that "$10 in the hand of 10 people is more than $50 in the hand of two, or $100 in the hand of one". I think this encapsulates the security assumption on why we want decentralization at all. This is a very critical property bitcoin exploits for being able to transact large amounts, among other things. (Closely related is the notion that defecting will destroy all the value...) -- @JeremyRubin On Thu, Nov 5, 2015 at 6:33 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote: > > ... > > 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). > > ... > > 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. > > This side of the security model seems underappreciated, if not poorly > understood. Weakening is not just occurring because of the proliferation > of non-validating wallet software and centralized (web) wallets, but > also centralized Bitcoin APIs. > > Over time developers tend to settle on a couple of API providers for a > given problem. Bing and Google for search and mapping, for example. All > applications and users of them, depending on an API service, reduce to a > single validator. Imagine most Bitcoin applications built on the > equivalent of Bing and Google. > > e > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a114f25fcab307b0523d58f9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd also like to s= ee some more formal analysis of the notion that "$10 in the hand of 10= people is more than $50 in the hand of two, or $100 in the hand of one&quo= t;. I think this encapsulates the security assumption on why we want decent= ralization at all.

This is= a very critical property bitcoin exploits for being able to transact large= amounts, among other things. (Closely related is the notion that defecting= will destroy all the value...)




On Thu, Nov 5, 2015 at 6:33 PM, Eric Voskuil= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
On 11/05/2015 03:= 03 PM, Adam Back via bitcoin-dev wrote:
> ...
> Validators: Economically dependent full nodes are an = important part of
> Bitcoin's security model because they assure Bitcoin security by > enforcing consensus rules.=C2=A0 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).
> ...
> Validators vs Miner decentralisation balance:
>
> There is a tradeoff where we can tolerate weak miner decentralisation<= br> > if we can rely on good validator decentralisation or vice versa.=C2=A0= But
> both being weak is risky.=C2=A0 Currently given mining centralisation<= br> > 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.

This side of the security model seems underappreciated, if not poorl= y
understood. Weakening is not just occurring because of the proliferation of non-validating wallet software and centralized (web) wallets, but
also centralized Bitcoin APIs.

Over time developers tend to settle on a couple of API providers for a
given problem. Bing and Google for search and mapping, for example. All
applications and users of them, depending on an API service, reduce to a single validator. Imagine most Bitcoin applications built on the
equivalent of Bing and Google.

e


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a114f25fcab307b0523d58f9c--