Just to clarify, SPV is fundamentally busted as it currently exists. I’m talking about potential optimizations for future protocols.
- Eric Lombrozo > On Jun 27, 2015, at 10:29 PM, Patrick Strateman <[email protected]> > wrote: > > Fraud proofs need to be at least more efficient than full node validation. > > Currently they are not. > > On 06/27/2015 09:54 PM, Eric Lombrozo wrote: >> Fraud proofs actually don’t need to be made super efficient…but they do need >> to be secure, of course. >> >> The trick is aligning incentives. In order for fraud proofs to be widely >> available there needs to be a market for them - there must be a way to buy >> one (because producing one is not free). What makes such a scheme actually >> practical is that very few of these fraud proofs ever need to actually be >> executed - it’s a classical Nimzowischian case of the threat being much >> stronger than the execution. >> >> - Eric Lombrozo >> >>> On Jun 27, 2015, at 7:13 PM, Patrick Strateman >>> <[email protected]> wrote: >>> >>>> Further, it appears clear that the original author intended >>> organizations operating full network nodes would provide connectivity to >>> light clients and these light clients would make up the majority of the >>> user base. >>> >>> Satoshi also believed that fraud proofs would be widely available and >>> practical. >>> >>> If fraud proofs were practical SPV client security would be much closer >>> to full node security than it is today. >>> >>> Unfortunately no design for fraud proofs which is both efficient and >>> secure has been proposed; much less implemented and deployed. >>> >>> In building a system as new and innovative as bitcoin certain things >>> will be wrong. >>> >>> The perception that SPV clients could be made nearly as secure as full >>> nodes is one example of something that was wrong. >>> >>> On 06/27/2015 05:14 PM, Santino Napolitano wrote: >>>> There is much heated debate going on right now and I know it can be very >>>> stressful but I'd like to point out that it is really amazing how >>>> passionately so many feel about this once very small project. Let's not >>>> forget there is something really special going on here and we're all part >>>> of it. >>>> >>>> The current debate has little to do with block size or hard-forks, IMO. >>>> It's about the nature of Bitcoin and what it means to people and how it >>>> will grow. I would like to take a moment to share my interpretation of the >>>> original author's intent based on everything I could find and read from >>>> this person. This is not to say their original vision is paramount-- or >>>> even that I got it completely correct but I think it might do us some good >>>> to think about. >>>> >>>> It seems as though the incentive conceived of for running a full network >>>> node was that it would enable mining. The proceeds from mining (new coins >>>> and transaction fees) would be the reward and provide a reason to continue >>>> operating these nodes. If fees are ever to be a sufficient reward and >>>> still allow for a practical and useful system the size of the blocks must >>>> grow significantly as must the user base. I'm not sure that this is really >>>> contested but I haven't exhaustively reviewed everyone's opinion so please >>>> excuse me if I have marginalized you. If you do contest that I would be >>>> interested in hearing it. >>>> >>>> Further, it appears clear that the original author intended organizations >>>> operating full network nodes would provide connectivity to light clients >>>> and these light clients would make up the majority of the user base. This >>>> is completely consistent with current trends in Internet consumption, e.g. >>>> tablets and phones are becoming more preferred to even owning a >>>> traditional computer. Having the system be entirely decentralized and >>>> trustless for every client does not appear to me to be the original design >>>> goal. Yes, the whitepaper speaks of the design goal as not having a need >>>> for a trusted third party but it does not say that some amount of trust >>>> won't be preferred by a majority of users. In fact, in the SPV section it >>>> implies some amount of localized trust is perhaps a necessary trade-off >>>> and maybe businesses should still run their own full network node if they >>>> want the stronger completely trustless guarantee. The global decentralized >>>> consensus appears meant to make the network >>> r >>>> esilient to a single government or other adversary's ability to shut the >>>> network down. If you really want to trust no one it is your option at a >>>> cost and should be possible by design. The author further gives evidence >>>> that they believe Moore's observation would keep the idea of running a >>>> full network node a practical one at global scale for perpetuity. It does >>>> not appear as if they intended for every individual to run one at home nor >>>> in their pocket. >>>> >>>> If my interpretation seems incorrect please do point it out. I hope this >>>> hasn't been too off-topic and distracting. The original author's >>>> engineering ingenuity is what gave me any interest in this project so >>>> re-visiting their design and scaling intentions might be helpful for us to >>>> move forward-- together. >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> [email protected] >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> [email protected] >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
