Topic: Mobile Bitcoin proposal (or light-weight transfers) (Read 8892 times)

The unfortunate caveat being that TXT is a disaster zone. It's very hard to actually buy or build a TXT capable system and the software has a disturbing habit of bricking motherboards that should theoretically have worked off the shelf.

And by bricking, I'm using the old fashioned definition. You have to throw them in the trash and buy a new one.

I was very interested in TXT some years ago and bought the book Intel published on it. But huge pieces are missing and it's clear Intel aren't very interested in pushing the technology. Which is a shame. It could have been very powerful.

I imagine it would work kinda like public key encryption like with PGP encrypted emailing

This can be done using the TPM chip and Intel's Trusted Execution Technology. http://www.intel.com/technology/security/

Yes, this can be done, but the problem then becomes how do you enter the private key without the host noticing?

Would it be possible to host a whole VM in such a way that the hosting service even though having physical access can't access anything inside the VM without the user's private key?

Yeah, I guess if I had a my mobile wallet encrypted and backed up at home, then there's not really any risk of having the bitcoins stolen. I've flip flopped many times as to whether I'd prefer a mobile client or a secure personal web server and y'all have just change my mind again. If somebody else builds a functional native Maemo 5 Bitcoin, I'd definitely use it. Currently I'm not really interested in helping to get it to a functional state, but that may change at some point.

Amen.

A code locked wallet, along with a regular backup elsewhere, would also help a great deal.  If someone steals your cell, you should have plenty of time to get home to use your backup wallet to transfer your cell phone balance off of it before the code is cracked.  Your backup may not have all of your money, but it will have some of it.

And if you don't have the diskspace for the blockchain, just a light version of a client should still be able to *spend* bitcoins, and accept bitcoins on faith.

Yeah, just don't leave to much on your phone, just like you wouldn't leave too much cash in your physical pocket.

This could open up a potiential attack vector, if any thief were to discover that you have a bitcoin client running on your home machine with continuous access.  It could also serve as a sign that you have a client running on your home machine, even if your server was indeed secure.  The main reason that most people have never been actively hacked over their broadband connection, is that most people don't have anything on their home computers worth stealing.  All this will change if bitcoin takes off.  If a talented thief cannot beat the blockchain, he can likely still find a mark in the wide world; and if the home pc is well secured, then the home become a physical target.

IMHO, it's worth the disk space to be able to run a full client on the phone.

It would be better to add a lightweight secure web server so that people can access their secure home bitcoins while away from home. You already have to be online to make transfers, so you might as well connect to your more secure home stash rather then putting the cash onto a mobile phone which is more vulnerable to being stolen. The only advantage to porting bitcoin to mobile phones is if the person doesn't have a home computer, doesn't leave their home computer running while away or for if for some reason their home computer is not secure from the wife and kids.

Right now, it may actually increase Maemo's reach!

Adding Bitcoin to Maemo wouldn't exactly increase Bitcoins reach.. But Android or iphone would!

A full client should be doable without a fork on Nokia's N900 Maemo phone. Maemo Linux supports fairly standard development in C, C++ or Python. I guess the crypto libraries are available because ssh runs on the phone. Most Linux libraries can easily be recompiled for the N900's ARM architecture. The phone has root access "out of the box" and there's no restriction on multitasking or background processes.

The only sticking point would be the GUI library. The N900 comes with GTK+ installed, and QT is optional. But I seem to recall that the Bitcoin client uses some other library, which would need to be recompiled for ARM and made a dependency of the Bitcoin client. No big deal for a developer who is familiar with this stuff (which is not me, unfortunately).

This can easily be resolved with a bitcoin specification?

I have been thinking about mobile-to-mobile bitcoin transfers a bit, and wanted to share some initial thoughts for feedback.

I've been ordering possibilities in my head from "STRONG" to "WEAK" as far as usefulness and security.

Strongest would be bitcoin client on the phone. This is currently doable for an android phone, but Satoshi doesn't want client forks, and you'd have to reimplement in Java. I rate as not a good plan right now.

Next: Secure connection to your wallet, listening on the net through some sort of secure connection to the RPC interface. This is a relatively nice solution, and would be even better if the mainline client added a "listen on port YYYY, using secret ZZZZZ for authentication". Incidentally, this would allow a bunch of nice programmatic solutions to a whole range of possible things to do with Bitcoin.

Something I'm terming "WEAK": Passing over the private key to a given address to a user. Now, I know what you're thinking: double spending, yadda yadda.

On the other hand, it would be nice to sync up a bunch of 1BTC addresses to your phone, and when you wanted to send some money to someone, you could just BUMP or otherwise beam them the public keys. They would verify, IMMEDIATELY transfer the BTC in those accounts out, and you'd all be good to go once they're sure there are no double spending collisions in the network. Of course, don't trust those accounts again.

What seems appealing about this is I've got the spending down to "only one side needs direct access to a full client."

Suggestions for getting it down to "neither side needs direct access to a full client," or some sort of reasonable cloud-oriented proxy server that doesn't require way too much trust from the user?