From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3168788B for ; Sat, 8 Aug 2015 11:08:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B5ABB132 for ; Sat, 8 Aug 2015 11:08:29 +0000 (UTC) Received: from [0.0.0.0] (herngaard.torservers.net [96.44.189.102]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id CED71783F55; Sat, 8 Aug 2015 11:08:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org; s=20110108; t=1439032105; bh=oUMpoY8cYFuKYLQb7GLT4gbYsq6lKgkkKbmZX5Ln314=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=AybogaYOjBQVXxygAobDA+kNh03oq5Ev1+/qFTtMj4EwOvG3rZaToGxy2mX+haMIq dgp1h16H9JZewhmB/hQiMz4eW256Bi84Y3jMdhFlf6ZnI/zGIx9lqqIQZB/iWWthOA sgQabT5vuEtIHsq/ixl/D1hjZG2URd9sA/H1X0Aw= Reply-To: s7r@sky-ip.org References: <8185694.hShCHQnpze@coldstorage> <20150808085451.4689995.38052.4163@thomaszander.se> To: Benjamin , Thomas Zander From: s7r X-Enigmail-Draft-Status: N1110 Message-ID: <55C5E31A.2090508@sky-ip.org> Date: Sat, 8 Aug 2015 14:08:10 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CTCH-RefID: str=0001.0A020205.55C5E329.003B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: s7r@sky-ip.org X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=YL9iskyx c=1 sm=1 tr=0 a=IN0GVkDZBMvuYpVMTZ7cxw==:117 a=IN0GVkDZBMvuYpVMTZ7cxw==:17 a=ZDnEzkWgAAAA:8 a=-NIMs_s3AAAA:8 a=bvjBBkZ6AAAA:8 a=JAI3OqB5mnwA:10 a=N659UExz7-8A:10 a=ag1SF4gXAAAA:8 a=lp1u85yg6TwYw-ONSqYA:9 a=LhxNC8mYXSY5lHdF:21 a=CAAzJie5eRfQ1b5z:21 a=pILNOxqGKmIA:10 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 11:08:38 -0000 -----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-----