It is open source. https://github.com/opposablebrain/BitcoinDroid

I've been using stunnel for SSL with self-signed certificates. My init script is posted here:

http://bitcointalk.org/index.php?topic=533.0

Was the original question ever answered? Can the clients handle 35000 transactions per block? What about 100000? What is the bytesize of a transaction in the block? How much bandwidth is needed for the network to push these around in 10 minutes?

200.35.150.50

You could always pregenerate all the keypairs (addresses) you'd ever need and keep them in your wallet. Then you just pull new ones off as needed, reuse old ones as you like, etc. E.g. with every transaction you get to pick the addresses that participate in that transaction. From the network's point of view, this is is indistinguishable from the curent behaviour of generating new addresses every time, but you can backup your wallet once in some really robust fashion and never worry about backups again. You can in fact patch your client to do that right now without affecting anyone else or breaking anything. So, that's a PRO; having to back up after every transaction is silly.

The negative side of pregenerating all the keypairs is that if I steal your wallet, and you don't know about it, I can just sit around for years waiting for a big transaction involving one of your addresses and then burn you. This theft is more insidious than just spending your wallet immediately, because nobody can ever be 100% certain than someone hasn't already done it. It would undermine trust in the network.

D'oh. Thanks.

Anyone else tried building on Ubuntu? I get a weird linker error with the boost_threads library. It has nothing to do with Bitcoin per se, except that the client now uses boost threads and my boost installation is being weird. Can anyone else reproduce while I sit here feeling like an idiot?


g++ -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I"/usr/include" -I"/usr/local/include/wx-2.9" -I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" -o bitcoind -L"/usr/lib" -L"/usr/local/lib" obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o obj/sha.o -Wl,-Bstatic -l boost_system -l boost_filesystem -l boost_program_options -l boost_thread -l db_cxx -l crypto -Wl,-Bdynamic -l gthread-2.0
/usr/bin/ld: cannot find -lboost_thread
collect2: ld returned 1 exit status
make: *** [bitcoind] Error 1


It looks like libboostthread is missing. But:


~/dev/bitcoin/trunk$ locate libboost_thread
/usr/local/lib/libboost_thread.so
/usr/local/lib/libboost_thread.so.1.40.0

Curious what the exchange rate was :-)

Hmm, nothing I want to buy right now. I wish it were transferable...
Maybe someone can post some bitcoins up for sale and you can buy them with your certificate? That would be one way to turn it into real money, though you take a hit in the paypal transfer and insertion fees.

Ha! My next-door neighbor works at Bump. I'll talk to him about it. However, even if you didn't "integrate" with the Bump client, you can still include a BC address in your contact info, or even make a blank contact that only has the BC address and nothing else. Then bump that, and the other person copy-pastes into the BC app and sends the money. Another slick idea: steg you BC address into your contact photo, according to a known scheme that all BC users know. Then you just send your photo around with your contact info, and your address is always there, but only BC users know about it.

Regarding a full client on the Android: since it's still mainly a mobile platform, and device batteries barely last a day as it is, I doubt that people would want the hashing to happen on their handset (and these new CPUs heat up a lot when cranking). Would it make sense to run a non-generating client on your phone? If you don't want to open the headless client to the whole world, that may be your only option.
The next thing I plan on doing is to rewrite Satoshi's code into a barebones library using straight ANSI C. That will open up lots of doors for porting, and developers would be able to directly compile for Android or iPhone or whatever, using the native toolchains, and put up whatever GUI they wanted. With a rooted phone, you can run a native bitcoind at startup, and continue to use a thin client to turn generation on/off, etc, if you really wanted that.

Anyway, a thin client is great if you're willing to run a server, which just about anyone can do. Just get yourself a dynamic hostname (e.g. from dyndns.org), open up a port in your firewall, and you're good to go.

PM me if you'd like to get an APK to play with. I should have something ready to go by the weekend. And keep those ideas going.

Cheers!

App is now available on the Android Market. Look for Bitcoin.
Now that we have RPC passwords, I am tunneling bitcoind over SSL, and can query the daemon from anywhere. So, I whipped together an Android app that provides access to the API. At this point, I am just calling "getinfo" and parsing the output, which I think demonstrates the basic functionality needed for a complete app. I'm attaching a fresh screenshot, straight from my Nexus One. I'll be hacking more features in over the next few days.

If you

• are running the headless client on a server somewhere,
• have an Android device,
• want to help with beta testing,
• and will have lots of patience with my schedule...

Then I would love three or four volunteers to help with testing and to suggest fixes and improvements.



                 


For reference, here's how I've set up my Ubuntu server:

1. I created a startup script, /etc/init.d/bitcoind-ssl. It looks like this:

#!/bin/sh -e

##
# /etc/init.d/bitcoind-ssl
##

[ -x /usr/local/bin/bitcoind ] || exit 0
. /lib/lsb/init-functions
. /etc/default/rcS

#The port on which the SSL tunnel will run
PORT=38332
#Run as this user.
USER=rodin

case "$1" in
    start)
   log_begin_msg "Starting bitcoind..."
   su $USER -c ~$USER/bin/bcstart
        /usr/bin/stunnel -d $PORT -r 8332
   ;;
    stop)
   log_begin_msg "Stopping bitcoind..."
   su $USER -c ~$USER/bin/bcstop
   echo Waiting for server to shutdown cleanly...
   sleep 2
   fuser -n tcp $PORT -k
   ;;
    restart|force-reload)
   su $USER -c ~$USER/bin/bcstop
   echo Waiting for server to shutdown cleanly...
   sleep 2
   fuser -n tcp $PORT -k
   su $USER -c ~$USER/bin/bcstart
        /usr/bin/stunnel -d $PORT -r 8332
   ;;
    status)
   su $USER -c ~$USER/bin/bcstatus
   ;;
    *)
   echo "Usage: /etc/init.d/bitcoind-ssl {start|stop|restart|force-reload}"
   exit 1
   ;;
esac

exit 0


2. I made three scripts in ~/bin, bcstart, bcstop, and bcstatus. The names are pretty descriptive. These scripts contain my password but are only readable by me and root, so that's relatively safe (esp. since I'm root).

3. I scheduled the init script to start at boot-time. You can do something like sudo update-rc.d bitcoind-ssl defaults.

And, just for completeness, I use logrotate to simultaneously rotate my bitcoin logs and do staggered backups of my wallet:

##
# logrotate.conf
# Schedule me to run in crontab:
# 0 1 * * * /usr/sbin/logrotate --state /home/rodin/.bitcoin/logrotate.state /home/rodin/.bitcoin/logrotate.conf
##

/home/rodin/.bitcoin/debug.log{
      rotate 5
      prerotate
         /home/rodin/bin/bcstop
         sleep 3
         cp ~/.bitcoin/wallet.dat.4 ~/.bitcoin/wallet.dat.5
         cp ~/.bitcoin/wallet.dat.3 ~/.bitcoin/wallet.dat.4
         cp ~/.bitcoin/wallet.dat.2 ~/.bitcoin/wallet.dat.3
         cp ~/.bitcoin/wallet.dat.1 ~/.bitcoin/wallet.dat.2
         cp ~/.bitcoin/wallet.dat ~/.bitcoin/wallet.dat.1
      endscript
      compress
      postrotate
         /home/rodin/bin/bcstart
      endscript
}



Hope this is all useful to somebody.

Hey,

That's a great idea!
It would inspire confidence to see some proof that you have the certificate. Maybe a screenshot with some of the important numbers blacked out?

Cheers!

The difficulty is 181.5 right now (it's nice to see some real dynamics in the market), which means more CPUs are joining the network.
So the increase in faucet requests and the increase in CPUs are well-correlated, which suggests that the faucet requests are legitimate.

The actual adjustment happens on lines 4 and 5.
bnNew = bnNew * actual/target
This will scale the required work up or down, depending on how long it actually takes to produce a block.

Lines 7 and 8 are just clipping.