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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1WwZiq-0002YA-TW
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 16:25:28 +0000
X-ACL-Warn:
Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WwZip-0007v4-2p for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 16:25:28 +0000
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74])
by qmta05.westchester.pa.mail.comcast.net with comcast
id F2tk1o0021c6gX8554RMgk; Mon, 16 Jun 2014 16:25:21 +0000
Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f])
by omta23.westchester.pa.mail.comcast.net with comcast
id F4RL1o00a4VnV2P3j4RMha; Mon, 16 Jun 2014 16:25:21 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Odinn Cyberguerrilla <odinn.cyberguerrilla@riseup.net>
Date: Mon, 16 Jun 2014 12:25:20 -0400
Message-ID: <53959513.H7tOyQYvqT@crushinator>
User-Agent: KMail/4.13.1 (Linux/3.12.20-gentoo; KDE/4.13.1; x86_64; ; )
In-Reply-To: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>
References: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [76.96.62.48 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WwZip-0007v4-2p
Cc: 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: Mon, 16 Jun 2014 16:25:29 -0000
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
|
