From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup•net>
To: "Justus Ranvier" <justusranvier@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
Date: Tue, 17 Jun 2014 10:47:53 -0700 [thread overview]
Message-ID: <e3efdac3aca49f6b942d7896aa46e73a.squirrel@fruiteater.riseup.net> (raw)
In-Reply-To: <539F59B0.5040601@gmail.com>
> -----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
>
prev parent reply other threads:[~2014-06-17 17:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 8:12 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 message]
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=e3efdac3aca49f6b942d7896aa46e73a.squirrel@fruiteater.riseup.net \
--to=odinn.cyberguerrilla@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=justusranvier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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