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 9367F826 for ; Mon, 10 Aug 2015 21:43:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from manxnetsf05.manx.net (outbound.manx.net [213.137.31.12]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9283717D for ; Mon, 10 Aug 2015 21:43:49 +0000 (UTC) Received: from adsl92.39.203.140.manx.net (EHLO coldstorage.localnet) ([92.39.203.140]) by manxnetsf05.manx.net (MOS 4.4.5a-GA FastPath queued) with ESMTP id EGD50733; Mon, 10 Aug 2015 22:43:47 +0100 (BST) From: Thomas Zander To: Bitcoin Dev Date: Mon, 10 Aug 2015 23:43:46 +0200 Message-ID: <2674312.GqtxTJeqiO@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <8185694.hShCHQnpze@coldstorage> <1725491.c810VbMBxP@coldstorage> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Mirapoint-Received-SPF: 92.39.203.140 coldstorage.localnet thomas@thomaszander.se 5 none X-Junkmail-Status: score=10/50, host=manxnetsf05.manx.net X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.55C91B13.00E2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.55C91B13.00E2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 24dfd6aff0edc0402cf1b89e428cb32e X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 21:43:50 -0000 On Monday 10. August 2015 22.17.52 Jorge Tim=F3n wrote: > But I don't see how that is relevant, allowing trust to be involved i= n > different ways is a feature, but it's optional. Agreed. > I think the point "you don't need to trust anyone to use Bitcoin" rem= ains. yes, and thats fine. The argument that Adam was making was the other extreme; that Bitcoin w= as=20 useless the moment he has to trust any 3rd party. And that is why I started this thread, because that idea that Bitcoin l= ooses=20 its functionality when you deviate from the trust-no-one path, is destr= uctive. For instance I suggested a week ago that the Chinese firewall (blocksiz= e=20 propagation) problem could maybe be solved by having a chinese miner pa= rtially=20 trust some full nodes on Internet hubs. For instance in Amsterdam, one = in=20 Stockholm, etc. And then propagation of a newly mined block would make the miner only s= ent the=20 header to this server where a full x-MB block is then created by some=20= specialized software that bases it on the mempool of its bitcoind. Propagation of a Chinese miner then suddenly doesn't care about blocksi= ze when=20 hopping over the chinese firewall. You'd only send a small amount of da= ta,=20 likely around 20Kb for even 8Mb blocks. A critic would argue its a useless strategy because you'd have to trust= the=20 data center operators. I'd argue that its a risk, for sure, but one that can be mitigated easi= ly by=20 having various datacenters around the world where you'd run your softwa= re so=20 you'd be able to check the validity of each. Risks can only be assessed fairly if people are less black/white in the= ir=20 thinking. I love that about Bitcoin, it combines technical specialized thinking w= ith=20 Economics and planning. If you don't have both, you probably end up rej= ecting=20 the best ideas. > Adam, I think he means a multisig escrow transaction where the escrow= > is trusted by both parties, and other examples like that. Yes, thats one example. Thanks Jorge! A similar but relevant example would be like the M-Pesa example. People that have a phone but not a smart phone can choose to have their= =20 private keys stored at a trusted company in their own country. Some pay= ments=20 can be off-chain, but as soon as you deal with people outside of this s= mall=20 community they would be on-chain. When we are talking about remittances, this means one of the two partie= s does=20 not have an account at the trusted party and as such this will be an on= -chain=20 transaction. Same for a farmer in Nairobi buying equipment from a company in Cairo, = or a=20 Internet startup in Kampala/Uganda selling services to users in Europe = and=20 those users send their payments on-chain. All of these examples are about the largest group of people in the worl= d; the=20 unbanked. Bitcoin could mean a huge change to these people and I care a= lot=20 about this usecase. We need bigger bocks for these usecases as LN will = not do=20 anything for them. --=20 Thomas Zander