From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DF5B1273 for ; Sun, 28 Jun 2015 05:29:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E8DFFD for ; Sun, 28 Jun 2015 05:29:26 +0000 (UTC) Received: by pdjn11 with SMTP id n11so97805497pdj.0 for ; Sat, 27 Jun 2015 22:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hHWYfrDHrtQcU0uYJ47HksBBzfShsBbLj3S9ypQX5KM=; b=xYcqEfdReeEK6gKA7mWMfnny9EhemwVG2f9NvRW4TaFUJr00sWnB1AIJE2oHZzRBzq oAr/MH8hX8IFYryZbWhtThr/xOym4xSxht6C7cMaIqzVJHmKd+fnjA8vLyOH/sCWduu2 0BDwdSAcho9Fh2zHqNTnsAQW31tFyZr8a+1yshR86KKUZr966w69KCtaECQQS/V0CKhT zkXffHeQ0FbU8DvtzqIOjwnWNBf2XwzxxtJ9WQM4X/0YElTPR2S5DK9jMvVmSSS6Jxr4 G+/1Q0MTl5QG/l/DGG273s+hd3RM8HtAg5nzpxw3YPt00p5PRVQg5PBb1DMI3U8j8FOA uB4g== X-Received: by 10.70.20.196 with SMTP id p4mr19325663pde.58.1435469366090; Sat, 27 Jun 2015 22:29:26 -0700 (PDT) Received: from [10.45.134.9] (c-24-5-81-164.hsd1.ca.comcast.net. [24.5.81.164]) by mx.google.com with ESMTPSA id qt4sm37993403pbc.86.2015.06.27.22.29.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2015 22:29:25 -0700 (PDT) Message-ID: <558F8634.90904@gmail.com> Date: Sat, 27 Jun 2015 22:29:24 -0700 From: Patrick Strateman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 CC: bitcoin-dev@lists.linuxfoundation.org References: <1164261435450448@web14h.yandex.ru> <558F583C.1000500@gmail.com> <2A94BDF7-F265-4D36-B438-DC4F432E1C67@gmail.com> In-Reply-To: <2A94BDF7-F265-4D36-B438-DC4F432E1C67@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Original Vision X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 05:29:27 -0000 Fraud proofs need to be at least more efficient than full node validation= =2E Currently they are not. On 06/27/2015 09:54 PM, Eric Lombrozo wrote: > Fraud proofs actually don=E2=80=99t need to be made super efficient=E2=80= =A6but they do need to be secure, of course. > > The trick is aligning incentives. In order for fraud proofs to be widel= y 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 act= ually practical is that very few of these fraud proofs ever need to actua= lly be executed - it=E2=80=99s a classical Nimzowischian case of the thre= at being much stronger than the execution. > > - Eric Lombrozo > >> On Jun 27, 2015, at 7:13 PM, Patrick Strateman 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 th= e >> 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 close= r >> 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 v= ery stressful but I'd like to point out that it is really amazing how pas= sionately so many feel about this once very small project. Let's not forg= et 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, IM= O. It's about the nature of Bitcoin and what it means to people and how i= t 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 fr= om this person. This is not to say their original vision is paramount-- o= r even that I got it completely correct but I think it might do us some g= ood to think about. >>> >>> It seems as though the incentive conceived of for running a full netw= ork node was that it would enable mining. The proceeds from mining (new c= oins and transaction fees) would be the reward and provide a reason to co= ntinue 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 s= o please excuse me if I have marginalized you. If you do contest that I w= ould be interested in hearing it. >>> >>> Further, it appears clear that the original author intended organizat= ions operating full network nodes would provide connectivity to light cli= ents and these light clients would make up the majority of the user base.= This is completely consistent with current trends in Internet consumptio= n, e.g. tablets and phones are becoming more preferred to even owning a t= raditional computer. Having the system be entirely decentralized and trus= tless for every client does not appear to me to be the original design go= al. Yes, the whitepaper speaks of the design goal as not having a need fo= r 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 im= plies some amount of localized trust is perhaps a necessary trade-off and= maybe businesses should still run their own full network node if they wa= nt 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 eviden= ce 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 doe= s 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 t= his hasn't been too off-topic and distracting. The original author's engi= neering ingenuity is what gave me any interest in this project so re-visi= ting their design and scaling intentions might be helpful for us to move = forward-- together. >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev