Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tfza2-0004gw-5q for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 20:59:02 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f47.google.com; Received: from mail-oa0-f47.google.com ([209.85.219.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tfza0-0004G9-Cx for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 20:59:02 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so4718395oag.34 for ; Tue, 04 Dec 2012 12:58:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.30.42 with SMTP id p10mr7453972oeh.59.1354654735072; Tue, 04 Dec 2012 12:58:55 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Tue, 4 Dec 2012 12:58:54 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 21:58:54 +0100 X-Google-Sender-Auth: p4-VlbtfBnDk5mt5yVarh2Jkew8 Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1Tfza0-0004G9-Cx Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 20:59:02 -0000 > 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.