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