1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <odinn.cyberguerrilla@riseup.net>) id 1WwxUs-0005IP-4o
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 17:48:38 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129;
envelope-from=odinn.cyberguerrilla@riseup.net;
helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WwxUq-0006Bc-9O
for bitcoin-development@lists.sourceforge.net;
Tue, 17 Jun 2014 17:48:38 +0000
Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "Gandi Standard SSL CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id EE4BF5102F;
Tue, 17 Jun 2014 10:47:53 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla@fruiteater.riseup.net)
with ESMTPSA id 6E906D7F
Received: from localhost (127.0.0.1)
(SquirrelMail authenticated user odinn.cyberguerrilla)
by fruiteater.riseup.net with HTTP; Tue, 17 Jun 2014 10:47:53 -0700
Message-ID: <e3efdac3aca49f6b942d7896aa46e73a.squirrel@fruiteater.riseup.net>
In-Reply-To: <539F59B0.5040601@gmail.com>
References: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>
<1801389.9PVWAZniMG@crushinator>
<CANEZrP0eNDuGnm1vESwoe=9HWUKZGQ5CKsDZ8SHsQxCaNEjRsA@mail.gmail.com>
<1866054.ECx185lXld@crushinator>
<422d16e8.kqhkiG.146a60d2382@gmail.com> <539F59B0.5040601@gmail.com>
Date: Tue, 17 Jun 2014 10:47:53 -0700
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Justus Ranvier" <justusranvier@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.98.1 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.5 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
X-Headers-End: 1WwxUq-0006Bc-9O
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 17:48:38 -0000
> -----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 ho=
w
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 for=
m
of a 'decentralizing lottery' such that all participants who are runnin=
g
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 currenc=
y
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=3DbakOKJFtB-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=3D
> =3D9hrW
> -----END PGP SIGNATURE-----
> -----------------------------------------------------------------------=
-------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutio=
ns
> 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
>
|
