Message-ID: <558F8634.90904@gmail.com>
Date: Sat, 27 Jun 2015 22:29:24 -0700
From: Patrick Strateman <patrick.strateman@gmail.com>
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
Subject: Re: [bitcoin-dev] Original Vision
Precedence: list

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 <patrick.strateman@gmai=
l.com> 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