summaryrefslogtreecommitdiff
path: root/84/7ecfa6493546d2706331fa186ce45d4f98a432
blob: 61c383b95873d8b54ba081350e1f4aa43b3806ca (plain)
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
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Uyp4G-0002lt-Do
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jul 2013 20:08:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.50 as permitted sender)
	client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f50.google.com; 
Received: from mail-oa0-f50.google.com ([209.85.219.50])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Uyp4E-0002as-E7
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jul 2013 20:08:20 +0000
Received: by mail-oa0-f50.google.com with SMTP id k7so16456580oag.9
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 15 Jul 2013 13:08:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.97.200 with SMTP id ec8mr44112854oeb.33.1373918892949;
	Mon, 15 Jul 2013 13:08:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Mon, 15 Jul 2013 13:08:12 -0700 (PDT)
Received: by 10.76.23.36 with HTTP; Mon, 15 Jul 2013 13:08:12 -0700 (PDT)
In-Reply-To: <3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
References: <B87F1213-5BD8-43F5-9744-F69947561ED5@grabhive.com>
	<CANEZrP2xh=m8yWLt-o2UrrUVfU+cUYBuMVxkVFF5mVMtWdRwOQ@mail.gmail.com>
	<C1727B41-AF61-44FA-BE17-5FE4425FDEA8@grabhive.com>
	<CANEZrP0_H9+prDSF92q8a4QzP=fzDM6cTDv0+KcfV9NF9thkmw@mail.gmail.com>
	<3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
Date: Mon, 15 Jul 2013 22:08:12 +0200
X-Google-Sender-Auth: -ZENEvDpmtbvJ3Mtx4RS9Q7xUNE
Message-ID: <CANEZrP2jmWkDbpJEm0vd2CKF-prFNbz_ZeNJfDWtSCKb8k5ZXA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jonas Schnelli <jonas.schnelli@include7.ch>
Content-Type: multipart/alternative; boundary=089e0115f34e90907c04e1926bc8
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: 1Uyp4E-0002as-E7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework
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 Jul 2013 20:08:20 -0000

--089e0115f34e90907c04e1926bc8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

You can cut down the JVM to be a few megabytes if you're aggressive about
it. But for a desktop app I'm not sure it's really necessary these days. A
few megabytes used to make a noticeable difference to success rates but
bandwidth improved a lot since then.

Portability to android is a given, it's already Java based. IOS is a non
starter until apple is convinced to allow wallet apps into the App store,
language is not the issue there.

There is no point manually rewriting bitcoinj to c++ when j2c does such a
great job already. You would want to at last start from what it generates
even if you fork from there.
On 15 Jul 2013 20:19, "Jonas Schnelli" <jonas.schnelli@include7.ch> wrote:

> The embedded JVM is a way. But the binary will be huge.
> And how about the portability (like iOS and Android)?
>
> If i would have "unlimited resources" and like to make a "perfect native
> client" i would see two solutions:
> a) add SPV features to bitcoind and go on with BitcoinKit.framework (mayb=
e
> first SPV features are only available through "API's" and not for bitcoin=
d
> as runnable binary)
> b) rewrite bitcoinj in c++ (*auto-port the unit-tests* and try to rewrite
> line by line to c++)
>
> also a mix of a) and b) is possible. Like extending bitcoind with the
> SPVBlockstore, bloom filter, etc. from bitcoinj (rewritten in c++). The
> wallet birthday must also be added somehow.
>
> both a) and b) (or the mix) is a lot of work and might take much longer a=
s
> Mike's JVM idea.
> But it then might end up in a stable, portable and extendable pice of cod=
e.
>
> </jonas>
>
>
>
> Oracle provide an OSX JVM and will do so for the forseeable future, it's
> also open source, so the community could carry on if they stopped. The
> primary problem with the Oracle JVM is lack of retina support for Swing,
> but if you'd write a Cocoa UI yourself then it doesn't matter of course a=
s
> Java won't handle any GUI stuff. Retina support for JavaFX2 (the
> current-gen gui toolkit) is available in Java 8 so it's definitely being
> actively developed, it's not abandoned or anything.
>
> So the question then becomes, which is better:
>
> a) Take bitcoinj completely out of the Java world via native compilation
> or transpilation to C++
> b) Embed the JVM and link the two worlds together?
>
> (b) is much less ambitious, especially if you're OK with writing a bit of
> Java code to keep the interface thin. Basically the Java side calls into
> your app when interesting user-visible things happen, like new transactio=
ns
> appearing, then your GUI can call into the java side to send money. There
> are auto-translators that make the glue work easy, like
> https://code.google.com/p/javacpp/. You probably wouldn't want to expose
> the entire bitcoinj API that way because it's very large, but the code
> needed to bring up a wallet app is very small. I knocked one up this
> weekend in about one evenings worth of coding, completed with nice
> animations. The interfaces you'd need are basically some Objective-C++
> methods that receive information from the Bitcoin side, like the balance
> having changed, a list of transactions, etc, and then a callback into the
> Java side to send money. If you look at the javacpp site you can see
> example code for making calls both ways.
>
> If I were in your shoes, I'd go for (b) because it is the most well
> trodden path and will let you achieve the best user visible results
> quickly. The JVM can be bundled with your app and stripped down if you're
> worried about download size.
>
> If it's unclear how the code would look, let me know and I'll try and
> knock up a really simple prototype.
>
> There's also (a). I'm investigating transpilation for a few reasons, one
> of which is to do with a private project. I'm working with the author of
> j2c: https://code.google.com/a/eclipselabs.org/p/j2c/. It's a rather
> sophisticated transpiler that converts Java to clean, readable C++11 that
> looks much like code a human would write. It's complete enough to transpi=
le
> the entire standard Java class library, including all the GUI toolkits an=
d
> other things - so, pretty amazing piece of code. However it's incomplete
> because where the Java code calls native methods (that would be provided =
by
> the JVM) it just spits out stubs you're expected to fill out yourself, fo=
r
> starting threads and so on. As there's no JVM it's just like using a C++
> library that is missing a "portability layer".
>
> I'm working on this myself and don't really need much help at the moment,
> I'm just making steady progress towards getting something up and running.=
 I
> can let you know once I reach some interesting milestones. The point of
> this is that whilst you don't need access to most of the API to write a
> wallet app, I'd like to make every kind of app easy from C++, not just GU=
I
> wallets. Then the compile-to-C++ approach is much more appealing, even
> though it's also more work.
>
>
>
>
>
> On Mon, Jul 15, 2013 at 4:39 PM, Wendell <w@grabhive.com> wrote:
>
>> Hi Mike,
>>
>> You are absolutely right about the synchronize time, it's one of our mai=
n
>> frustration points right now and we clearly won't deliver the kind of us=
er
>> experience we want, without fixing this. Actually we were thinking of
>> extending Jeff Garzik's picocoin as time permits, but the plan is far fr=
om
>> concrete at the moment.
>>
>> What you say about trans-piling bitcoinj is _really_ appealing. We
>> discounted Java simply because an OS X JVM is no longer guaranteed, but
>> otherwise bitcoinj is ideal for our purposes. How can we assist or
>> otherwise accelerate such an effort?
>>
>> -w
>>
>> On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:
>>
>> > That's great! I'm all for more wallets, especially user friendly UIs.
>> >
>> > However being based on bitcoind means it will take a very long time to
>> synchronize for new users. We know a lot of users drop out. The best fix
>> for this is SPV mode. Do you have any plans in this direction?
>> >
>> > So far, the only SPV mode implementation I know about is bitcoinj. I a=
m
>> experimenting with trans-piling bitcoinj to C++ to make it usable from
>> Objective-C++ exactly with your use case in mind.
>>
>>
>
> -------------------------------------------------------------------------=
-----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&iu=3D/4140/ostg.=
clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> =C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0
> include7 AG
> Jonas Schnelli
> Mattengasse 27
> CH-8005 Z=C3=BCrich
> Switzerland
> Office: +41 44 500 16 70
>
> Mail: jonas.schnelli@include7.ch
> Web: www.include7.ch
> V-Card: www.include7.ch/js.vcf
> =C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0
>
> ACHTUNG
> Bitte senden sie uns keine sensitiven Daten in unverschl=C3=BCsselten E-M=
ails.
> Verwenden Sie hierzu folgenden Link:
> https://include7.ch/contact/secureform
>
> =C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0
>
>

--089e0115f34e90907c04e1926bc8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">You can cut down the JVM to be a few megabytes if you&#39;re=
 aggressive about it. But for a desktop app I&#39;m not sure it&#39;s reall=
y necessary these days. A few megabytes used to make a noticeable differenc=
e to success rates but bandwidth improved a lot since then.</p>

<p dir=3D"ltr">Portability to android is a given, it&#39;s already Java bas=
ed. IOS is a non starter until apple is convinced to allow wallet apps into=
 the App store, language is not the issue there.</p>
<p dir=3D"ltr">There is no point manually rewriting bitcoinj to c++ when j2=
c does such a great job already. You would want to at last start from what =
it generates even if you fork from there.</p>
<div class=3D"gmail_quote">On 15 Jul 2013 20:19, &quot;Jonas Schnelli&quot;=
 &lt;<a href=3D"mailto:jonas.schnelli@include7.ch">jonas.schnelli@include7.=
ch</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div>The embedded JVM is a way. But the=
 binary will be huge.</div><div>And how about the portability (like iOS and=
 Android)?</div><div><br></div><div>If i would have &quot;unlimited resourc=
es&quot; and like to make a &quot;perfect native client&quot; i would see t=
wo solutions:</div>
<div>a) add SPV features to bitcoind and go on with=C2=A0BitcoinKit.framewo=
rk (maybe first SPV features are only available through &quot;API&#39;s&quo=
t; and not for bitcoind as runnable binary)</div><div>b) rewrite bitcoinj i=
n c++ (<b>auto-port the unit-tests</b> and try to rewrite line by line to c=
++)</div>
<div><br></div><div>also a mix of a) and b) is possible. Like extending bit=
coind with the SPVBlockstore, bloom filter, etc. from bitcoinj (rewritten i=
n c++). The wallet birthday must also be added somehow.</div><div><br></div=
>
<div>both a) and b) (or the mix) is a lot of work and might take much longe=
r as Mike&#39;s JVM idea.</div><div>But it then might end up in a stable, p=
ortable and extendable pice of code.</div><div><br></div><div>&lt;/jonas&gt=
;</div>
<div><br></div><br><div><br><blockquote type=3D"cite"><div dir=3D"ltr">Orac=
le provide an OSX JVM and will do so for the forseeable future, it&#39;s al=
so open source, so the community could carry on if they stopped. The primar=
y problem with the Oracle JVM is lack of retina support for Swing, but if y=
ou&#39;d write a Cocoa UI yourself then it doesn&#39;t matter of course as =
Java won&#39;t handle any GUI stuff. Retina support for JavaFX2 (the curren=
t-gen gui toolkit) is available in Java 8 so it&#39;s definitely being acti=
vely developed, it&#39;s not abandoned or anything.<div>

<br></div><div>So the question then becomes, which is better:</div><div><br=
></div><div>a) Take bitcoinj completely out of the Java world via native co=
mpilation or transpilation to C++</div><div>b) Embed the JVM and link the t=
wo worlds together?</div>

<div><br></div><div>(b) is much less ambitious, especially if you&#39;re OK=
 with writing a bit of Java code to keep the interface thin. Basically the =
Java side calls into your app when interesting user-visible things happen, =
like new transactions appearing, then your GUI can call into the java side =
to send money. There are auto-translators that make the glue work easy, lik=
e=C2=A0<a href=3D"https://code.google.com/p/javacpp/" target=3D"_blank">htt=
ps://code.google.com/p/javacpp/</a>. You probably wouldn&#39;t want to expo=
se the entire bitcoinj API that way because it&#39;s very large, but the co=
de needed to bring up a wallet app is very small. I knocked one up this wee=
kend in about one evenings worth of coding, completed with nice animations.=
 The interfaces you&#39;d need are basically some Objective-C++ methods tha=
t receive information from the Bitcoin side, like the balance having change=
d, a list of transactions, etc, and then a callback into the Java side to s=
end money. If you look at the javacpp site you can see example code for mak=
ing calls both ways.</div>

<div><br></div><div>If I were in your shoes, I&#39;d go for (b) because it =
is the most well trodden path and will let you achieve the best user visibl=
e results quickly. The JVM can be bundled with your app and stripped down i=
f you&#39;re worried about download size.=C2=A0</div>

<div><br></div><div>If it&#39;s unclear how the code would look, let me kno=
w and I&#39;ll try and knock up a really simple prototype.</div><div><br></=
div><div>There&#39;s also (a). I&#39;m investigating transpilation for a fe=
w reasons, one of which is to do with a private project. I&#39;m working wi=
th the author of j2c:=C2=A0<a href=3D"https://code.google.com/a/eclipselabs=
.org/p/j2c/" target=3D"_blank">https://code.google.com/a/eclipselabs.org/p/=
j2c/</a>. It&#39;s a rather sophisticated transpiler that converts Java to =
clean, readable C++11 that looks much like code a human would write. It&#39=
;s complete enough to transpile the entire standard Java class library, inc=
luding all the GUI toolkits and other things - so, pretty amazing piece of =
code. However it&#39;s incomplete because where the Java code calls native =
methods (that would be provided by the JVM) it just spits out stubs you&#39=
;re expected to fill out yourself, for starting threads and so on. As there=
&#39;s no JVM it&#39;s just like using a C++ library that is missing a &quo=
t;portability layer&quot;.</div>

<div><br></div><div>I&#39;m working on this myself and don&#39;t really nee=
d much help at the moment, I&#39;m just making steady progress towards gett=
ing something up and running. I can let you know once I reach some interest=
ing milestones. The point of this is that whilst you don&#39;t need access =
to most of the API to write a wallet app, I&#39;d like to make every kind o=
f app easy from C++, not just GUI wallets. Then the compile-to-C++ approach=
 is much more appealing, even though it&#39;s also more work.</div>

<div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Mon, Jul 15, 2013 at 4:39 PM, Wend=
ell <span dir=3D"ltr">&lt;<a href=3D"mailto:w@grabhive.com" target=3D"_blan=
k">w@grabhive.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi Mike,<br>
<br>
You are absolutely right about the synchronize time, it&#39;s one of our ma=
in frustration points right now and we clearly won&#39;t deliver the kind o=
f user experience we want, without fixing this. Actually we were thinking o=
f extending Jeff Garzik&#39;s picocoin as time permits, but the plan is far=
 from concrete at the moment.<br>


<br>
What you say about trans-piling bitcoinj is _really_ appealing. We discount=
ed Java simply because an OS X JVM is no longer guaranteed, but otherwise b=
itcoinj is ideal for our purposes. How can we assist or otherwise accelerat=
e such an effort?<br>


<span><font color=3D"#888888"><br>
-w<br>
</font></span><div><div><br>
On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:<br>
<br>
&gt; That&#39;s great! I&#39;m all for more wallets, especially user friend=
ly UIs.<br>
&gt;<br>
&gt; However being based on bitcoind means it will take a very long time to=
 synchronize for new users. We know a lot of users drop out. The best fix f=
or this is SPV mode. Do you have any plans in this direction?<br>
&gt;<br>
&gt; So far, the only SPV mode implementation I know about is bitcoinj. I a=
m experimenting with trans-piling bitcoinj to C++ to make it usable from Ob=
jective-C++ exactly with your use case in mind.<br>
<br>
</div></div></blockquote></div><br></div>
---------------------------------------------------------------------------=
---<br>See everything from the browser to the database with AppDynamics<br>=
Get end-to-end visibility with application monitoring from AppDynamics<br>
Isolate bottlenecks and diagnose root cause in seconds.<br>Start your free =
trial of AppDynamics Pro today!<br><a href=3D"http://pubads.g.doubleclick.n=
et/gampad/clk?id=3D48808831&amp;iu=3D/4140/ostg.clktrk_____________________=
__________________________" target=3D"_blank">http://pubads.g.doubleclick.n=
et/gampad/clk?id=3D48808831&amp;iu=3D/4140/ostg.clktrk_____________________=
__________________________</a><br>
Bitcoin-development mailing list<br><a href=3D"mailto:Bitcoin-development@l=
ists.sourceforge.net" target=3D"_blank">Bitcoin-development@lists.sourcefor=
ge.net</a><br><a href=3D"https://lists.sourceforge.net/lists/listinfo/bitco=
in-development" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/bitcoin-development</a><br>
</blockquote></div><br><div>
<div style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;tex=
t-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:norma=
l;text-transform:none;font-size:medium;white-space:normal;font-family:Helve=
tica;word-wrap:break-word;word-spacing:0px">
<div style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;tex=
t-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:norma=
l;text-transform:none;font-size:medium;white-space:normal;font-family:Helve=
tica;word-wrap:break-word;word-spacing:0px">
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
<br>include7 AG<br>Jonas Schnelli<br>Mattengasse 27<br>CH-8005 Z=C3=BCrich<=
br>Switzerland<br>Office: <a href=3D"tel:%2B41%2044%20500%2016%2070" value=
=3D"+41445001670" target=3D"_blank">+41 44 500 16 70</a><br>
<br>Mail:=C2=A0<a href=3D"mailto:jonas.schnelli@include7.ch" target=3D"_bla=
nk">jonas.schnelli@include7.ch</a><br>Web:=C2=A0<a href=3D"http://www.inclu=
de7.ch/" target=3D"_blank">www.include7.ch</a><br>V-Card:=C2=A0<a href=3D"h=
ttp://www.include7.ch/js.vcf" target=3D"_blank">www.include7.ch/js.vcf</a><=
br>
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
<br><br>ACHTUNG<br>Bitte senden sie uns keine sensitiven Daten=C2=A0in unve=
rschl=C3=BCsselten E-Mails.<br>Verwenden Sie hierzu folgenden Link:<br><a h=
ref=3D"https://include7.ch/contact/secureform" target=3D"_blank">https://in=
clude7.ch/contact/secureform</a><br>
<br>=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0</div></div>
</div>
<br></div></blockquote></div>

--089e0115f34e90907c04e1926bc8--