From: Corey Haddad <corey3@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Fees and the block-finding process
Date: Tue, 11 Aug 2015 18:56:00 -0700 [thread overview]
Message-ID: <CAK_HAC9T391=uDHr+37R3NOrJEy=SSBzna1qXF2bO9+8nbcTQA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]
On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>
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 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
list.
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
attack.
-Corey (CubicEarth)
[-- Attachment #2: Type: text/html, Size: 5023 bytes --]
next reply other threads:[~2015-08-12 1:56 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 1:56 Corey Haddad [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-08-07 14:57 [bitcoin-dev] Fees and the block-finding process Gavin Andresen
2015-08-07 15:16 ` Pieter Wuille
2015-08-07 15:55 ` Gavin Andresen
2015-08-07 16:28 ` Pieter Wuille
2015-08-07 17:47 ` Ryan Butler
2015-08-07 18:25 ` Mark Friedenbach
2015-08-07 18:57 ` Ryan Butler
2015-08-07 19:07 ` Ryan Butler
2015-08-07 19:15 ` Mark Friedenbach
2015-08-07 20:17 ` Ryan Butler
2015-08-07 20:33 ` Dave Hudson
2015-08-07 18:17 ` jl2012
2015-08-07 18:35 ` Bryan Bishop
2015-08-07 18:36 ` Simon Liu
2015-08-11 23:20 ` Elliot Olds
2015-08-07 17:33 ` Jorge Timón
2015-08-07 22:12 ` Thomas Zander
2015-08-07 23:06 ` Adam Back
2015-08-08 22:45 ` Dave Scotese
2015-08-08 23:05 ` Alex Morcos
2015-08-09 5:52 ` Hector Chu
2015-08-09 10:32 ` Thomas Zander
2015-08-09 10:42 ` Thomas Zander
2015-08-09 20:43 ` Dave Scotese
2015-08-11 17:03 ` Jorge Timón
2015-08-10 11:55 ` Jorge Timón
2015-08-10 12:33 ` Btc Drak
2015-08-10 13:03 ` Jorge Timón
2015-08-10 22:13 ` Thomas Zander
2015-08-11 17:47 ` Jorge Timón
2015-08-11 18:46 ` Michael Naber
2015-08-11 18:48 ` Mark Friedenbach
2015-08-11 18:55 ` Michael Naber
2015-08-11 19:45 ` Jorge Timón
2015-08-11 21:31 ` Michael Naber
2015-08-11 18:51 ` Bryan Bishop
2015-08-11 18:59 ` Michael Naber
2015-08-11 19:27 ` Jorge Timón
2015-08-11 19:37 ` Michael Naber
2015-08-11 19:51 ` Pieter Wuille
2015-08-11 21:18 ` Michael Naber
2015-08-11 21:23 ` Adam Back
2015-08-11 21:30 ` Angel Leon
2015-08-11 21:32 ` Pieter Wuille
2015-08-11 21:34 ` Adam Back
2015-08-11 21:39 ` Michael Naber
2015-08-12 6:10 ` Venzen Khaosan
2015-08-11 22:06 ` Angel Leon
2015-08-11 21:35 ` Michael Naber
2015-08-11 21:51 ` Pieter Wuille
2015-08-12 3:35 ` Elliot Olds
2015-08-12 4:47 ` Venzen Khaosan
2015-08-14 21:47 ` Elliot Olds
2015-08-12 0:56 ` Tom Harding
2015-08-12 1:18 ` Eric Voskuil
2015-08-12 8:10 ` Thomas Zander
2015-08-12 9:00 ` Jorge Timón
2015-08-12 9:25 ` Thomas Zander
2015-08-11 19:53 ` Jorge Timón
2015-08-11 20:56 ` Michael Naber
2015-08-12 7:54 ` Thomas Zander
2015-08-12 8:01 ` Thomas Zander
[not found] ` <1679272.aDpruqxXDP@coldstorage>
2015-08-12 8:51 ` Jorge Timón
2015-08-12 9:23 ` Thomas Zander
2015-08-12 9:45 ` Jorge Timón
2015-08-12 16:24 ` Thomas Zander
2015-08-17 14:49 ` BitMinter operator
2015-08-17 15:01 ` Peter Todd
2015-08-10 14:12 ` Gavin Andresen
2015-08-10 14:24 ` Alex Morcos
2015-08-10 22:12 ` Thomas Zander
2015-08-10 14:34 ` Pieter Wuille
2015-08-10 22:04 ` Thomas Zander
2015-08-20 14:40 ` Will Madden
2015-08-10 14:55 ` Jorge Timón
2015-08-10 22:09 ` Thomas Zander
2015-08-10 22:52 ` Pieter Wuille
2015-08-10 23:11 ` Pieter Wuille
2015-08-11 5:34 ` Thomas Zander
2015-08-11 6:03 ` Mark Friedenbach
2015-08-11 6:31 ` Thomas Zander
2015-08-11 7:08 ` Mark Friedenbach
2015-08-11 8:38 ` Thomas Zander
2015-08-11 9:14 ` Angel Leon
2015-08-11 19:00 ` Mark Friedenbach
2015-08-11 19:26 ` Michael Naber
2015-08-11 20:12 ` Adam Back
2015-08-12 0:32 ` odinn
2015-08-11 11:10 ` Thomas Zander
2015-08-12 0:18 ` odinn
2015-08-07 21:30 ` Jim Phillips
2015-08-07 18:22 ` Anthony Towns
2015-08-07 18:36 ` Peter R
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='CAK_HAC9T391=uDHr+37R3NOrJEy=SSBzna1qXF2bO9+8nbcTQA@mail.gmail.com' \
--to=corey3@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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