From: Peter Todd <pete@petertodd•org>
To: Daniel Lidstrom <lidstrom83@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Large-blocks and censorship
Date: Sun, 10 Mar 2013 04:18:57 -0400 [thread overview]
Message-ID: <20130310081857.GA2609@savin> (raw)
In-Reply-To: <CADjHg8EQbmdpFE6yxq5tvkn49WUGz2Yv3WEeWzG+LMPAMAHCww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]
On Thu, Mar 07, 2013 at 02:31:10PM -0700, Daniel Lidstrom wrote:
> 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.
Yes, but keep in mind the meta risk, which is that as Bitcoin becomes
centralized one of the types of transactions that will be censored are
ones that preserve your privacy. For instance, as it costs thousands of
dollars to setup a mining pool, and hence mining pools also become quite
visible, it would be very easy for local governments to start doing
things like specifying that transactions must be accompanied with a
proof of identification. With that proof of course Bitcoin can remain
totally legal, and the pool in business.
> 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.
Why do you expect that? It's always harder to hide a large amount of
bandwidth than a small one, and stenography is limited by the bandwidth
of the data it's hiding it. HD video streams aren't going to require
more bandwidth in the future.
> 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.
Right now the thing that keeps pools honest is that setting up another
pool is pretty easy; note how most pools are run as hobbyist projects.
Similarly you can always use P2Pool, which is totally decentralized.
But if running the validating node required to run a pool costs
thousands of dollars that competition just isn't there anymore and
starting a new pool isn't an option. Remember there will be a chicken
and egg problem in that the new pool has thousands of dollars in costs,
yet no hashing power yet.
As for constantly moving countries, The Pirate Bay is in the same
position, and as well as they've done, they still wind up getting shut
down periodically. Do you really want access to your funds contingent on
some highly visible mining pools, constantly wondering if their local
government will change their mind?
Anyway, seems that my question was answered: There aren't any clever
technical ways to avoid censorship if validating nodes and mining pools
are centralized.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2013-03-10 8:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 11:00 Peter Todd
2013-03-07 11:34 ` Peter Todd
2013-03-07 17:42 ` Mike Hearn
2013-03-07 18:30 ` Peter Todd
2013-03-07 21:19 ` Mike Hearn
2013-03-07 21:31 ` Daniel Lidstrom
2013-03-10 8:18 ` Peter Todd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130310081857.GA2609@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=lidstrom83@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox