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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <clem.ds@gmail.com>) id 1W1JgJ-000093-Ll
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Jan 2014 17:46:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.54 as permitted sender)
client-ip=209.85.128.54; envelope-from=clem.ds@gmail.com;
helo=mail-qe0-f54.google.com;
Received: from mail-qe0-f54.google.com ([209.85.128.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W1JgI-0001ia-QX
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Jan 2014 17:46:11 +0000
Received: by mail-qe0-f54.google.com with SMTP id cy11so3498932qeb.27
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Jan 2014 09:46:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.49.17.232 with SMTP id r8mr9925343qed.74.1389289565406; Thu,
09 Jan 2014 09:46:05 -0800 (PST)
Received: by 10.229.177.195 with HTTP; Thu, 9 Jan 2014 09:46:05 -0800 (PST)
In-Reply-To: <CAP63atZ=-Wd++nuL_Gf-wnT768w3wHhxsA+KgVY-S_C2+1QRLw@mail.gmail.com>
References: <CAP63atZBJqi6oN9EbPxzEo4qk5ZMgEKQ11NSPWmU65FypDdbzw@mail.gmail.com>
<CAP63atZ=-Wd++nuL_Gf-wnT768w3wHhxsA+KgVY-S_C2+1QRLw@mail.gmail.com>
Date: Thu, 9 Jan 2014 18:46:05 +0100
Message-ID: <CAP63atYX1rKCNaDHr5WwAO_kORibCDaBcecWoanpRDR0WMw6aA@mail.gmail.com>
From: =?ISO-8859-1?Q?Cl=E9ment_Elbaz?= <clem.ds@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7bea3be4096f5d04ef8d2f1a
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
(clem.ds[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
X-Headers-End: 1W1JgI-0001ia-QX
Subject: Re: [Bitcoin-development] Getting trusted metrics from the block
chain in an untrusted environment ?
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: Thu, 09 Jan 2014 17:46:11 -0000
--047d7bea3be4096f5d04ef8d2f1a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Rob,
Thank you for answering.
> So you want to 'benefit' from the network without contributing to it ?
> Not going to happen - why would anyone be interested in providing you
'free compute resources' ?
Not free. As I stated in my second email ("some more thoughts" etc.), it
seems really fitting to pay a fee to the network for every metric request
you send. 'I want to execute this request on your blockchain, and I want
the response to be approved by the Bitcoin network, and here is a fee for
all the computing trouble".
You either have the blockchain and the hardware resources to compute things
based on it, or you have addresses that takes a few bytes of data in your
environement but contains money, potentially a lot. The situation seems
plausible to me.
The thing is, as soon as there is an exchange of value (hardware computing
resources vs bitcoins) between parties that do not trust each other, there
is a need for proof of work, and thus my idea (in my second email) of a
specifc block chain that would store metric requests, current block number
when they were asked, and hash of theirs responses. This can be validated
by others nodes and as such can be published in a ledger just like bitcoin
transaction.
> Setup a node, create an API interface and have your 'app' use your API on
yoru node :p
The idea would have been actually to be able to get these computations in a
trusted way without having access to a specific trusted node. Compensating
absence of trust by providing actual money.
Anyways. I got quite a few answer privately, and after study it seems SPV
mode of bitcoinj will be just fine for my specific needs. I would have
liked the solution to be network-centric ideally (By committing to an
SPV-ready API like bitcoinj, I'm committing to languages that provide a
stable SPV API), but I'll be just fine with bitcoinj for now.
Thank you Rob and everyone for your time.
Cl=E9ment
On Wed, Jan 8, 2014 at 8:44 PM, Cl=E9ment Elbaz <clem.ds@gmail.com> wrote:
> Some more thoughts :
>
> If no such project exist yet, I thought it could work with an alternate,
> small and fixed-length 'metric request block chain' of some sort.
>
> It would temporarily stores structures defined as [metric request |
> current block number when request was made | hash of the response] instea=
d
> of financial transactions.
>
> These structures are verifiable so it could work the same way as a regula=
r
> financial blochchain.
>
> It should not be part of the main Bitcoin protocol but could be a plugin
> interacting with the data managed by the fullnode bitcoin software.
>
> Also, metrics requests can be expensive to compute and validate, so it
> would make sense to pay a fee everytime you ask one.
>
> Does any of this makes any sense to you ?
>
> Thanks,
>
> Cl=E9ment
>
--=20
Cl=E9ment ELBAZ
06. 09. 55. 78. 41
clem.ds@gmail.com
--047d7bea3be4096f5d04ef8d2f1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>Hi Rob,<br><br></div>Thank y=
ou for answering.<br><br>> So you want to 'benefit' from the net=
work without contributing to it ?<br><br>> Not going to happen - why wou=
ld anyone be interested in providing you 'free compute resources' ?=
<br>
<br></div>Not free. As I stated in my second email ("some more thought=
s" etc.), it seems really fitting to pay a fee to the network for ever=
y metric request you send. 'I want to execute this request on your bloc=
kchain, and I want the response to be approved by the Bitcoin network, and =
here is a fee for all the computing trouble".<br>
<br></div>You either have the blockchain and the hardware resources to comp=
ute things based on it, or you have addresses that takes a few bytes of dat=
a in your environement but contains money, potentially a lot. The situation=
seems plausible to me.<br>
<br></div>The thing is, as soon as there is an exchange of value (hardware =
computing resources vs bitcoins) between parties that do not trust each oth=
er, there is a need for proof of work, and thus my idea (in my second email=
) of a specifc block chain that would store metric requests, current block =
number when they were asked, and hash of theirs responses. This can be vali=
dated by others nodes and as such can be published in a ledger just like bi=
tcoin transaction.<br>
<br>> Setup a node, create an API interface and have your 'app' =
use your API on yoru node :p<br><br></div>The idea would have been actually=
to be able to get these computations in a trusted way without having acces=
s to a specific trusted node. Compensating absence of trust by providing ac=
tual money.<br>
<br></div>Anyways. I got quite a few answer privately, and after study it s=
eems SPV mode of bitcoinj will be just fine for my specific needs. I would =
have liked the solution to be network-centric ideally (By committing to an =
SPV-ready API like bitcoinj, I'm committing to languages that provide a=
stable SPV API), but I'll be just fine with bitcoinj for now.<br>
<br>Thank you Rob and everyone for your time.<br><br>Cl=E9ment<br><div><div=
><br><div><br><br></div></div></div></div><div class=3D"gmail_extra"><br><b=
r><div class=3D"gmail_quote">On Wed, Jan 8, 2014 at 8:44 PM, Cl=E9ment Elba=
z <span dir=3D"ltr"><<a href=3D"mailto:clem.ds@gmail.com" target=3D"_bla=
nk">clem.ds@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Some more thoughts :<br><br=
>If no such project exist yet, I thought it could work with an alternate, s=
mall and fixed-length 'metric request block chain' of some sort. <b=
r>
<br>It would temporarily stores structures defined as [metric request | cur=
rent block number when request was made | hash of the response] instead of =
financial transactions. <br>
<br>These structures are verifiable so it could work the same way as a regu=
lar financial blochchain.<br><br>It should not be part of the main Bitcoin =
protocol but could be a plugin interacting with the data managed by the ful=
lnode bitcoin software.<br>
<br>Also, metrics requests can be expensive to compute and validate, so it =
would make sense to pay a fee everytime you ask one.<br><br>Does any of thi=
s makes any sense to you ?<br><br>Thanks,<br><br>Cl=E9ment</div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Cl=E9ment ELBAZ<br>06. =
09. 55. 78. 41<br><a href=3D"mailto:clem.ds@gmail.com" target=3D"_blank">cl=
em.ds@gmail.com</a><br>
</div>
--047d7bea3be4096f5d04ef8d2f1a--
|
