Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-17 📝 Original message:On Sat, Aug 15, 2015 at ...

📅 Original date posted:2015-08-17
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/40c39e66/attachment.sig>;