summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authors7r <s7r@sky-ip.org>2015-08-08 14:08:10 +0300
committerbitcoindev <bitcoindev@gnusha.org>2015-08-08 11:08:38 +0000
commite4203ddb5e2110092ce2db2026a55026bace01e6 (patch)
treec6260b35028317049e7ffb3ded55be59457632bb
parentf20149ac7d387570777ad44bc635065e4719a1ad (diff)
downloadpi-bitcoindev-e4203ddb5e2110092ce2db2026a55026bace01e6.tar.gz
pi-bitcoindev-e4203ddb5e2110092ce2db2026a55026bace01e6.zip
Re: [bitcoin-dev] trust
-rw-r--r--32/53ac7006bd26bc1d504d6617b8be3cd33cef75181
1 files changed, 181 insertions, 0 deletions
diff --git a/32/53ac7006bd26bc1d504d6617b8be3cd33cef75 b/32/53ac7006bd26bc1d504d6617b8be3cd33cef75
new file mode 100644
index 000000000..3da00bbfe
--- /dev/null
+++ b/32/53ac7006bd26bc1d504d6617b8be3cd33cef75
@@ -0,0 +1,181 @@
+Return-Path: <s7r@sky-ip.org>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 3168788B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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 <bitcoin-dev@lists.linuxfoundation.org>;
+ 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>
+ <CALqxMTHpXymxg6ATcMM3gm73gww5tznzNsY5quNbRpzsnxS53g@mail.gmail.com>
+ <20150808085451.4689995.38052.4163@thomaszander.se>
+ <CAOoPuRYk_R+kyfyrROcL8y9Bdfq7ufsyXSH_Uva2GPGcK_jwkA@mail.gmail.com>
+To: Benjamin <benjamin.l.cordes@gmail.com>,
+ Thomas Zander <thomas@thomaszander.se>
+From: s7r <s7r@sky-ip.org>
+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: <CAOoPuRYk_R+kyfyrROcL8y9Bdfq7ufsyXSH_Uva2GPGcK_jwkA@mail.gmail.com>
+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 <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 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
+> <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-----
+