[Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Odinn Cyberguerrilla
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Mike Hearn
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.cyberguerri...@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

--
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
How can there be any kind of lottery that doesn't involve proof of work or 
proof of stake? Without some resource-limiting factor, there is no way to limit 
the number of lottery tickets any given individual could acquire. The very 
process of Bitcoin mining was invented specifically to overcome the Sybil 
problem, which had plagued computer scientists for decades, and now you're 
proposing a system that suffers from the same problem. Or am I wrong about this?


On Monday, 16 June 2014, at 1:12 am, Odinn Cyberguerrilla 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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/16/2014 04:25 PM, Matt Whitlock wrote:
 How can there be any kind of lottery that doesn't involve proof of
 work or proof of stake? Without some resource-limiting factor,
 there is no way to limit the number of lottery tickets any given
 individual could acquire. The very process of Bitcoin mining was
 invented specifically to overcome the Sybil problem, which had
 plagued computer scientists for decades, and now you're proposing a
 system that suffers from the same problem. Or am I wrong about
 this?

If you allow the solution set to include pay-to-play networks, and not
just free P2P networks, then it's easier to find a solution

Imagine every node is competing with its peers in terms of relevancy.
Relevancy is established by delivering newly-seen transactions first.

Each node keeps track of which of its peers send it transactions that
it hadn't seen and forwarded to them yet (making sure that the
transactions do make it into a block) and uses that information to
determine whether or not it should be paying that peer, or if that
peer should be paying it, or if they are equal relevancy and no net
payment is required.

Once any given pair of nodes can establish who, if anyone, should be
paying they could use micropayment channels to handle payments.

Nodes that are well connected, and with high uptimes would end up
being net recipients of payments. Mobile nodes and other low-uptime
nodes would be net payers.

Now that you've established a market for the service of delivering
transaction information, you can rely on price signals to properly
match supply and demand.

People who hate market-based solutions could always run these nodes
and configure them to refuse to pay anyone, and to charge nothing to
their peers, if that's what they wanted.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJTnyRMAAoJEMP3uyY4RQ21XwgH/RPlhgR63XF9/Sm+z0EBxVtO
0hzDngD0iTO1v5LRmas9P5ZuQ97j8169pui+EJO8clXjV41yEu96jc0BiOQTnfMR
rzPfgeZqfnVNDvIfJnLRMeVCJMiu9Tjdqx83S28Tz9sx/sgy1uw9INX7M7wOIHFR
7GLA16k4g8qcmnX89XXM3Uf7/3fhL2kiN/E59V2n6qYJAnYTUEb+uehclzR+T4v4
93oAF3TjgLU6J0VleDrvgFcyLriGBjOmkTAvmOJQF1H/s4gzHol5kbOb9vqQ7BJX
QQ/mEYHEdCHTxU59FdZ5CmFYZrINHj+mNnu1RorYYF1FLbBDTDpq4zjrJpngayI=
=9qQJ
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
On Monday, 16 June 2014, at 5:07 pm, Justus Ranvier wrote:
 On 06/16/2014 04:25 PM, Matt Whitlock wrote:
  How can there be any kind of lottery that doesn't involve proof of
  work or proof of stake? Without some resource-limiting factor,
  there is no way to limit the number of lottery tickets any given
  individual could acquire. The very process of Bitcoin mining was
  invented specifically to overcome the Sybil problem, which had
  plagued computer scientists for decades, and now you're proposing a
  system that suffers from the same problem. Or am I wrong about
  this?
 
 If you allow the solution set to include pay-to-play networks, and not
 just free P2P networks, then it's easier to find a solution
 
 Imagine every node is competing with its peers in terms of relevancy.
 Relevancy is established by delivering newly-seen transactions first.
 
 Each node keeps track of which of its peers send it transactions that
 it hadn't seen and forwarded to them yet (making sure that the
 transactions do make it into a block) and uses that information to
 determine whether or not it should be paying that peer, or if that
 peer should be paying it, or if they are equal relevancy and no net
 payment is required.
 
 Once any given pair of nodes can establish who, if anyone, should be
 paying they could use micropayment channels to handle payments.
 
 Nodes that are well connected, and with high uptimes would end up
 being net recipients of payments. Mobile nodes and other low-uptime
 nodes would be net payers.
 
 Now that you've established a market for the service of delivering
 transaction information, you can rely on price signals to properly
 match supply and demand.
 
 People who hate market-based solutions could always run these nodes
 and configure them to refuse to pay anyone, and to charge nothing to
 their peers, if that's what they wanted.

This is a cool idea, but doesn't it generate some perverse incentives? If I'm 
running a full node and I want to pay CheapAir for some plane tickets, I'll 
want to pay in the greatest number of individual transactions possible, to 
maximize the rewards that I'll receive from my connected peers. This maybe 
would not be a problem if transaction fees were required on all transactions, 
but as it is (e.g., while fee-free transactions can be accepted into blocks if 
they have high enough priority), I can preload my wallet with hundreds of 
small-ish outputs, let them sit there for a few months to accumulate coin age, 
and then spend each little piece in a separate transaction when it comes time 
to pay for a big-ticket purchase. It's more lucrative for me to pay for my 
plane ticket in 100 separate, low-value transactions than in one high-value 
transaction. So you're incentivizing greater consumption of bandwidth and 
storage.

--
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Mike Hearn

 This is a cool idea, but doesn't it generate some perverse incentives? If
 I'm running a full node and I want to pay CheapAir for some plane tickets,
 I'll want to pay in the greatest number of individual transactions possible


Peers can calculate rewards based on number of inputs or total kb used:
you're paying for kilobytes with either coin age or fees no matter what. So
I think in practice it's not a big deal.
--
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Matt Whitlock
On Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote:
 
  This is a cool idea, but doesn't it generate some perverse incentives? If
  I'm running a full node and I want to pay CheapAir for some plane tickets,
  I'll want to pay in the greatest number of individual transactions possible
 
 Peers can calculate rewards based on number of inputs or total kb used:
 you're paying for kilobytes with either coin age or fees no matter what. So
 I think in practice it's not a big deal.

So effectively, if you pay for your bandwidth/storage usage via fees, then the 
reward system is constrained by proof of burn, and if you pay for your usage 
via coin age, then the reward system is constrained by proof of stake.

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.

--
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
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 b...@mattwhitlock.name
Sent: 2014/06/16 - 13:10
To: Mike Hearn m...@plan99.net, Justus Ranvier justusranv...@gmail.com
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes

 On Monday, 16 June 2014, at 7:59 pm, Mike Hearn wrote:
 
  This is a cool idea, but doesn't it generate some perverse incentives? If
  I'm running a full node and I want to pay CheapAir for some plane tickets,
  I'll want to pay in the greatest number of individual transactions possible

 Peers can calculate rewards based on number of inputs or total kb used:
 you're paying for kilobytes with either coin age or fees no matter what. So
 I think in practice it's not a big deal.

 So effectively, if you pay for your bandwidth/storage usage via fees, then 
 the reward system is constrained by proof of burn, and if you pay for your 
 usage via coin age, then the reward system is constrained by proof of stake.

 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.




signature.asc
Description: PGP/MIME digital signature
--
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


Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
-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
 b...@mattwhitlock.name
 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.

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.

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.

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=bakOKJFtB-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=
=9hrW
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
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