Re: [bitcoin-dev] Incentives to run full nodes

From: odinn <odinn.cyberguerrilla@riseup•net>
To: Chris Pacia <ctpacia@gmail•com>, Peter Todd <pete@petertodd•org>,
	 justusranvier@riseup•net, gmaxwell@gmail•com
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Incentives to run full nodes
Date: Sun, 04 Oct 2015 06:46:07 +0000	[thread overview]
Message-ID: <5610CB2F.90002@riseup.net> (raw)
In-Reply-To: <55D4124B.6070700@riseup.net>

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