1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
Return-Path: <patrick.strateman@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DF5B1273
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 05:29:26 +0000 (UTC)
Received: by pdjn11 with SMTP id n11so97805497pdj.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>
(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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
|
