summaryrefslogtreecommitdiff
path: root/07/361a5ccf22cf3e0553c603f6ce2261c331fb35
blob: e923601183148cac17bafc2e3fbc39c1c9fcb10d (plain)
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
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 31D781915
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  4 Oct 2015 06:46:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E856F100
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  4 Oct 2015 06:46:27 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.162])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.riseup.net",
	Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.riseup.net (Postfix) with ESMTPS id 6517EC1460;
	Sat,  3 Oct 2015 23:46:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1443941187; bh=V6wOwydyPAeU5SXcwSI5VCuBjLRAtyV9gNeIulWgGt8=;
	h=Date:From:To:CC:Subject:References:In-Reply-To:From;
	b=Re4up7L0Vt8nnFqGWNm2zPQZEwtOYpFP0W8D2oEYPdTtOHGRf8IU0TJUg3t6Vxdm6
	FKUKD4JdTaMudpw7ZqreRI/3eNblpgW+8SRje/Mx4Ao8tGAMpJMKfNkeEw+UhY+Dtw
	YcG3Yg1aXVCSKUVIS0By5OaWosxUoq+t99Af2Vc0=
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla)
	with ESMTPSA id B4ABF1416FD
Message-ID: <5610CB2F.90002@riseup.net>
Date: Sun, 04 Oct 2015 06:46:07 +0000
From: odinn <odinn.cyberguerrilla@riseup.net>
MIME-Version: 1.0
To: Chris Pacia <ctpacia@gmail.com>, Peter Todd <pete@petertodd.org>, 
	justusranvier@riseup.net, gmaxwell@gmail.com
References: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04>	<20150817212912.GA15817@muck>
	<CAB+qUq79BgiTGFS1yLxxogg8907jCUtNDmBhnikLWc1fqofNyg@mail.gmail.com>
	<55D4124B.6070700@riseup.net>
In-Reply-To: <55D4124B.6070700@riseup.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD,
	UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Incentives to run full nodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2015 06:46:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

Some background on this....


A very long while ago I posted to the bitcoin-development mailing list
some ABIS concepts having to do with microdonations:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/00
3791.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004
049.html

And an interesting post (which led me to explore BCN) via nullc:
https://news.ycombinator.com/item?id=7765455
(posted 1 & 1/3 year ago).


Anyway, some long while ago this discussion came up about "Incentives
to run full nodes," and the last post in the thread was here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006083
.html

Since that time, some new developments have come to light which the
participants in that thread may find interesting;

Please see in part,

https://bytecoin.org/news/bytecoin-wallet-1.0.8-release-introduces-micro
- -donations/

This presents a working implementation in BCN; the concept as
implemented there is arguably viable in BTC as well.

Please explore, play with, discuss, etc.

Cheers,

- - O

odinn:
> Potentially relevant...
> 
> "Incentivizing the running of full nodes"
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060
28
>
> 
.html
> 
> (However, the issue to which I referred here is now closed)
> 
> View whole thread:
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thre
ad
>
> 
.html#6028
> 
> On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
> 
>> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" 
>> <bitcoin-dev@lists.linuxfoundation.org 
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: From the 
>> point of view of a
>>> wallet, it's not very secure to use Hearn-style SPV mode, and 
>>> volunteers running full nodes doesn't help things. Sybil 
>>> attacking the IP address space is pretty easy in comparison to 
>>> aquiring hashing power sufficient to create false
>>> confirmations, so any attacker able to do the former will
>>> likely be running the full node you're connecting too anyway.
>>> Ultimately, Hearn-style SPV is a close approximation to just
>>> trusting anyone with a non-trivial amount of hashing power.
>>> (and getting that is surprisingly easy, e.g. w/ SPV mining)
> 
>> Can you explain how the spv node fails against an attacker with a
>>  non-trivial amount of hash power where a full node doesn't? To 
>> attack an spv wallet that is waiting for 6 or 10 confirmations,
>> you would not only need to Sybil them but also summon a massive
>> amount of hashing power to create a chain of headers (while
>> forgoing the opportunity to mine valid blocks with that hash
>> power).
> 
>> But could someone with that much hash power not Sybil a full
>> node and give them a chain for valid blocks (but on an orphan
>> fork)? The failure model doesn't seem specific to spv to me.
> 
> 
> 
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWEMsvAAoJEGxwq/inSG8CcU8IAMJ+ZYMFzjETUDEZNyUnVd3v
SJCNauufTOcqxLzQoGIj4Y66PDnk9doRy/KJUGhKNtg4vjxiEk+GGHRH02ktvnQB
6MGuDCJS+MLeGi2W2QMr1NdHl09kRo306F5ZgjtZnOqX0mhwhOrIUylpoevcBnSQ
maJ5hpmxqyhxozEyYyu50HwcMQrXeWKZ8G0VSkTqmY5wf0s98MGrFLWSujwsva0e
p4hvG6YgBH85ne7dnBSH/sySreJpRMA0aac/+1j9U3LVvMTsmuaPc71aGI791o/y
+KV+UZ8bgHldfi+NSK8wA4eRi4JQrt+ruE63XlfYl29gWINqsGeVtpW/W3jeDnI=
=KDER
-----END PGP SIGNATURE-----