Date: Mon, 17 Aug 2015 14:29:12 -0700
From: Peter Todd <pete@petertodd.org>
To: satoshi@vistomail.com
Message-ID: <20150817212912.GA15817@muck>
References: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Incentives to run full nodes
Precedence: list


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 t=
o be.  However I acknowledge that a lot has changed since that time, and ne=
w knowledge has been gained that contradicts some of my early opinions.  Fo=
r example I didn't anticipate pooled mining and its effects on the security=
 of the network.  Making Bitcoin a competitive monetary system while also p=
reserving its security properties is not a trivial problem, and we should t=
ake more time to come up with a robust solution.  I suspect we need a bette=
r 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)

=46rom 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
=66rom 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 d=
on'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.

--=20
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJV0lIlXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi
ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzuCwf/YJfiE0SXdXJWttJMBcZ71XJq
TOTouzvIpTu8NXPn5v9XUFFvL1OC0g510tVvbb+KDc38LjSWVdMaVsqouMgtcIAj
oomhaNjlr0jIu4eRmg9ZWyxtQcmDr6mlpb/gJ98o3TTIc4fzsWM3xAdNC8HmaNpN
s98XSheKEOWkkazW6k/QZ7zaQCd27d1877kPloOJ3a8gdfPPk4OZnpxBWEaaapaH
1Z/Z60Jq816LUXtPXRouc9G9PQ038O2vvkBSG162uEGfbuErXYIeSDPUru8bFBpG
K5Oh1KrVrU7m8MSD1wGkiSk4wrrw7INarJCU9km12aVd+EAPwsUTMD8a52daww==
=Ws7X
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--