diff options
| author | Chris Priest <cp368202@ohiou.edu> | 2015-11-06 15:41:36 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-11-06 23:41:38 +0000 |
| commit | f96d4e7921dd4a37940a75923a214d3cb8681d23 (patch) | |
| tree | 15fdac5db3c9d06be1f942c0b7d528f6a7908ee8 | |
| parent | ecec27d7ddc52ced0a45731585c5f0778140d29e (diff) | |
| download | pi-bitcoindev-f96d4e7921dd4a37940a75923a214d3cb8681d23.tar.gz pi-bitcoindev-f96d4e7921dd4a37940a75923a214d3cb8681d23.zip | |
Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
| -rw-r--r-- | dd/9f46e7859b87532accdc5c08bfe37eec2abc40 | 161 |
1 files changed, 161 insertions, 0 deletions
diff --git a/dd/9f46e7859b87532accdc5c08bfe37eec2abc40 b/dd/9f46e7859b87532accdc5c08bfe37eec2abc40 new file mode 100644 index 000000000..d1d990c9e --- /dev/null +++ b/dd/9f46e7859b87532accdc5c08bfe37eec2abc40 @@ -0,0 +1,161 @@ +Return-Path: <nbvfour@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E48FD8DD + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 6 Nov 2015 23:41:38 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com + [209.85.192.65]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CEF5D16F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 6 Nov 2015 23:41:37 +0000 (UTC) +Received: by qgad10 with SMTP id d10so11922180qga.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 06 Nov 2015 15:41:37 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:sender:in-reply-to:references:date:message-id:subject + :from:to:cc:content-type; + bh=MeNwLXoL4pYYUi3Kob6HEyHkd/SyYepo0O/CC5IE6ik=; + b=ef5MLSXsvMBsNdYBQWl2iHBa7CQla3NiFZ3GjSzF1nzjvzlTcyYyKYCcDSj4AJJIbE + WNS5ljFP5XuqSCVkFtRd82rAeLu3msIrPFZkZ+1wTjxfLI5Joz6k6nssNDtoOawtSJPD + hv5jeDtR0kSbDOjbp4hxIQf3mX6pD/t7GUmffbBEFYRTJRXM+P3zT5qmNhXby5NwND4u + +bax48JqJj8JNpcT8OVeHGLTCIVN1BUyWI63jcftqD107rDF96t5ORWKVC/6tIPrv9Kx + 40N6NhrvIgjwexvjY1vyjecys0gK3AJKmi8BuputraBsr+07jTd0F7dz+kDDwtpvoozG + V/5g== +MIME-Version: 1.0 +X-Received: by 10.140.134.211 with SMTP id 202mr17588279qhg.51.1446853296980; + Fri, 06 Nov 2015 15:41:36 -0800 (PST) +Sender: nbvfour@gmail.com +Received: by 10.140.32.118 with HTTP; Fri, 6 Nov 2015 15:41:36 -0800 (PST) +In-Reply-To: <CALqxMTGnusroDgjt0a7HqfPpS=1n7WNu1uz6bOPG2vQAbCNQ1g@mail.gmail.com> +References: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com> + <563BE746.5030406@voskuil.org> + <CAAcC9yv6JwSY-LhWaFc5cF6CkTwTfLLtqFfemwjJ7hKnfzXuLQ@mail.gmail.com> + <CALqxMTGnusroDgjt0a7HqfPpS=1n7WNu1uz6bOPG2vQAbCNQ1g@mail.gmail.com> +Date: Fri, 6 Nov 2015 15:41:36 -0800 +X-Google-Sender-Auth: xjRubhJP5mYtXMbuTUwmYlpXl0A +Message-ID: <CAAcC9yvq51pj_yH_SsbqGg08sgwNZJ-h+YnY4ekgDUNYLBSRxQ@mail.gmail.com> +From: Chris Priest <cp368202@ohiou.edu> +To: Adam Back <adam@cypherspace.org> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TVD_FUZZY_SECURITIES + 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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 06 Nov 2015 23:41:39 -0000 + +> The bigger point however, which Erik explained, was: widespread use of +> APIs as a sole means of interfacing with the blockchain also +> contributes to reducing network security for everyone, because it +> erodes the consensus rule validation security described under +> "Validators" in the OP. + +I completely disagree with this. You are implying that there is some +sort of ideal ratio of full nodes to 'client only' nodes that the +network must maintain. You seem to be implying that if that ideal +ratio is to somehow be disrupted, then security suffers. My question +to you is what is that ideal ratio and what methodology did you use to +come up with it? + +The way I see it, the security of the system is independent on ratio +between full nodes and lightweight nodes. + +In other words, if there are 100,000 lightweight wallets to 100 full +nodes, then you have the same security profile as one with 100,000 +full nodes to 100 lightweight wallets. + +I think most 'big blockers' think the same way I do, hence the rub +between the two camps. + +Small block people need to make a better case as to how exactly full +node ratio relates to network security (especially the 'for everyone' +part), because the link is not clear to me at all. Small block people +seem to take this simple fact as self evident, but I just don't see +it. + +On 11/6/15, Adam Back <adam@cypherspace.org> wrote: +> You're right that it is better that there be more APIs than fewer, +> that is less of a single point of failure. It also depends what you +> mean by APIs: using an API to have a second cross-check of information +> is quite different to building a wallet or business that only +> interfaces with the blockchain via a 3rd party API. There are +> different APIs also: some are additive eg they add a second signature +> via multisig, but even those models while better can still be a mixed +> story for security, if the user is not also checking their own +> full-node or checking SPV to make the first signature. +> +> Power users and businesses using APIs instead of running a full-node, +> or instead of doing SPV checks, should be clear about the API and what +> security they are delegating to a third party, and whether they have a +> reason to trust the governance and security competence of the third +> party: in the simplest case it can reduce their and their users +> security below SPV. +> +> The bigger point however, which Erik explained, was: widespread use of +> APIs as a sole means of interfacing with the blockchain also +> contributes to reducing network security for everyone, because it +> erodes the consensus rule validation security described under +> "Validators" in the OP. +> +> Adam +> +> +> On 6 November 2015 at 09:05, Chris Priest <cp368202@ohiou.edu> wrote: +>> On 11/5/15, 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 +>>> +>>> +>> +>> I disagree. I think blockchain APIs are a good thing for +>> decentralization. There aren't just 3 or 4 blockexplorer APIs out +>> there, there are dozens. Each API returns essentially the same data, +>> so they are all interchangeable. Take a look at this python package: +>> https://github.com/priestc/moneywagon +> + |