[bitcoin-dev] Fees and the block-finding process

Corey Haddad corey3 at gmail.com
Wed Aug 12 01:56:00 UTC 2015

On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev <

bitcoin-dev at lists.linuxfoundation.org

>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 actively
>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’s onslaught, to benefit from the protection of
the ‘credible threat’.

It’s important to accurately asses the level of threat the Bitcoin system
faces from regulation, legislation, and government ‘operations’.  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’s pretty safe to say 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

If there are security or network-hardening measures that don’t 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’s
potential growth.  How does this relate to the Blocksize debate?  Let’s
accept that 8 MB blocks might cause a little bit, and perhaps even a
‘medium bit’ (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’d wager the overall
security situation would be stronger, owning to greatly decreased risk of

-Corey (CubicEarth)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/41b60844/attachment.html>

More information about the bitcoin-dev mailing list