From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4jQO-0000xT-Nl for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 05:28:40 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=justusranvier@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z4jQN-0007fR-9B for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 05:28:40 +0000 Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 2ED2242C74; Tue, 16 Jun 2015 05:28:32 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: justusranvier) with ESMTPSA id C1216401FC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 16 Jun 2015 05:28:32 +0000 From: justusranvier@riseup.net To: Kevin Greene In-Reply-To: References: <201506160341.10994.luke@dashjr.org> Message-ID: X-Sender: justusranvier@riseup.net User-Agent: Riseup mail X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.0 (--) 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1Z4jQN-0007fR-9B Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] The Bitcoin Node Market 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, 16 Jun 2015 05:28:40 -0000 On 2015-06-16 03:49, Kevin Greene wrote: > =E2=80=8BHah, fair enough, there is no such thing as the "right" way to= do > anything. But I still think punishing users who use SPV wallets is =E2=80= =8Ba > less-than-ideal way to incentive people to run full nodes. Right now=20 > SPV is > the best way that exists for mobile phones to participate in the=20 > network in > a decentralized way. This proposal makes the user experience for mobile > wallets a little more confusing and annoying. Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who=20 would provide the nodes they would need connect to? The decentralization=20 fairy? There's absolutely no reason that paying for connectivity would be any=20 more confusing or annoying than transaction fees are. If some full nodes in the network started offering paid connection=20 slots, that would just mean that users who checked the "pay subscription=20 fee" box in their wallet configuration would have an easier time=20 connecting than the users who did't, just like how your transaction=20 might eventually get mined without a fee but paying one makes it faster=20 and more probable.