From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwVCT-0006AU-3C for Bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 11:35:45 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.41 as permitted sender) client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f41.google.com; Received: from mail-oa0-f41.google.com ([209.85.219.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwVCR-0000AU-7j for Bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 11:35:45 +0000 Received: by mail-oa0-f41.google.com with SMTP id l6so5674497oag.14 for ; Mon, 16 Jun 2014 04:35:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.115.199 with SMTP id jq7mr1676101obb.70.1402918533131; Mon, 16 Jun 2014 04:35:33 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 04:35:33 -0700 (PDT) In-Reply-To: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net> References: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net> Date: Mon, 16 Jun 2014 13:35:33 +0200 X-Google-Sender-Auth: is1AYvajKoqmZ4y3nET4Wmmvy5o Message-ID: From: Mike Hearn To: Odinn Cyberguerrilla Content-Type: multipart/alternative; boundary=047d7b678120d0f7a004fbf26ceb X-Spam-Score: -0.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 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WwVCR-0000AU-7j 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: Mon, 16 Jun 2014 11:35:45 -0000 --047d7b678120d0f7a004fbf26ceb Content-Type: text/plain; charset=UTF-8 Hi Odinn, I think trying to incentivise nodes with money is tricky: it makes intuitive sense but right now the market is flooded with supply relative to demand. Yes, we worry about the falling number of nodes, but that's for reasons that aren't really economic: the more nodes we have, the bigger and more grassroots the project seems to the outside world, plus the cheaper it gets for everyone as the biggest cost (chain upload bandwidth) is spread over multiple people. Also there's research showing that when you have people volunteering, introducing money can ruin the motivation of the volunteers, so the transition to a pay-for-node-services world could be quite painful and difficult. Right now rather than microdonations to all nodes, IMO the lowest hanging fruit is to move chain upload onto specialised "archival nodes" which can potentially charge for their services. I prototyped this here https://github.com/mikehearn/PayFile but never finished it. On Mon, Jun 16, 2014 at 10:12 AM, Odinn Cyberguerrilla < odinn.cyberguerrilla@riseup.net> wrote: > I have been noticing for some time the problem which Mike H. identified as > how we are bleeding nodes ~ losing nodes over time. > > This link was referenced in the coindesk article of May 9, 2014: > > > http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx5pg%40mail.gmail.com/#msg32196023 > > (coindesk article for reference: > http://www.coindesk.com/bitcoin-nodes-need/) > > The proposed solution is noted here as a portion of an issue at: > https://github.com/bitcoin/bitcoin/issues/4079 > > Essentially that part which has to do with helping reduce > the loss of nodes is as follows: > > "a feature similar to that suggested by @gmaxwell that would process small > change and tiny txouts to user specified donation targets, in an > incentivized process. Those running full nodes (Bitcoin Core all the > time), processing their change and txouts through Core, would be provided > incentives in the form of a 'decentralizing lottery' such that all > participants who are running nodes and donating no matter how infrequently > (and no matter who they donate to) will be entered in the 'decentralizing > lottery,' the 'award amounts' (which would be distinct from 'block > rewards' for any mining) would vary from small to large bitcoin amounts > depending on how many participants are involved in the donations process. > This would help incentivize individuals to run full nodes as well as > encouraging giving and microdonations. The option could be expressed in > the transactions area to contribute to help bitcoin core development for > those that are setting up change and txouts for donations, regarding the > microdonation portion (which has also has been expressed conceptually at > abis.io" > > This addresses the issue of how to incentivize more > interested individuals to run full nodes (Bitcoin Core). The lottery > concept (which would be applicable to anyone running the full node > regardless of whether or not they are mining) is attractive from the point > of view that it will complement the block reward concept already in place > which serves those who mine, but more attractive to the individual who > doesn't feel the urge to mine, but would like to have the chance of being > compensated for the effort they put into the system. > > I hope that this leads to additional development discussion on these > concepts regarding incentivizing giving. This may also involve a process > BIP. I look forward to your remarks. > > Respect, > > Odinn > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > 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 > --047d7b678120d0f7a004fbf26ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Odinn,

I think trying to incentivise nodes with mon= ey is tricky: it makes intuitive sense but right now the market is flooded = with supply relative to demand. Yes, we worry about the falling number of n= odes, but that's for reasons that aren't really economic: the more = nodes we have, the bigger and more grassroots the project seems to the outs= ide world, plus the cheaper it gets for everyone as the biggest cost (chain= upload bandwidth) is spread over multiple people.

<= /div>
Also there&= #39;s research showing that when you have people volunteering, introducing = money can ruin the motivation of the volunteers, so the transition to a pay= -for-node-services world could be quite painful and difficult.

Right now rather than = microdonations to all nodes, IMO the lowest hanging fruit is to move chain = upload onto specialised "archival nodes" which can potentially ch= arge for their services. I prototyped this here


=
but never finish= ed it.


On Mon, Jun 16, 2014 at 10:12 AM, Odinn Cyberguerrilla &l= t;odin= n.cyberguerrilla@riseup.net> wrote:
I have been noticing for some time the problem which Mike H. identified as<= br> how we are bleeding nodes ~ losing nodes over time.

This link was referenced in the coindesk article of May 9, 2014:

http://sourceforge.net/p/bitcoin/mailman/bi= tcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx= 5pg%40mail.gmail.com/#msg32196023

(coindesk article for reference: http://www.coindesk.com/bitcoin-nodes-need/= )

The proposed solution is noted here as a portion of an issue at:
=C2=A0https://github.com/bitcoin/bitcoin/issues/4079

Essentially that part which has to do with helping reduce
the loss of nodes is as follows:

"a feature similar to that suggested by @gmaxwell that would process s= mall
change and tiny txouts to user specified donation targets, in an
incentivized process. Those running full nodes (Bitcoin Core all the
time), processing their change and txouts through Core, would be provided incentives in the form of a 'decentralizing lottery' such that all<= br> participants who are running nodes and donating no matter how infrequently<= br> (and no matter who they donate to) will be entered in the 'decentralizi= ng
lottery,' the 'award amounts' (which would be distinct from = 9;block
rewards' for any mining) would vary from small to large bitcoin amounts=
depending on how many participants are involved in the donations process. This would help incentivize individuals to run full nodes as well as
encouraging giving and microdonations. The option could be expressed in
the transactions area to contribute to help bitcoin core development for those that are setting up change and txouts for donations, regarding the microdonation portion (which has also has been expressed conceptually at abis.io"

This addresses the issue of how to incentivize more
interested individuals to run full nodes (Bitcoin Core). =C2=A0The lottery<= br> concept (which would be applicable to anyone running the full node
regardless of whether or not they are mining) is attractive from the point<= br> of view that it will complement the block reward concept already in place which serves those who mine, but more attractive to the individual who
doesn't feel the urge to mine, but would like to have the chance of bei= ng
compensated for the effort they put into the system.

I hope that this leads to additional development discussion on these
concepts regarding incentivizing giving. This may also involve a process BIP. =C2=A0I look forward to your remarks.

Respect,

Odinn


---------------------------------------------------------------------------= ---
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions 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.n= et/sfu/hpccsystems
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--047d7b678120d0f7a004fbf26ceb--