[bitcoin-dev] trust

Benjamin benjamin.l.cordes at gmail.com
Sat Aug 8 12:01:58 UTC 2015


>>  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 at 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 at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/5696b441/attachment.html>


More information about the bitcoin-dev mailing list