Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 100A13EE for ; Wed, 12 Aug 2015 01:56:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49D33FB for ; Wed, 12 Aug 2015 01:56:01 +0000 (UTC) Received: by igbjg10 with SMTP id jg10so34188154igb.0 for ; Tue, 11 Aug 2015 18:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wjJli8DMXaKA+mkxekWwAj4oS0yXjRR63dgMPkNyTu0=; b=TE2sLSRD+5mvWuum8v6F2rxJr2LekusWgBKxsvqSJ1eLDwJBnCSDdK2ropD3UAwiix 9ZAUv9HSowYbiLxL79FswzThjqbxIa8NNS7UUL05sZXO6/NvMNK8oWSeyatgc51SC6mP t6xjIbaUuuIwXDkHskKQsWdTTmjZWqah9Cgq5W7ssd+1OviRlqdsdnmjF62tDoJcBfiH VE2AdSeRD7ytPtbl819eP5tetL2j2LeFYFD2Mn4TagX850haXsI8k0EVrliAJGn/6iMN 4A0HORcvAqx1yFxLLiPDDKkeykJEG00TWNKVvpSb8QUTlwCD/jrj62g3AFmUAZcrojlc k4jw== MIME-Version: 1.0 X-Received: by 10.50.143.37 with SMTP id sb5mr21520687igb.13.1439344560726; Tue, 11 Aug 2015 18:56:00 -0700 (PDT) Received: by 10.64.127.103 with HTTP; Tue, 11 Aug 2015 18:56:00 -0700 (PDT) Date: Tue, 11 Aug 2015 18:56:00 -0700 Message-ID: From: Corey Haddad To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1135fe4e4067d2051d1385c5 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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: [bitcoin-dev] Fees and the block-finding process 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: Wed, 12 Aug 2015 01:56:02 -0000 --001a1135fe4e4067d2051d1385c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org > wrote: >Neither one of those assertions is clear. Keep in mind the goal is to have >Bitcoin survive active censorship. Presumably that means being able to run >a node even in the face of a hostile ISP or government. Furthermore, it >means being location independent and being able to move around. In many >places the higher the bandwidth requirements the fewer the number of ISPs >that are available to service you, and the more visible you are. >It may also be necessary to be able to run over Tor. And not just today's >Tor which is developed, serviced, and supported by the US government, but = a >Tor or I2P that future governments have turned hostile towards and activel= y >censor or repress. Or existing authoritative governments, for that matter. >How much bandwidth would be available through those connections? >It may hopefully never be necessary to operate under such constraints, >except by freedom seeking individuals within existing totalitarian regimes= . >However the credible threat of doing so may be what keeps Bitcoin from >being repressed in the first place. Lose the capability to go underground, >and it will be pressured into regulation, eventually. I agree on the importance of having the credible threat of being able to operate in the underground, and for the reasons you outlined. However, I see that threat as being inherent in the now-public-knowledge that a system like Bitcoin can exist. The smart governments already know that Bitcoin-like systems are unstoppable phenomena, that they can operate over Tor and I2P, that they can and do run without central servers, and that they can be run on commodity hardware without detection. Bitcoin itself does not need to constantly operate in survival-mode, hunkered down, and always ready for big brother=E2=80=99s onslaught, to benefit from the prote= ction of the =E2=80=98credible threat=E2=80=99. It=E2=80=99s important to accurately asses the level of threat the Bitcoin = system faces from regulation, legislation, and government =E2=80=98operations=E2= =80=99. If we are too paranoid, we are going to waste resources or forgo opportunities in the name of, essentially, baseless fear. When I got involved with this project in 2012, no one really knew how governments were going to react. Had an all out war-on-Bitcoin been declared, I think it=E2=80=99s pretty safe to s= ay the structure of the network would look different than it does today. We would probably be discussing ways to disguise Bitcoin traffic to look like VoIP calls, not talking about how to best scale the network. In light of the current regulatory climate surrounding Bitcoin, I believe the best security against a state-sponsored / political crackdown to be gained at this time comes from growing the user base and use cases, as opposed to hardening and fortifying the protocol. Uber is a great example of this form of security-though-adoption, as was mentioned earlier today on this mailing list. If there are security or network-hardening measures that don=E2=80=99t come= at the expense of growing the user base and use cases, then there is no reason not to adopt them. The recent improvements in Tor routing are a great example of a security improvement that in no meaningful way slows Bitcoin=E2=80=99s potential growth. How does this relate to the Blocksize debate? Let=E2=80= =99s accept that 8 MB blocks might cause a little bit, and perhaps even a =E2=80=98medium bit=E2=80=99 (however that is measured), of centralization.= Although the network might be slightly more vulnerable to government attack, if millions more people are able to join the system as a result, I=E2=80=99d wager the = overall security situation would be stronger, owning to greatly decreased risk of attack. -Corey (CubicEarth) --001a1135fe4e4067d2051d1385c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tur, Aug 11, 2015 at 07:0= 8 AM,=C2=A0Mark Friedenbach=C2=A0via bitcoin-dev <

>Neith= er one of those assertions is clear. Keep in mind the goal is to have
=
>Bitcoin survive active censorship. Presum= ably that means being able to run
>a = node even in the face of a hostile ISP or government. Furthermore, it
=
>means being location independent and bein= g able to move around. In many
>place= s the higher the bandwidth requirements the fewer the number of ISPs
<= div style=3D"font-size:13px">>that are available to service you, and the= more visible you are.

>It may also be necessary to be able to run over = Tor. And not just today's
>Tor wh= ich is developed, serviced, and supported by the US government, but a
=
>Tor or I2P that future governments have t= urned hostile towards and actively
>c= ensor or repress. Or existing authoritative governments, for that matter.
>How much bandwidth would be available= through those connections?

>It may hopefully never be necessary to oper= ate under such constraints,
>except b= y freedom seeking individuals within existing totalitarian regimes.
>However the credible threat of doing so may= be what keeps Bitcoin from
>being re= pressed in the first place. Lose the capability to go underground,
>and it will be pressured into regulation, ev= entually.

I agree on the importance of having the credible threat of being = able to operate in the underground, and for the reasons you outlined.=C2=A0= However, I see that threat as being inherent in the now-public-knowledge t= hat a system like Bitcoin can exist.=C2=A0 The smart governments already kn= ow that Bitcoin-like systems are unstoppable phenomena, that they can opera= te over Tor and I2P, that they can and do run without central servers, and = that they can be run on commodity hardware without detection.=C2=A0 Bitcoin= itself does not need to constantly operate in survival-mode, hunkered down= , and always ready for big brother=E2=80=99s onslaught, to benefit from the= protection of the =E2=80=98credible threat=E2=80=99.

It=E2=80=99s importan= t to accurately asses the level of threat the Bitcoin system faces from reg= ulation, legislation, and government =E2=80=98operations=E2=80=99.=C2=A0 If= we are too paranoid, we are going to waste resources or forgo opportunitie= s in the name of, essentially, baseless fear.=C2=A0 When I got involved wit= h this project in 2012, no one really knew how governments were going to re= act.=C2=A0 Had an all out war-on-Bitcoin been declared, I think it=E2=80=99= s pretty safe to say the structure of the network would look different than= it does today.=C2=A0 We would probably be discussing ways to disguise Bitc= oin traffic to look like VoIP calls, not talking about how to best scale th= e network.=C2=A0 In light of the current regulatory climate surrounding Bit= coin, I believe the best security against a state-sponsored / political cra= ckdown to be gained at this time comes from growing the user base and use c= ases, as opposed to hardening and fortifying the protocol.=C2=A0 Uber is a = great example of this form of security-though-adoption, as was mentioned ea= rlier today on this mailing list.

If there are security or network-hardenin= g measures that don=E2=80=99t come at the expense of growing the user base = and use cases, then there is no reason not to adopt them.=C2=A0 The recent = improvements in Tor routing are a great example of a security improvement t= hat in no meaningful way slows Bitcoin=E2=80=99s potential growth.=C2=A0 Ho= w does this relate to the Blocksize debate?=C2=A0 Let=E2=80=99s accept that= 8 MB blocks might cause a little bit, and perhaps even a =E2=80=98medium b= it=E2=80=99 (however that is measured), of centralization.=C2=A0 Although t= he network might be slightly more vulnerable to government attack, if milli= ons more people are able to join the system as a result, I=E2=80=99d wager = the overall security situation would be stronger, owning to greatly decreas= ed risk of attack.

-Corey (CubicEarth)
--001a1135fe4e4067d2051d1385c5--