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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
|
Return-Path: <benjamin.l.cordes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D82709B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 12:02:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com
[209.85.218.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 753941C7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 12:01:59 +0000 (UTC)
Received: by oihn130 with SMTP id n130so68415374oih.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Aug 2015 05:01:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=G94lWYnxM+cj2M4heBdDn3HIM/4tbCNTREH1nJGc2OU=;
b=RR0IS5sfoLVx6qLlsXXLKrO6scD+GXdtZ4iMw6DA/rSGrBDZYRjNpgfu5hzAbkQdb2
1IsaQfok88CKMgiJRbhF1E6DL2MOX9puqlGOCj92U/kdBkbzdrLdkloEdmCQ0CRlWRdz
YiWPbD5ITr9WqgGTKFi3oPld3au5bs6FmlGj0P4UITrJ9bgo58/TuWyYYQPWBxlBF2BJ
Lvtpi59xEJMhEPslYvlO/3+HWrhI/v0hoCnceO0hP7d+25Sf4oQT0zYSVa6mjD1FWEhb
O7yBF+rRDwR4gToRnos3odFYC/XdcFcXjkvN5ipBaCaRbIBT309wa9nb5yfAWv1KHP0E
eG+g==
MIME-Version: 1.0
X-Received: by 10.202.179.87 with SMTP id c84mr10886117oif.110.1439035318866;
Sat, 08 Aug 2015 05:01:58 -0700 (PDT)
Received: by 10.202.224.212 with HTTP; Sat, 8 Aug 2015 05:01:58 -0700 (PDT)
In-Reply-To: <55C5E31A.2090508@sky-ip.org>
References: <8185694.hShCHQnpze@coldstorage>
<CALqxMTHpXymxg6ATcMM3gm73gww5tznzNsY5quNbRpzsnxS53g@mail.gmail.com>
<20150808085451.4689995.38052.4163@thomaszander.se>
<CAOoPuRYk_R+kyfyrROcL8y9Bdfq7ufsyXSH_Uva2GPGcK_jwkA@mail.gmail.com>
<55C5E31A.2090508@sky-ip.org>
Date: Sat, 8 Aug 2015 14:01:58 +0200
Message-ID: <CAOoPuRbTtr1Mu1MtvJ_j0Gp9kt4O=dOLrUwgp82H-smAbwqrOg@mail.gmail.com>
From: Benjamin <benjamin.l.cordes@gmail.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=001a113cd1f4001ab4051ccb8556
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] trust
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: Sat, 08 Aug 2015 12:02:05 -0000
--001a113cd1f4001ab4051ccb8556
Content-Type: text/plain; charset=UTF-8
>> What is the problem that
you see in lightning model exactly?
How do you know who is who online? If Alice and Bob want to transact and
haven't exchanged keys before they need public-key infrastructure
out-of-band to identify themselves. Which means they are using SSL and
Certificate authorities and trust them. If you have non-cooperative hubs
they could flood the network and make it unusable. And why should hubs
cooperate? There are no incentives in the system.
On Sat, Aug 8, 2015 at 1:08 PM, s7r <s7r@sky-ip.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Interesting point of view Thomas! I agree that if we only think
> towards one single direction (treat trust as a super bad thing) we
> might miss some good features (or scalability levels) among the way.
>
> Benjamin:
> > Lightning assumes explicit trust and ID - much like Ripple. That's
> > not going to work, and I'm surprised that someone with basic
> > knowledge of crypto doesn't see this problem. Having explicit
> > counter-parties is something very different from Bitcoin where the
> > entity doing transactions verification is unknowable and changes
> > all the time.
>
> Can explain why exactly do you think this? What is the problem that
> you see in lightning model exactly? I am not arguing, maybe you are
> right and there is a part of the lightning network proposal which I
> missed, so that is why I am asking for clarification here.
>
> Lightning doesn't require explicit trust, worst case scenario you can
> end up with coins blocked until next in-chain broadcast. It depends on
> each and very hub, obviously there will also be trusted, identified
> public hubs but we can also have anonymous hubs.
>
> On 8/8/2015 12:24 PM, Benjamin via bitcoin-dev wrote:
> >>> The point was NOT to trust no-one, the point was to trust
> >>> everyone, but keep everyone honest by keeping the ledger open
> >>> and publicly available.
> >
> > Trust takes many different forms and is not a binary function. You
> > trust a surgeon to do an operation and a pilot to fly a jet, but
> > not vice versa. To trust someone explicitly, you need to know who
> > they are. Most social structures work without explicit identity and
> > they still function quite well. For example companies are mostly
> > anonymous to the consumer - if you buy something in a shop you
> > trust a chain of people producing that good. A priori there is
> > little reason to trust others, but rather that trust is already
> > developed through social institutions. Money is one such
> > institution with specific trust problems, and the history of money
> > is indeed a very good way to study these problems. Unfortunately in
> > Bitcoin development such insights are rare to find.
> >
> > Lightning assumes explicit trust and ID - much like Ripple. That's
> > not going to work, and I'm surprised that someone with basic
> > knowledge of crypto doesn't see this problem. Having explicit
> > counter-parties is something very different from Bitcoin where the
> > entity doing transactions verification is unknowable and changes
> > all the time. Users of Bitcoin trust nodes doing the verification
> > because they know it is in their best interest to be honest.
> > Neither Sidechains nor LT have preserve that important property,
> > and so IMO there are no good proposals to make Bitcoin scale (if
> > that is possible at all).
> >
> > On Sat, Aug 8, 2015 at 10:54 AM, Thomas Zander via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > I didn't say off-chain, and gave an example of on-chain usecase
> > with trusted middleman.
> >
> > So, no, that's not what I meant.
> >
> > Sent on the go, excuse the brevity. Original Message From: Adam
> > Back Sent: Saturday, 8 August 2015 09:50 To: Thomas Zander Cc:
> > Bitcoin Dev Subject: Re: [bitcoin-dev] trust
> >
> > If you are saying that some people are happy trusting other
> > people, and so would be perfectly fine with off-chain use of
> > Bitcoin, then we agree and I already said that off-chain use case
> > would be a constructive thing for someone to improve scale and
> > interoperability of in the post you are replying to. However that
> > use case is not a strong argument for weakening Bitcoin's security
> > to get to more scale for that use case.
> >
> > In a world where we could have scale and decentralisation, then of
> > course it would be nice to provide people with that outlook more
> > security than they seem to want. And sometimes people dont
> > understand why security is useful until it goes wrong, so it would
> > be a useful thing to do. (Like insurance, your money being seized
> > by paypal out of the blue etc). And indeed providing security at
> > scale maybe possible with lightning like protocols that people are
> > working on.
> >
> > Adam
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBCAAGBQJVxeMaAAoJEIN/pSyBJlsRJFoH/RbgArUMJStQwF92XZk99dUd
> 0xI/VU1goFLDFiFVkrea7uNWUrWw0GM9nDq0kTIV+mTi9rTYgWKlgA1XZnPusr35
> GpDhXxoG3mJmay9AX1fezrZjGmCZPCjSnPWa+BeQCSMXnVchZX0U4XZSwgD7qTIU
> 7o4r5JIDuGxXyPcwECnB7ePmZ8xA2QGQaMW6nnMhlA4KCanSd5/78kcpUp/kGAJ1
> chjhV2g7tAeq3NMs2IXeIMiEAqji0B7RRAejviBg9CAwbpo4dP3dRz8hv/qPx6K0
> Mu6jHczCQOUyAHagwG8q4+laMbkskVETw18NwluspOZi3inxvVpOD60CDqSZPS4=
> =ogMZ
> -----END PGP SIGNATURE-----
>
--001a113cd1f4001ab4051ccb8556
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>>=C2=A0=C2=A0What is the problem that<br>you see in=
lightning model exactly?<div><br></div><div>How do you know who is who onl=
ine? If Alice and Bob want to transact and haven't exchanged keys befor=
e they need public-key infrastructure out-of-band to identify themselves. W=
hich means they are using SSL and Certificate authorities and trust them. I=
f you have non-cooperative hubs they could flood the network and make it un=
usable. And why should hubs cooperate? There are no incentives in the syste=
m.</div><div><div class=3D"gmail_extra">=C2=A0=C2=A0<br><div class=3D"gmail=
_quote">On Sat, Aug 8, 2015 at 1:08 PM, s7r <span dir=3D"ltr"><<a href=
=3D"mailto:s7r@sky-ip.org" target=3D"_blank">s7r@sky-ip.org</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----=
<br>
Hash: SHA256<br>
<br>
Interesting point of view Thomas! I agree that if we only think<br>
towards one single direction (treat trust as a super bad thing) we<br>
might miss some good features (or scalability levels) among the way.<br>
<br>
Benjamin:<br>
<span class=3D"">> Lightning assumes explicit trust and ID - much like R=
ipple. That's<br>
> not going to work, and I'm surprised that someone with basic<br>
> knowledge of crypto doesn't see this problem. Having explicit<br>
> counter-parties is something very different from Bitcoin where the<br>
> entity doing transactions verification is unknowable and changes<br>
> all the time.<br>
<br>
</span>Can explain why exactly do you think this? What is the problem that<=
br>
you see in lightning model exactly? I am not arguing, maybe you are<br>
right and there is a part of the lightning network proposal which I<br>
missed, so that is why I am asking for clarification here.<br>
<br>
Lightning doesn't require explicit trust, worst case scenario you can<b=
r>
end up with coins blocked until next in-chain broadcast. It depends on<br>
each and very hub, obviously there will also be trusted, identified<br>
public hubs but we can also have anonymous hubs.<br>
<div><div class=3D"h5"><br>
On 8/8/2015 12:24 PM, Benjamin via bitcoin-dev wrote:<br>
>>> The point was NOT to trust no-one, the point was to trust<br>
>>> everyone, but keep everyone honest by keeping the ledger open<=
br>
>>> and publicly available.<br>
><br>
> Trust takes many different forms and is not a binary function. You<br>
> trust a surgeon to do an operation and a pilot to fly a jet, but<br>
> not vice versa. To trust someone explicitly, you need to know who<br>
> they are. Most social structures work without explicit identity and<br=
>
> they still function quite well. For example companies are mostly<br>
> anonymous to the consumer - if you buy something in a shop you<br>
> trust a chain of people producing that good. A priori there is<br>
> little reason to trust others, but rather that trust is already<br>
> developed through social institutions. Money is one such<br>
> institution with specific trust problems, and the history of money<br>
> is indeed a very good way to study these problems. Unfortunately in<br=
>
> Bitcoin development such insights are rare to find.<br>
><br>
> Lightning assumes explicit trust and ID - much like Ripple. That's=
<br>
> not going to work, and I'm surprised that someone with basic<br>
> knowledge of crypto doesn't see this problem. Having explicit<br>
> counter-parties is something very different from Bitcoin where the<br>
> entity doing transactions verification is unknowable and changes<br>
> all the time. Users of Bitcoin trust nodes doing the verification<br>
> because they know it is in their best interest to be honest.<br>
> Neither Sidechains nor LT have preserve that important property,<br>
> and so IMO there are no good proposals to make Bitcoin scale (if<br>
> that is possible at all).<br>
><br>
> On Sat, Aug 8, 2015 at 10:54 AM, Thomas Zander via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
</div></div><span class=3D"">> <mailto:<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>>>=
; wrote:<br>
><br>
> I didn't say off-chain, and gave an example of on-chain usecase<br=
>
> with trusted middleman.<br>
><br>
> So, no, that's not what I meant.<br>
><br>
> Sent on the go, excuse the brevity. Original Message From: Adam<br>
> Back Sent: Saturday, 8 August 2015 09:50 To: Thomas Zander Cc:<br>
> Bitcoin Dev Subject: Re: [bitcoin-dev] trust<br>
><br>
> If you are saying that some people are happy trusting other<br>
> people, and so would be perfectly fine with off-chain use of<br>
> Bitcoin, then we agree and I already said that off-chain use case<br>
> would be a constructive thing for someone to improve scale and<br>
> interoperability of in the post you are replying to. However that<br>
> use case is not a strong argument for weakening Bitcoin's security=
<br>
> to get to more scale for that use case.<br>
><br>
> In a world where we could have scale and decentralisation, then of<br>
> course it would be nice to provide people with that outlook more<br>
> security than they seem to want. And sometimes people dont<br>
> understand why security is useful until it goes wrong, so it would<br>
> be a useful thing to do. (Like insurance, your money being seized<br>
> by paypal out of the blue etc). And indeed providing security at<br>
> scale maybe possible with lightning like protocols that people are<br>
> working on.<br>
><br>
> Adam<br>
</span>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
<br>
iQEcBAEBCAAGBQJVxeMaAAoJEIN/pSyBJlsRJFoH/RbgArUMJStQwF92XZk99dUd<br>
0xI/VU1goFLDFiFVkrea7uNWUrWw0GM9nDq0kTIV+mTi9rTYgWKlgA1XZnPusr35<br>
GpDhXxoG3mJmay9AX1fezrZjGmCZPCjSnPWa+BeQCSMXnVchZX0U4XZSwgD7qTIU<br>
7o4r5JIDuGxXyPcwECnB7ePmZ8xA2QGQaMW6nnMhlA4KCanSd5/78kcpUp/kGAJ1<br>
chjhV2g7tAeq3NMs2IXeIMiEAqji0B7RRAejviBg9CAwbpo4dP3dRz8hv/qPx6K0<br>
Mu6jHczCQOUyAHagwG8q4+laMbkskVETw18NwluspOZi3inxvVpOD60CDqSZPS4=3D<br>
=3DogMZ<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div></div>
--001a113cd1f4001ab4051ccb8556--
|
