* [Bitcoin-development] Incentivizing the running of full nodes @ 2014-06-16 8:12 Odinn Cyberguerrilla 2014-06-16 11:35 ` Mike Hearn 2014-06-16 16:25 ` Matt Whitlock 0 siblings, 2 replies; 10+ messages in thread From: Odinn Cyberguerrilla @ 2014-06-16 8:12 UTC (permalink / raw) To: Bitcoin-development 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 8:12 [Bitcoin-development] Incentivizing the running of full nodes Odinn Cyberguerrilla @ 2014-06-16 11:35 ` Mike Hearn 2014-06-16 16:25 ` Matt Whitlock 1 sibling, 0 replies; 10+ messages in thread From: Mike Hearn @ 2014-06-16 11:35 UTC (permalink / raw) To: Odinn Cyberguerrilla; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 8:12 [Bitcoin-development] Incentivizing the running of full nodes Odinn Cyberguerrilla 2014-06-16 11:35 ` Mike Hearn @ 2014-06-16 16:25 ` Matt Whitlock 2014-06-16 17:07 ` Justus Ranvier 1 sibling, 1 reply; 10+ messages in thread From: Matt Whitlock @ 2014-06-16 16:25 UTC (permalink / raw) To: Odinn Cyberguerrilla; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 16:25 ` Matt Whitlock @ 2014-06-16 17:07 ` Justus Ranvier 2014-06-16 17:26 ` Matt Whitlock 0 siblings, 1 reply; 10+ messages in thread From: Justus Ranvier @ 2014-06-16 17:07 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2460 bytes --] -----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----- [-- Attachment #2: 0x38450DB5.asc --] [-- Type: application/pgp-keys, Size: 12659 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 17:07 ` Justus Ranvier @ 2014-06-16 17:26 ` Matt Whitlock 2014-06-16 17:59 ` Mike Hearn 0 siblings, 1 reply; 10+ messages in thread From: Matt Whitlock @ 2014-06-16 17:26 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 17:26 ` Matt Whitlock @ 2014-06-16 17:59 ` Mike Hearn 2014-06-16 18:10 ` Matt Whitlock 0 siblings, 1 reply; 10+ messages in thread From: Mike Hearn @ 2014-06-16 17:59 UTC (permalink / raw) To: Matt Whitlock; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 424 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 662 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 17:59 ` Mike Hearn @ 2014-06-16 18:10 ` Matt Whitlock 2014-06-16 19:00 ` Justus Ranvier 0 siblings, 1 reply; 10+ messages in thread From: Matt Whitlock @ 2014-06-16 18:10 UTC (permalink / raw) To: Mike Hearn, Justus Ranvier; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 18:10 ` Matt Whitlock @ 2014-06-16 19:00 ` Justus Ranvier 2014-06-16 20:55 ` Justus Ranvier 0 siblings, 1 reply; 10+ messages in thread From: Justus Ranvier @ 2014-06-16 19:00 UTC (permalink / raw) To: Matt Whitlock, Justus Ranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1885 bytes --] 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 <bip@mattwhitlock•name> Sent: 2014/06/16 - 13:10 To: Mike Hearn <mike@plan99•net>, Justus Ranvier <justusranvier@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. [-- Attachment #2: PGP/MIME digital signature --] [-- Type: application/pgp-signature, Size: 532 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 19:00 ` Justus Ranvier @ 2014-06-16 20:55 ` Justus Ranvier 2014-06-17 17:47 ` Odinn Cyberguerrilla 0 siblings, 1 reply; 10+ messages in thread From: Justus Ranvier @ 2014-06-16 20:55 UTC (permalink / raw) To: Matt Whitlock; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2364 bytes --] -----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 > <bip@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----- [-- Attachment #2: 0x38450DB5.asc --] [-- Type: application/pgp-keys, Size: 12659 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Incentivizing the running of full nodes 2014-06-16 20:55 ` Justus Ranvier @ 2014-06-17 17:47 ` Odinn Cyberguerrilla 0 siblings, 0 replies; 10+ messages in thread From: Odinn Cyberguerrilla @ 2014-06-17 17:47 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev > -----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 >> <bip@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. 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 how 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 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,'" 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 currency 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=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----- > ------------------------------------------------------------------------------ > 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-06-17 17:48 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-16 8:12 [Bitcoin-development] Incentivizing the running of full nodes Odinn Cyberguerrilla 2014-06-16 11:35 ` Mike Hearn 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox