public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Odinn Cyberguerrilla <odinn.cyberguerrilla@riseup.net>
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
Date: Mon, 16 Jun 2014 13:35:33 +0200	[thread overview]
Message-ID: <CANEZrP0zsV1FZ4=+OUv7pJ09c3rbw_uuWRh+00E4EkfbXTjMxw@mail.gmail.com> (raw)
In-Reply-To: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>

[-- Attachment #1: Type: text/plain, Size: 4192 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6058 bytes --]

  reply	other threads:[~2014-06-16 11:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-16  8:12 [Bitcoin-development] Incentivizing the running of full nodes Odinn Cyberguerrilla
2014-06-16 11:35 ` Mike Hearn [this message]
2014-06-16 16:25 ` Matt Whitlock
2014-06-16 17:07   ` Justus Ranvier
2014-06-16 17:26     ` Matt Whitlock
2014-06-16 17:59       ` Mike Hearn
2014-06-16 18:10         ` Matt Whitlock
2014-06-16 19:00           ` Justus Ranvier
2014-06-16 20:55             ` Justus Ranvier
2014-06-17 17:47               ` Odinn Cyberguerrilla

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='CANEZrP0zsV1FZ4=+OUv7pJ09c3rbw_uuWRh+00E4EkfbXTjMxw@mail.gmail.com' \
    --to=mike@plan99.net \
    --cc=Bitcoin-development@lists.sourceforge.net \
    --cc=odinn.cyberguerrilla@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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