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
157
158
159
160
161
162
163
164
165
166
167
168
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z4Rkw-0004hg-Oo
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 10:36:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4Rkv-0001WQ-IE
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 10:36:42 +0000
Received: by wiga1 with SMTP id a1so72795697wig.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 03:36:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.59.98 with SMTP id y2mr7657785wjq.42.1434364595542; Mon,
15 Jun 2015 03:36:35 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Mon, 15 Jun 2015 03:36:35 -0700 (PDT)
In-Reply-To: <CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
<CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com>
<CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
Date: Mon, 15 Jun 2015 12:36:35 +0200
X-Google-Sender-Auth: Rxxl3uQtE5Lp83dqTeZQLnTukUI
Message-ID: <CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba978a032212405188c0851
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z4Rkv-0001WQ-IE
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 10:36:42 -0000
--047d7ba978a032212405188c0851
Content-Type: text/plain; charset=UTF-8
>
> Since you keep bringing this up, I'll try to clarify this once again.
>
I understand the arguments against it. And I think you are agreeing with me
- Adam is bemoaning the way developers outsource stuff to third party
services, and suggesting it is relevant to the block size debate. And we
are saying, no, it's happening because it's easier than doing things in a
decentralised way.
> If you can't do that, and are just aiming for removing central points of
> failure, run a bunch of servers yourself, and let others run their own.
> That sounds remarkably close to what you actually did, actually...
>
Right. There's a deeper issue here. The sort of 'trustless' querying of the
UTXO set that was demanded from me is impossible even with commitments,
because the answer can change the moment you receive it. All it takes is a
new block or new transaction to be broadcast a split second after you
download and use the data, and suddenly what you did is incorrect no matter
how many proofs you verified!
The only way to know this has happened is to be a full node and download
all transactions yourself ... and even then, you are trusting your peers to
actually relay you all transactions and not a subset. So in the end you can
never achieve perfection, only get closer to it.
But that situation is *fine* for many use cases, like showing someone a
snapshot of their crowdfund in a user interface. We just accept that what
we see on the screen may lag behind reality. It happens all the time with
all kinds of non-Bitcoin apps. We accept that there may be cases where the
answer we get is wrong. The software can nevertheless still be useful.
So Lighthouse compromises. It queries multiple peers and cross-references
their answers. If their answers don't match it shows an error on the screen
and won't show the user any status for their crowdfund at all. This error
has never occurred. Maybe one day it will. So the app gets more
decentralisation, more robustness, and accepts that the user interface
might one day show a wrong answer if the P2P network starts lying (or your
internet connection is hacked, but the right fix for that is P2P
encryption).
Unfortunately this sort of balance-of-risks approach is considered a
non-starter in Bitcoin Core. So why would developers even try? The message
sent was clear: even if you have an approach you think will work, don't
bother.
Much easier to just outsource to a trusted service indeed.
--047d7ba978a032212405188c0851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div>Since you keep bringing this up, I'll try t=
o clarify this once again.<br></div></div></div></div></blockquote><div><br=
></div><div>I understand the arguments against it. And I think you are agre=
eing with me - Adam is bemoaning the way developers outsource stuff to thir=
d party services, and suggesting it is relevant to the block size debate. A=
nd we are saying, no, it's happening because it's easier than doing=
things in a decentralised way.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><div>If you can't do that, and are just aiming for removing centr=
al points of failure, run a bunch of servers yourself, and let others run t=
heir own. That sounds remarkably close to what you actually did, actually..=
.<br></div></div></div></div></blockquote><div><br></div><div>Right. There&=
#39;s a deeper issue here. The sort of 'trustless' querying of the =
UTXO set that was demanded from me is impossible even with commitments, bec=
ause the answer can change the moment you receive it. All it takes is a new=
block or new transaction to be broadcast a split second after you download=
and use the data, and suddenly what you did is incorrect no matter how man=
y proofs you verified!</div><div><br></div><div>The only way to know this h=
as happened is to be a full node and download all transactions yourself ...=
and even then, you are trusting your peers to actually relay you all trans=
actions and not a subset. So in the end you can never achieve perfection, o=
nly get closer to it.</div><div><br></div><div>But that situation is=C2=A0<=
i>fine</i>=C2=A0for many use cases, like showing someone a snapshot of thei=
r crowdfund in a user interface. We just accept that what we see on the scr=
een may lag behind reality. It happens all the time with all kinds of non-B=
itcoin apps. We accept that there may be cases where the answer we get is w=
rong. The software can nevertheless still be useful.</div><div><br></div><d=
iv>So Lighthouse compromises. It queries multiple peers and cross-reference=
s their answers. If their answers don't match it shows an error on the =
screen and won't show the user any status for their crowdfund at all. T=
his error has never occurred. Maybe one day it will. So the app gets more d=
ecentralisation, more robustness, and accepts that the user interface might=
one day show a wrong answer if the P2P network starts lying (or your inter=
net connection is hacked, but the right fix for that is P2P encryption).</d=
iv><div><br></div><div>Unfortunately this sort of balance-of-risks approach=
is considered a non-starter in Bitcoin Core. So why would developers even =
try? The message sent was clear: =C2=A0even if you have an approach you thi=
nk will work, don't bother.</div><div><br></div><div>Much easier to jus=
t outsource to a trusted service indeed.</div><div><br></div></div></div></=
div>
--047d7ba978a032212405188c0851--
|
