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
From: Eric Lombrozo <elombrozo@gmail.com>
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 <patrick.strateman@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Original Vision
Precedence: list


--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 <elombrozo@gmail.com> =
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 =
<patrick.strateman@gmail.com> 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 =
<patrick.strateman@gmail.com> 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--