"Unfortunately no design for fraud proofs which is both efficient and secure has been proposed”
Also to clarify, there’s no disagreement here, Patrick. > On Jun 27, 2015, at 10:32 PM, Eric Lombrozo <[email protected]> wrote: > > 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
