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'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.</p> <p dir=3D"ltr">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.</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, "Jonas Schnelli"= <<a href=3D"mailto:jonas.schnelli@include7.ch">jonas.schnelli@include7.= ch</a>> 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 "unlimited resourc= es" and like to make a "perfect native client" 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 "API'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'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></jonas>= ;</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'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.<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'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'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.</div> <div><br></div><div>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</div> <div><br></div><div>If it's unclear how the code would look, let me kno= w and I'll try and knock up a really simple prototype.</div><div><br></= div><div>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=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'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".</div> <div><br></div><div>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.</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"><<a href=3D"mailto:w@grabhive.com" target=3D"_blan= k">w@grabhive.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">Hi Mike,<br> <br> 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.<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> > That's great! I'm all for more wallets, especially user friend= ly UIs.<br> ><br> > 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> ><br> > 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&iu=3D/4140/ostg.clktrk_____________________= __________________________" target=3D"_blank">http://pubads.g.doubleclick.n= et/gampad/clk?id=3D48808831&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--