Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0858BA04 for ; Sun, 28 Jun 2015 05:48:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AE2DA7 for ; Sun, 28 Jun 2015 05:48:08 +0000 (UTC) Received: by paceq1 with SMTP id eq1so88455196pac.3 for ; Sat, 27 Jun 2015 22:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=g+5/3LkYogaWZ1egmTQtD853aTMUlGz7B+9tBrVHcqQ=; b=YZbwNvCX5eEYF6SKCB49NiCGBBBlvKvF7OedmwPLaRPyFXAn2F5M/KeHoFC+hr+qhf YN8yQHjKvkaeL087n+lRlWr/Kx4zqaNevotEO54Nq5C34E/9WIFKFJ/cudLkdzm9AXwA jEbFGFOGveL//8Sx78Vm1OZ9P8eC9ZY/ic8aj3SreU4/F/bEC3iZTg3WaDVFpnpWqXmO Q97m+rKZiuia9x5zvjRyTjcm1EVv3VT5Q3KkCN2Y5f2CALpwGjPc/kXWfFaB2/6nMV2W LCFuuSoQj9/sADy2+5I8cZHIVwxR/VL7h0+AMSJeJDMPbTVrSRcIJjKKXjxDHg6ojieh eEHA== X-Received: by 10.66.66.173 with SMTP id g13mr19620068pat.155.1435470488020; Sat, 27 Jun 2015 22:48:08 -0700 (PDT) Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by mx.google.com with ESMTPSA id bx8sm38380869pab.38.2015.06.27.22.48.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jun 2015 22:48:06 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_411358AC-CD11-4CFA-A76F-92C3841D810D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: <38C2E2A1-EB6C-48EB-8FA1-7FAA97B3E911@gmail.com> Date: Sat, 27 Jun 2015 22:48:04 -0700 Message-Id: <951AB6C2-D81E-48F1-8565-CA31D53AE19F@gmail.com> References: <1164261435450448@web14h.yandex.ru> <558F583C.1000500@gmail.com> <2A94BDF7-F265-4D36-B438-DC4F432E1C67@gmail.com> <558F8634.90904@gmail.com> <38C2E2A1-EB6C-48EB-8FA1-7FAA97B3E911@gmail.com> To: Patrick Strateman X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.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:48:09 -0000 --Apple-Mail=_411358AC-CD11-4CFA-A76F-92C3841D810D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 "Unfortunately no design for fraud proofs which is both efficient and secure has been proposed=E2=80=9D Also to clarify, there=E2=80=99s no disagreement here, Patrick. > On Jun 27, 2015, at 10:32 PM, Eric Lombrozo = wrote: >=20 > Just to clarify, SPV is fundamentally busted as it currently exists. = I=E2=80=99m talking about potential optimizations for future protocols. >=20 > - Eric Lombrozo >=20 >> On Jun 27, 2015, at 10:29 PM, Patrick Strateman = wrote: >>=20 >> Fraud proofs need to be at least more efficient than full node = validation. >>=20 >> Currently they are not. >>=20 >> 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. >>>=20 >>> 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=E2=80=99s a classical Nimzowischian = case of the threat being much stronger than the execution. >>>=20 >>> - Eric Lombrozo >>>=20 >>>> On Jun 27, 2015, at 7:13 PM, Patrick Strateman = wrote: >>>>=20 >>>>> 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. >>>>=20 >>>> Satoshi also believed that fraud proofs would be widely available = and >>>> practical. >>>>=20 >>>> If fraud proofs were practical SPV client security would be much = closer >>>> to full node security than it is today. >>>>=20 >>>> Unfortunately no design for fraud proofs which is both efficient = and >>>> secure has been proposed; much less implemented and deployed. >>>>=20 >>>> In building a system as new and innovative as bitcoin certain = things >>>> will be wrong. >>>>=20 >>>> The perception that SPV clients could be made nearly as secure as = full >>>> nodes is one example of something that was wrong. >>>>=20 >>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>=20 >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 --Apple-Mail=_411358AC-CD11-4CFA-A76F-92C3841D810D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVj4qUAAoJEJNAI64YFENUtM8P/i+XV5vbMLGSms7OcJpvc56E i+UKFRMz59OMR081s+ySNdYuYgepJauMWspHzlN2FpIZfhskSKtEI1JeRFEbV3sP huaLKxoVK2o8KR36avHJiLsRaMetoL5bnDSGuzmkM7KEva1605t/tXDPZuksUnB4 nqWML8QEar7z+/mNi9I4o5gg8rWxr7lBO9by6AsLXdUlixlelIIG0iHZkmn6P415 +76oknvYZZdnUhWOzZOXwQgnjM6OL2ZoNtMw2rXJwgMqBEtm6i5OugxXzzAp9kKZ PZ3YxDASI+xGhi6k/TuNfkEJDM0/76aL95j4kVeTLmIdrItv5xc3vnPHvhqapbyI DlO6ZYgwNiKYjd6e4R4siCMY80lhjl76RLv5c/bq3lnqmigeDKvKgtC2YQwDOHYn vLyBcE8PPQ6KMyhJk32nKcvjhCalVdQqDsQmrukGzcB+eS6vi8HU6IIKoTr/sQ8j GYZ1B3W3H+aGziAmPktjrBo4EJi/FAa+Lmj248XXVlaIWy8ASLd0yZXMN57txx5u /cyFhRn2ubapFoF+r1Wgl4LkAaoQUAkW1kJN2Ztt5ImTYchnHIjI1SYfFWw8hXDy X/Cnw9yO8sdIZfk3yqn2lEW69NdaY+iQUQ4ccVlNQ83mi+DHpsuczs1ea8+71xab kvrhcZwxwqoQWaijY5h1 =4qxX -----END PGP SIGNATURE----- --Apple-Mail=_411358AC-CD11-4CFA-A76F-92C3841D810D--