As an FYI, I've sent Wendell and co some example code for how to use CPPJVM
to use bitcoinj from native code. A rather rough Hello World app looks like
this:
https://github.com/mikehearn/cppjvm/blob/master/mytest/bcj-hello-world.cpp
So, fairly C++ like.
Further discussion of this should take pla
Actually bitcoinj typically doesn't download all the headers (just from the
last checkpoint) and it throws away headers that are very old. By now
there's quite a lot of difference in how they manage things and I guess it
will diverge from bitcoind even more in future. For instance we're going to
st
On Tue, Jul 16, 2013 at 12:59:56PM +0200, Mike Hearn wrote:
> I think that's a great approach. Here is the patch Satoshi sent me back in
> 2010. All the code has changed since but it can be a source of inspiration.
>
> >From Satoshi:
>
> *The simplified payment verification in the paper imagined
I for one would be interested in taking a look at that.
In San Jose I was asking around about the possibility of hiring someone to
complete such a patch. Pieter Wuille introduced me to Eric Lombrozo, who
expressed interest, but has since gotten quite busy. So we haven't arrived at a
detailed es
Let's re-add the list as this is a topic of general interest.
On Tue, Jul 16, 2013 at 11:36 AM, Jonas Schnelli wrote:
> What do you think about extending the BitcoinKit.framework (based on
> bitcoind) so that the kit could handle the very basic SPV concept
> (getHeaders aka fast catchup, wallet-
> Clear. Your right. C++ would give us more flexibility (other platforms)
> and also android compatibility (through NDK).
>
I'm a bit confused I'm afraid. bitcoinj already runs SPV wallets on Android
on top of Dalvik. In fact that's what it's designed for. The NDK is not
necessary to work with Bit
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
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 as
Java wo
Hi Mike,
You are absolutely right about the synchronize time, it's one of our main
frustration points right now and we clearly won't deliver the kind of user
experience we want, without fixing this. Actually we were thinking of extending
Jeff Garzik's picocoin as time permits, but the plan is f
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
Hi devs,
Just wanted to cross-post this here since it seems very relevant.
We're launching BitcoinKit.framework, a Cocoa framework that allows developers
to write Bitcoin wallet apps for Mac OS X. BitcoinKit uses bitcoind, and serves
a small and tidy API for developer use. Support for other Bit
11 matches
Mail list logo
