From: Peter Todd <pete@petertodd•org>
To: satoshi@vistomail•com
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Incentives to run full nodes
Date: Mon, 17 Aug 2015 14:29:12 -0700 [thread overview]
Message-ID: <20150817212912.GA15817@muck> (raw)
In-Reply-To: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04>
[-- Attachment #1: Type: text/plain, Size: 3864 bytes --]
On Sat, Aug 15, 2015 at 12:43:54PM -0500, Satoshi Nakamoto via bitcoin-dev wrote:
> They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
Re: full nodes, my thinking along those lines has been:
1) Incentivising full-nodes is a red herring
We can look at this from multiple angles. 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)
From the point of view of full node or miner, having your peers be
valiating nodes is at best just a bandwidth optimization; all you need
from the rest of the P2P network is flood-fill capability with
reasonable DoS resistance. This isn't a problem that strongly requires
validation, and if bandwidth needs started to get excessive, sharding
the flood-fill network to limit bandwidth of any one flood-fill peer
would be relatively easy.
2) The best incentive to validate is clear and immediate failure when you don't
Currently the game theory and attacks possible against non-validating
nodes is a very complex landscape, full of cases where small attacks are
infeasible, but larger attacks possible. In particular, in many cases
you have co-ordination problems, where an attack is only viable if you
can steal at least a block reward worth of Bitcoins to make up for your
opportunity cost. This risks lulling people into complacency as attacks
seem rare, even if the risk is still quite high as the few attacks that
will happen will be very high impact.
If the system as a whole made small-scale attacks easier, we wouldn't
see this complacency, and people would build stronger systems. A
concrete example is Gregory Maxwell's idea of having all blocks commit
to two separate merkle trees, one valid and one invalid. Determining
which was which would require active validation, and because the block
as a whole is still valid regardless, this gives the opportunity to run
constant "fire drills" to uncover flaws in validation. Notable, this
scheme would even be compatible with SPV clients provided that all
sources of invalidity can be proven with a compact fraud proof.
A more extreme version of this notion is my embedded consensus ideas,
where you rely on the PoW for only proof-of-publication and/or
anti-replay functionality. Determining if coins (or any other asset) are
real becomes a clear job of validating history yourself, and/or trusting
others to do that validation. For instance, my smartcolors colored-coin
protocol work implemented client-side validation of colored coins, with
a planned (but not fully implemented - client ran out of funds)
optimization/trust tradeoff of having the issuer periodically sign
merkle-trees committing to all valid proofs within the system on an
offline machine.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-08-17 21:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-15 17:43 [bitcoin-dev] Bitcoin XT Fork Satoshi Nakamoto
2015-08-15 19:08 ` Laszlo Hanyecz
2015-08-15 19:10 ` jl2012
2015-08-17 11:40 ` Oliver Egginger
2015-08-17 11:44 ` Jorge Timón
2015-08-17 11:51 ` Oliver Egginger
2015-08-17 16:32 ` Jorge Timón
2015-08-17 17:01 ` Oliver Egginger
2015-08-17 17:15 ` Jorge Timón
2015-08-17 17:30 ` Btc Drak
2015-08-17 17:18 ` Gregory Maxwell
2015-08-17 19:14 ` Peter Todd
2015-08-17 17:28 ` Jeff Garzik
2015-08-17 19:03 ` Warren Togami Jr.
2015-08-17 20:37 ` Oliver Egginger
2015-08-18 5:16 ` Gregory Maxwell
2015-08-18 9:15 ` Warren Togami Jr.
2015-08-18 11:52 ` Micha Bailey
2015-08-18 18:57 ` Oliver Egginger
2015-08-18 20:59 ` Anon Moto
2015-08-19 1:03 ` Sergio Demian Lerner
2015-08-17 19:02 ` Anon Moto
2015-08-17 19:40 ` Marcel Jamin
2015-08-17 19:16 ` Hector Chu
2015-08-17 19:28 ` Gregory Maxwell
2015-08-17 19:39 ` Jorge Timón
2015-08-17 21:29 ` Peter Todd [this message]
2015-08-17 21:44 ` [bitcoin-dev] Incentives to run full nodes Chris Pacia
2015-08-18 0:20 ` Joseph Poon
2015-08-19 5:21 ` odinn
2015-10-04 6:46 ` odinn
2015-10-04 6:59 ` odinn
2015-08-19 2:54 ` [bitcoin-dev] Bitcoin XT Fork odinn
2015-08-19 2:59 ` Angel Leon
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=20150817212912.GA15817@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=satoshi@vistomail$(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