1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Return-Path: <thomas@thomaszander.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9367F826
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: <CABm2gDrJH8-6VPp1Lk4ueJA2ShOU+evTgK-S1zNjuqN8h8Je+Q@mail.gmail.com>
References: <8185694.hShCHQnpze@coldstorage> <1725491.c810VbMBxP@coldstorage>
<CABm2gDrJH8-6VPp1Lk4ueJA2ShOU+evTgK-S1zNjuqN8h8Je+Q@mail.gmail.com>
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 <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: 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
|
