path: root/dd/9f46e7859b87532accdc5c08bfe37eec2abc40

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
>