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 DDC74405 for ; Fri, 31 Jul 2015 18:04:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 48FE413E for ; Fri, 31 Jul 2015 18:04:54 +0000 (UTC) Received: by ioea135 with SMTP id a135so93005513ioe.1 for ; Fri, 31 Jul 2015 11:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IcjpPSJLSeXT3a1ZF4ytFqGxrMRfqAKKOu9ZR6it0/c=; b=PMHsGo3eQbBPCXOtepDIT6qAhOPJxsnWxtg+hGoaH8Mfogsz2YkEpeR/fs8OOwf2Xx tfhxEAKMzrVP3QxhT1riF+Kmk6fBfz+bo3WR6MNT5wj8ty3MdgSgaGrdcPSuBjPLX+2G yLdzj9Sv4JE0QH20fEz8/zqo51qqtkY8VFmg/ExOl6jUd076qmMYR1LeXKXcwDkJwa3g xKS40HH2VbWcDEpaKkIQxMd7erryzrXwSziu45P1FK5EmwCRH5CqcPn0jmXcgFmXGMxd g5LvvkgzsXEGo+AhSCbgjcUW/WA7KbHU3aWCWPOOjLZeOuTuurK8I2BZSxCFSIWb6Bic 75iQ== MIME-Version: 1.0 X-Received: by 10.107.150.141 with SMTP id y135mr6895821iod.38.1438365893654; Fri, 31 Jul 2015 11:04:53 -0700 (PDT) Received: by 10.36.208.131 with HTTP; Fri, 31 Jul 2015 11:04:53 -0700 (PDT) In-Reply-To: References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com> <20150731130714.Horde.PvL1IB3Kf5S6GAA73N-HOw1@server47.web-hosting.com> Date: Fri, 31 Jul 2015 14:04:53 -0400 Message-ID: From: "G. Andrew Stone" To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11403fd4260095051c2fa86f X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal 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, 31 Jul 2015 18:04:55 -0000 --001a11403fd4260095051c2fa86f Content-Type: text/plain; charset=UTF-8 There's a large array of solutions that are bigger than the cheapest home broadband, but smaller then renting hardware in a data center. Every company with internet service to their location purchases one of these options. If Bitcoin full node bandwidth requirements ever exceed a hobbyist's reach, s/he can always pool resources with other individuals to purchase one of these solutions, and a 1-room office. How many of you have connected to multiple ISPs and are routing internet traffic between them? But TCP is still permissionless. Bitcoin node requirements will grow beyond a hobbyist reach (but not that of the garage entrepreneur). The truth is that as technologies grow and mature, the hobbyists move on but anyone who has a real reason to continue using it stays. This fact does not destroy its decentralization. I do not think that reasonable scaling will significantly affect full node quantity (historical downtrends are conflated with the simultaneous transition from hobbyist to professional). At the same time the ability to create an independent full node is a tremendous force keeping existing full nodes honest -- this potential is more powerful then the fact. Which would you choose, a 10 thousand node strong bankCoin, or a 1000 node open source permissionless Bitcoin? On Fri, Jul 31, 2015 at 12:22 PM, Dave Scotese via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Here are some books that will help more people understand why Adam's > concern is important: > Kicking the Dragon (by Larken Rose) > The State (by Franz Oppenheimer) > > Like he said, it isn't much about bitcoin. Our crypto is just one of the > defenses we've created, and understanding what it defends will help us > maintain its value. > > Dave > > On Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> I think trust the data-center logic obviously fails, and I was talking >> about this scenario in the post you are replying to. You are trusting the >> data-center operator period. If one could trust data-centers to run >> verified code, to not get hacked, filter traffic, respond to court orders >> without notifying you etc that would be great but that's unfortunately not >> what happens. >> >> Data-center operators are bound to follow laws, including NSLs and gag >> orders. They also get hacked, employ humans who can be corrupt, >> blackmailed, and themselves centralisation points for policy attack. >> Snowden related disclosures and keeping aware of security show this is very >> real. >> >> This isn't much about bitcoin even, its just security reality for hosting >> anything intended to be secure via decentralisation, or just hosting in >> general while at risk of political or policy attack. >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11403fd4260095051c2fa86f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's a large array of solutions that are bigger tha= n the cheapest home broadband, but smaller then renting hardware in a data = center.=C2=A0 Every company with internet service to their location purchas= es one of these options.=C2=A0 If Bitcoin full node bandwidth requirements = ever exceed a hobbyist's reach, s/he can always pool resources with oth= er individuals to purchase one of these solutions, and a 1-room office.=C2= =A0

How many of you have connected to multiple ISPs and are routing= internet traffic between them?=C2=A0 But TCP is still permissionless.
<= br>Bitcoin node requirements will grow beyond a hobbyist reach (but not tha= t of the garage entrepreneur). =C2=A0 The truth is that as technologies gro= w and mature, the hobbyists move on but anyone who has a real reason to con= tinue using it stays.=C2=A0 This fact does not destroy its decentralization= .=C2=A0

I do not think that reasonable scaling will significantly a= ffect full node quantity (historical downtrends are conflated with the simu= ltaneous transition from hobbyist to professional).

At the same tim= e the ability to create an independent full node is a tremendous force keep= ing existing full nodes honest -- this potential is more powerful then the = fact.=C2=A0

Which would you choose, a 10 thousand node strong bankC= oin, or a 1000 node open source permissionless Bitcoin?


On Fri, Jul 31, 2015 at= 12:22 PM, Dave Scotese via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
Here are some books that will he= lp more people understand why Adam's concern is important:
Kic= king the Dragon (by Larken Rose)
The State (by Franz Oppenheimer)<= br>
Like he said, it isn't much about bitcoin.=C2=A0 Our crypt= o is just one of the defenses we've created, and understanding what it = defends will help us maintain its value.

Dave

On Fri, Jul 31, 2015 at 6= :16 AM, Adam Back via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org> wrote:

I think trust the data-center logic obviously fails, and I was talking=20 about this scenario in the post you are replying to.=C2=A0 You are trusting= =20 the data-center operator period.=C2=A0 If one could trust data-centers to r= un verified code, to not get hacked, filter traffic, respond to court=20 orders without notifying you etc that would be great but that's=20 unfortunately not what happens.

Data-center operators are bound to follow laws, including=20 NSLs and gag orders.=C2=A0 They also get hacked, employ humans who can be= =20 corrupt, blackmailed, and themselves centralisation points for policy=20 attack.=C2=A0 Snowden related disclosures and keeping aware of security sho= w=20 this is very real.

This isn't much about bitcoin even, its just security=20 reality for hosting anything intended to be secure via decentralisation, or just hosting in general while at risk of political or policy attack.



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


--001a11403fd4260095051c2fa86f--