Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D82709B for ; 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 ; Sat, 8 Aug 2015 12:01:59 +0000 (UTC) Received: by oihn130 with SMTP id n130so68415374oih.2 for ; 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> <20150808085451.4689995.38052.4163@thomaszander.se> <55C5E31A.2090508@sky-ip.org> Date: Sat, 8 Aug 2015 14:01:58 +0200 Message-ID: From: Benjamin 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > > > > 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
>>=C2=A0=C2=A0What is the problem that
you see in= lightning model exactly?

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.
=C2=A0=C2=A0
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 R= ipple. 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<= br> 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<= br> >>> 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-d= ev@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=3D
=3DogMZ
-----END PGP SIGNATURE-----

--001a113cd1f4001ab4051ccb8556--