From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwxUs-0005IP-4o for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 17:48:38 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WwxUq-0006Bc-9O for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 17:48:38 +0000 Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id EE4BF5102F; Tue, 17 Jun 2014 10:47:53 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla@fruiteater.riseup.net) with ESMTPSA id 6E906D7F Received: from localhost (127.0.0.1) (SquirrelMail authenticated user odinn.cyberguerrilla) by fruiteater.riseup.net with HTTP; Tue, 17 Jun 2014 10:47:53 -0700 Message-ID: In-Reply-To: <539F59B0.5040601@gmail.com> References: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net> <1801389.9PVWAZniMG@crushinator> <1866054.ECx185lXld@crushinator> <422d16e8.kqhkiG.146a60d2382@gmail.com> <539F59B0.5040601@gmail.com> Date: Tue, 17 Jun 2014 10:47:53 -0700 From: "Odinn Cyberguerrilla" To: "Justus Ranvier" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.98.1 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.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 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 -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1WwxUq-0006Bc-9O Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes 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, 17 Jun 2014 17:48:38 -0000 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/16/2014 07:00 PM, Justus Ranvier wrote: >> There can be multiple independent transport networks for Bitcoin. >> >> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree >> patch). >> >> As long as multihomed hosts that act as bridges then information >> will propagate across all of them. -- Justus Ranvier >> ----------------- sent with R2Mail2 >> >> ----- Original Message ----- From: Matt Whitlock >> >>> Now another concern: won't this proposal increase the likelihood >>> of a network split? The free-market capitalist nodes will want to >>> charge their peers and will kick and ban peers that don't pay up >>> (and will pay their peers to avoid being kicked and banned >>> themselves), whereas the socialist nodes will want all of their >>> peers to feed them transactions out of the goodness of their >>> hearts and will thus necessarily be relegated to connecting only >>> to other altrustic peers. Thus, the network will comprise two >>> incompatible ideological camps, whose nodes won't interconnect. If the technical development emanating from the proposal follows a design which ensures that the notion of whether or not someone were to donate remains voluntary in nature (there's never any requirement that someone donate to anyone, but incentives can be made), then I don't feel that network split would be an issue, because it's just an issue of choice. Justus Ranvier suggested a system which would naturally include pay-to-play networks, and not just free P2P networks. The question of ho= w to limit the number of entries the system registers in the framework of the proposed 'decentralizing lottery' would be fairly straightforward, there could one entry for a distinct period of time (say 30 days as an example) for anyone who meets the suggested criteria of: "those running full nodes (Bitcoin Core (...)), processing their change and txouts through Core, would be provided incentives in the for= m of a 'decentralizing lottery' such that all participants who are runnin= g nodes and donating no matter how infrequently (and no matter who they donate to) will be entered in the 'decentralizing lottery,'" for a chance to receive "the 'award amounts'" In my mind I imagine that the smart property qualities of Bitcoin may eventually enable people to represent what sort of time and energy they are putting into maintaining the network, so that rather solely a currenc= y aspect, people who have done something collaborative with each other to help advance or develop Bitcoin would be able to show in their donations field that they have a smart property, which could be also expressed in equivalence terms as a value of a certain amount of btc, would also be able to have the smart property representing their voluntary efforts represented and given a voice in the blockchain, whether or not they want to participate in such a 'decentralizing lottery.' In point of fact, I contemplate that all aspects of this, at least ideally (to me) should be voluntary, such that if a person is donating through this system, that is voluntary, if they wish to have their donations result in a chance at winning the 'decentralizing lottery,' that is voluntary / an option, and if they win, they would have the option to accept the winnings or return them (the bitcoin 'award amount') back to the network. > > Also consider that currently there are many people have already > demonstrated a willingness to donate bandwidth and resources to the > public by running nodes, so those people aren't going to disappear. > Those who are already dedicated to running nodes will likely (mostly) remain, but any ideas reaching technical development and reality as a result of this concept would be intended to help grow that base by bringing in persons who might not otherwise be as interested to do so. > They could operate mixed-mode nodes, with a fraction of the allowed > incoming connections reserved for free peer, with free connections > might be limited in terms of time duration. Bitcoin-accepting > brick-and-mortars would probably allow free access to anyone connected > to their internal wifi to facilitate people wanting to pay. That's a great idea. The incentives could certainly go beyond just pointing to Bitcoin Core. Giving is important to everyone. > > Crowdfunded free bridges, assurance contracts, etc are all other ways > to let people get into the network with no upfront cost. > > > - -- > Support online privacy by using email encryption whenever possible. > Learn how here: http://www.youtube.com/watch?v=3DbakOKJFtB-k > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ > 197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj > JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok > o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ > Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpWMVbWHviYiZ7UufmzMgwPtfMCsQAxSb > q3OMAkcSGJZL8pcy9/9NWpOGAHY2DRtGtu8oSqXcBSW/IQCubmUNmzopt8O/H74=3D > =3D9hrW > -----END PGP SIGNATURE----- > -----------------------------------------------------------------------= ------- > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutio= ns > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems________________________________________= _______ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >