diff options
| author | Daniel Lidstrom <lidstrom83@gmail.com> | 2013-03-07 14:31:10 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-03-07 21:31:17 +0000 |
| commit | 5fe1eb10ca84fe0c8a7a90970ce019258842b46f (patch) | |
| tree | 0d7e777d86aa4d61f0b3b9cced1e22c936498d4e | |
| parent | 07b989f0c1686a8659f062d0efd74a19727f5db0 (diff) | |
| download | pi-bitcoindev-5fe1eb10ca84fe0c8a7a90970ce019258842b46f.tar.gz pi-bitcoindev-5fe1eb10ca84fe0c8a7a90970ce019258842b46f.zip | |
Re: [Bitcoin-development] Large-blocks and censorship
| -rw-r--r-- | 97/170dd4ccc69651d1016ff7af14c04b2af488f6 | 217 |
1 files changed, 217 insertions, 0 deletions
diff --git a/97/170dd4ccc69651d1016ff7af14c04b2af488f6 b/97/170dd4ccc69651d1016ff7af14c04b2af488f6 new file mode 100644 index 000000000..77ade532d --- /dev/null +++ b/97/170dd4ccc69651d1016ff7af14c04b2af488f6 @@ -0,0 +1,217 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <lidstrom83@gmail.com>) id 1UDiPF-0003tr-2E + for bitcoin-development@lists.sourceforge.net; + Thu, 07 Mar 2013 21:31:17 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.210.178 as permitted sender) + client-ip=209.85.210.178; envelope-from=lidstrom83@gmail.com; + helo=mail-ia0-f178.google.com; +Received: from mail-ia0-f178.google.com ([209.85.210.178]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1UDiPE-0006Ar-1y + for bitcoin-development@lists.sourceforge.net; + Thu, 07 Mar 2013 21:31:17 +0000 +Received: by mail-ia0-f178.google.com with SMTP id o25so889193iad.9 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 07 Mar 2013 13:31:10 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.50.40.162 with SMTP id y2mr15647864igk.65.1362691870674; + Thu, 07 Mar 2013 13:31:10 -0800 (PST) +Received: by 10.64.8.168 with HTTP; Thu, 7 Mar 2013 13:31:10 -0800 (PST) +In-Reply-To: <CANEZrP3oHropYJ1zEXCw1QdtRimK_JxeohOh1yNkPxzZohcXnA@mail.gmail.com> +References: <20130307110018.GA7491@savin> + <CANEZrP0MHA_Mv37DSv=CLBWLHo_-ajRgNRd1-4EGJ2GZvTxiJQ@mail.gmail.com> + <20130307183035.GA9083@savin> + <CANEZrP3oHropYJ1zEXCw1QdtRimK_JxeohOh1yNkPxzZohcXnA@mail.gmail.com> +Date: Thu, 7 Mar 2013 14:31:10 -0700 +Message-ID: <CADjHg8EQbmdpFE6yxq5tvkn49WUGz2Yv3WEeWzG+LMPAMAHCww@mail.gmail.com> +From: Daniel Lidstrom <lidstrom83@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=14dae9341283e3d8d304d75c6c75 +X-Spam-Score: -0.3 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (lidstrom83[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in + digit (lidstrom83[at]gmail.com) + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1UDiPE-0006Ar-1y +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Large-blocks and censorship +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 07 Mar 2013 21:31:17 -0000 + +--14dae9341283e3d8d304d75c6c75 +Content-Type: text/plain; charset=ISO-8859-1 + +My views on censorship resistance in the face of scaling: + +1) I expect if I'm not careful about preserving my privacy with the way I +use Bitcoin, then I will always run the risk of being censored by miners. +This means connecting to the network anonymously, not reusing addresses, +and perhaps even mixing my coins. The onus is on me here to avoid +censorship, but I'm optimistic that this privacy preservation can be made +pretty automatic. + +2) I expect anonymity systems to scale to accommodate Bitcoin full nodes, +not Bitcoin to stay small to avoid putting pressure on anonymity systems to +scale. + +3) If 2 is too tall an order, then mining in a pool is always an option. +There should always be some countries in the world free enough to allow +mining pools to operate, and miners in countries that ban Bitcoin can +simply connect to these anonymously. If not, then Bitcoin is toast anyway, +is it not? If these miners are really interested in avoiding censoring +transactions, then they will do their due diligence and choose a pool that +doesn't do this. But even if they don't, censorship can be personally +avoided by following 1. + +On Thu, Mar 7, 2013 at 2:19 PM, Mike Hearn <mike@plan99.net> wrote: + +> As an aside, there's a paper coming out in perhaps a few months that +> describes a new way to provide Chaum-style privacy integrated with +> Bitcoin, but without the use of blinding and without any need for +> banks. It's quite smart, I was reviewing the paper this week. +> Unfortunately the technique is too slow and too complicated to +> actually integrate, but you'd probably get a kick out of it. It's +> based on zero knowledge proofs. You can talk to Ian Miers if you like, +> perhaps he'll send you a copy for review. +> +> Back on topic. +> +> This idea is not new. I proposed the idea of regulating miners to +> freeze certain outputs two years ago: +> +> https://bitcointalk.org/index.php?action=printpage;topic=5979.0 +> +> I concluded that it was not a real risk because both mining and +> transactions can be done anonymously. +> +> Your argument rests on the assumption that you can't mine large blocks +> anonymously because Tor doesn't scale. Even if we go along with the +> idea that Tor is the only way to escape regulation (it's not), you +> should maybe take up its inability to move data sufficiently fast with +> the developers. Given that they routinely push two gigabits/second +> today, with an entirely volunteer run network, I think they'll be +> surprised to learn that their project is doomed to never be usable by +> miners. +> +> +> ------------------------------------------------------------------------------ +> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester +> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the +> endpoint security space. For insight on selecting the right partner to +> tackle endpoint security challenges, access the full report. +> http://p.sf.net/sfu/symantec-dev2dev +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +--14dae9341283e3d8d304d75c6c75 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +My views on censorship resistance in the face of scaling:<br><br>1) I=20 +expect if I'm not careful about preserving my privacy with the way I us= +e + Bitcoin, then I will always run the risk of being censored by miners.=A0= +=20 +This means connecting to the network anonymously, not reusing addresses, + and perhaps even mixing my coins.=A0 The onus is on me here to avoid=20 +censorship, but I'm optimistic that this privacy preservation can be=20 +made pretty automatic.<br> +<br>2) I expect anonymity systems to scale to accommodate Bitcoin full=20 +nodes, not Bitcoin to stay small to avoid putting pressure on anonymity=20 +systems to scale.<br><br>3) If 2 is too tall an order, then mining in a=20 +pool is always an option.=A0 There should always be some countries in the= +=20 +world free enough to allow mining pools to operate, and miners in=20 +countries that ban Bitcoin can simply connect to these anonymously.=A0 If= +=20 +not, then Bitcoin is toast anyway, is it not?=A0 If these miners are=20 +really interested in avoiding censoring transactions, then they will do=20 +their due diligence and choose a pool that doesn't do this.=A0 But even= + if + they don't, censorship can be personally avoided by following 1.<br><b= +r><div class=3D"gmail_quote">On Thu, Mar 7, 2013 at 2:19 PM, Mike Hearn <sp= +an dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik= +e@plan99.net</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"> +As an aside, there's a paper coming out in perhaps a few months that<br= +> +describes a new way to provide Chaum-style privacy integrated with<br> +Bitcoin, but without the use of blinding and without any need for<br> +banks. It's quite smart, I was reviewing the paper this week.<br> +Unfortunately the technique is too slow and too complicated to<br> +actually integrate, but you'd probably get a kick out of it. It's<b= +r> +based on zero knowledge proofs. You can talk to Ian Miers if you like,<br> +perhaps he'll send you a copy for review.<br> +<br> +Back on topic.<br> +<br> +This idea is not new. I proposed the idea of regulating miners to<br> +freeze certain outputs two years ago:<br> +<br> +=A0 =A0<a href=3D"https://bitcointalk.org/index.php?action=3Dprintpage;topi= +c=3D5979.0" target=3D"_blank">https://bitcointalk.org/index.php?action=3Dpr= +intpage;topic=3D5979.0</a><br> +<br> +I concluded that it was not a real risk because both mining and<br> +transactions can be done anonymously.<br> +<br> +Your argument rests on the assumption that you can't mine large blocks<= +br> +anonymously because Tor doesn't scale. Even if we go along with the<br> +idea that Tor is the only way to escape regulation (it's not), you<br> +should maybe take up its inability to move data sufficiently fast with<br> +the developers. Given that they routinely push two gigabits/second<br> +today, with an entirely volunteer run network, I think they'll be<br> +surprised to learn that their project is doomed to never be usable by<br> +miners.<br> +<div><div><br> +---------------------------------------------------------------------------= +---<br> +Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester<br> +Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" = +in the<br> +endpoint security space. For insight on selecting the right partner to<br> +tackle endpoint security challenges, access the full report.<br> +<a href=3D"http://p.sf.net/sfu/symantec-dev2dev" target=3D"_blank">http://p= +.sf.net/sfu/symantec-dev2dev</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</div></div></blockquote></div><br> + +--14dae9341283e3d8d304d75c6c75-- + + |