From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
Date: Tue, 4 Dec 2012 21:58:54 +0100 [thread overview]
Message-ID: <CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com>
> It sounds to me that you're insisting that you're asking people who
> oppose degrading our recommendations to commit to a costly rushed
> development timeline. I think this is a false choice.
Hardly. I don't have any particular timeline in mind. But I disagree
we have "forever". New ideas have a certain time window to take off
and become credible. If they never overcome their problems in that
time window, eventually people just give up and move on. Does anyone
take desktop Linux seriously anymore? No. "The year of desktop Linux"
is a joke. People took it seriously in 2001 but despite great progress
since, the excitement and attention has gone. There were steady
improvements over the last 10 years but nobody is creating desktop
Linux startups anymore - Bitcoin shouldn't go the same way.
It's unclear we need to have every man and his dog run a full node.
Tor is a successful P2P network where the number of users vastly
outstrips the number of nodes, and exit nodes in particular are a
scarce resource run by people who know what they're doing and commit
to it.
The Tor guys could have said "every node should be an exit if
possible", but that would have been a short term optimization at the
cost of long term stability, and anyway doesn't seem to have been
necessary so far. Even with no incentives, they were able to obtain
the resources they need.
So why should Bitcoin be different? If there are a million users
supported by 50,000 full nodes, that wouldn't sound unhealthy to me.
We can easily send a clear and consistent "this is important, please
help" message without complicated auto-upgrade/downgrade schemes that
risk annoying users.
next prev parent reply other threads:[~2012-12-04 20:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 17:46 Mike Hearn
2012-12-04 18:03 ` Alan Reiner
2012-12-04 18:08 ` Will
2012-12-04 18:17 ` Gregory Maxwell
2012-12-04 20:58 ` Mike Hearn [this message]
2012-12-04 21:41 ` Gregory Maxwell
2012-12-04 22:44 ` Alan Reiner
2012-12-05 0:27 ` Gregory Maxwell
2012-12-05 2:08 ` Alan Reiner
2012-12-05 2:54 ` Gregory Maxwell
2012-12-05 5:38 ` Jim Nguyen
2012-12-05 7:50 ` Wladimir
2012-12-05 9:43 ` Gary Rowe
2012-12-05 10:19 ` Robert Backhaus
2012-12-05 10:43 ` Mike Hearn
2012-12-04 18:57 ` Mark Friedenbach
2012-12-04 19:36 ` Gregory Maxwell
[not found] <mailman.70419.1354648162.2176.bitcoin-development@lists.sourceforge.net>
2012-12-04 19:56 ` Jim
2012-12-04 22:23 ` slush
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=CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@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