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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z4RZT-0003F5-Tj
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 10:24:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.174 as permitted sender)
client-ip=209.85.160.174; envelope-from=pieter.wuille@gmail.com;
helo=mail-yk0-f174.google.com;
Received: from mail-yk0-f174.google.com ([209.85.160.174])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4RZS-00015q-TT
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 10:24:51 +0000
Received: by ykaz81 with SMTP id z81so52562266yka.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 03:24:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.129.131.214 with SMTP id t205mr33061181ywf.26.1434363885471;
Mon, 15 Jun 2015 03:24:45 -0700 (PDT)
Received: by 10.37.93.67 with HTTP; Mon, 15 Jun 2015 03:24:45 -0700 (PDT)
In-Reply-To: <CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@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>
Date: Mon, 15 Jun 2015 12:24:45 +0200
Message-ID: <CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a114f57c0df4eec05188bdde5
X-Spam-Score: -0.6 (/)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z4RZS-00015q-TT
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:24:51 -0000
--001a114f57c0df4eec05188bdde5
Content-Type: text/plain; charset=UTF-8
On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn <mike@plan99.net> wrote:
> I persevered for several months to add a very small "API" I needed for my
> app to Bitcoin Core, and it was in the end a waste of time. There are no
> actionable items left for the getutxo patch, regardless, I had to fork
> Bitcoin to get it out there. It would have been *much* easier to just
> say, fuck it, I'll use blockchain.info and in fact some in this community
> told me to do exactly that. But, the approach I chose has been working fine
> for months now.
>
Since you keep bringing this up, I'll try to clarify this once again.
Since your patch was to enable querying spentness of particular outputs,
which is fundamentally unprovable data in Bitcoin as is (even your proposed
protocol that verifies scripts with amounts under sighash only proves
correctness of the txout data, not its spentness), I indeed don't see why
you would want anything else than querying such a service. I wish it were
different, but the choice is between querying a central service, or
trusting something a random peer on the internet tells you. At least with
the central service you can use an authenticated protocol with known keys
to detect MITM, and have someone to point to when they lie.
Not decentralized you say? Absolutely. But why do we want decentralization
in the first place? To remove central points of failure, and to reduce
trust. Bitcoin gets away with decentralization because it can validate (to
more or lesser extent) the data it received from its identityless peers. 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...
Do you want actually trustless querying of spentness in the future? Help
working on one of the several TXO commitment ideas to get them implemented.
--
Pieter
--001a114f57c0df4eec05188bdde5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn <span dir=3D"=
ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.n=
et</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><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"><span class=3D""></span>I persevered for several months to add a ver=
y small "API" I needed for my app to Bitcoin Core, and it was in =
the end a waste of time. There are no actionable items left for the getutxo=
patch, regardless, I had to fork Bitcoin to get it out there. It would hav=
e been <b>much</b>=C2=A0easier to just say, fuck it, I'll use <a href=
=3D"http://blockchain.info" target=3D"_blank">blockchain.info</a> and in fa=
ct some in this community told me to do exactly that. But, the approach I c=
hose has been working fine for months now.<br></div></div></blockquote><div=
><br></div><div>Since you keep bringing this up, I'll try to clarify th=
is once again.<br><br></div>Since your patch was to enable querying spentne=
ss of particular outputs, which is fundamentally unprovable data in Bitcoin=
as is (even your proposed protocol that verifies scripts with amounts unde=
r sighash only proves correctness of the txout data, not its spentness), I =
indeed don't see why you would want anything else than querying such a =
service. I wish it were different, but the choice is between querying a cen=
tral service, or trusting something a random peer on the internet tells you=
. At least with the central service you can use an authenticated protocol w=
ith known keys to detect MITM, and have someone to point to when they lie.<=
br><br></div><div class=3D"gmail_quote">Not decentralized you say? Absolute=
ly. But why do we want decentralization in the first place? To remove centr=
al points of failure, and to reduce trust. Bitcoin gets away with decentral=
ization because it can validate (to more or lesser extent) the data it rece=
ived from its identityless peers. If you can't do that, and are just ai=
ming for removing central points of failure, run a bunch of servers yoursel=
f, and let others run their own. That sounds remarkably close to what you a=
ctually did, actually...<br><br></div><div class=3D"gmail_quote">Do you wan=
t actually trustless querying of spentness in the future? Help working on o=
ne of the several TXO commitment ideas to get them implemented.<br><br>-- <=
br></div><div class=3D"gmail_quote">Pieter<br><br></div></div></div>
--001a114f57c0df4eec05188bdde5--
|
