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
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
