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 ) 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 ; 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: <3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch> Date: Mon, 15 Jul 2013 22:08:12 +0200 X-Google-Sender-Auth: -ZENEvDpmtbvJ3Mtx4RS9Q7xUNE Message-ID: From: Mike Hearn To: Jonas Schnelli 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 Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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. > > > > > > 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 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

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 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.

Portability to android is a given, it'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.

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.

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 resourc= es" and like to make a "perfect native client" i would see t= wo solutions:
a) add SPV features to bitcoind and go on with=C2=A0BitcoinKit.framewo= rk (maybe first SPV features are only available through "API's&quo= t; and not for bitcoind as runnable binary)
b) rewrite bitcoinj i= n 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 bit= coind with the SPVBlockstore, bloom filter, etc. from bitcoinj (rewritten i= n 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 longe= r as Mike's JVM idea.
But it then might end up in a stable, p= ortable and extendable pice of code.

</jonas>= ;



Orac= le provide an OSX JVM and will do so for the forseeable future, it'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'd write a Cocoa UI yourself then it doesn't matter of course as = Java won't handle any GUI stuff. Retina support for JavaFX2 (the curren= t-gen gui toolkit) is available in Java 8 so it's definitely being acti= vely 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 co= mpilation or transpilation to C++
b) Embed the JVM and link the t= wo 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 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=A0htt= ps://code.google.com/p/javacpp/. You probably wouldn't want to expo= se the entire bitcoinj API that way because it'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'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.

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 visibl= e results quickly. The JVM can be bundled with your app and stripped down i= f you're worried about download size.=C2=A0

If it's unclear how the code would look, let me kno= w and I'll try and knock up a really simple prototype.

There's also (a). I'm investigating transpilation for a fe= w reasons, one of which is to do with a private project. I'm working wi= th the author of j2c:=C2=A0https://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 transpile the entire standard Java class library, inc= luding all the GUI toolkits and 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, for starting threads and so on. As there= 's no JVM it's just like using a C++ library that is missing a &quo= t;portability layer".

I'm working on this myself and don't really nee= d much help at the moment, I'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't need access = to most of the API to write a wallet app, I'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's also more work.





On Mon, Jul 15, 2013 at 4:39 PM, Wend= ell <w@grabhive.com> wrote:
Hi Mike,

You are absolutely right about the synchronize time, it's one of our ma= in frustration points right now and we clearly won't deliver the kind o= f user experience we want, without fixing this. Actually we were thinking o= f extending Jeff Garzik's picocoin as time permits, but the plan is far= from concrete at the moment.

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?

-w

On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:

> That's great! I'm all for more wallets, especially user friend= ly 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 f= or 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 Ob= jective-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.n= et/gampad/clk?id=3D48808831&iu=3D/4140/ostg.clktrk_____________________= __________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourcefor= ge.net
https://lists.sourceforge.net/lists/listi= nfo/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<= br>Switzerland
Office: +41 44 500 16 70

Mail:=C2=A0jonas.schnelli@include7.ch
Web:=C2=A0www.include7.ch
V-Card:=C2=A0www.include7.ch/js.vcf<= 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=

ACHTUNG
Bitte senden sie uns keine sensitiven Daten=C2=A0in unve= rschl=C3=BCsselten E-Mails.
Verwenden Sie hierzu folgenden Link:
https://in= clude7.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--