I must say I really prefer the features of your app over Bitcoin Wallet for Android. I'm torn between the apps though because I think Bitcoin Wallet is almost perfect visually. But in the end features outweigh being pleasing to the eye, and since it's light weigth it's by far the better app to promote to people on the fly.

I have some feedback and feature requests though on how to make your app even better. So here it comes in order of personal preference.

1. I would very much like a possibility to send bitcoins over SMS, e-mail, or any other way of my choice using the built-in android share API. This would be a killer feature that a lot of people I promote bitcoin to would seem to appreciate as well. There is a fairly easy way to do this that I haven't seen in any client yet, using "bitcoin containers" as I proposed in this thread. The idea seemed to be recieving mostly favourable responses, so it would be pretty cool to see it in action. Android would be the ultimate platform for this as well because of its integration with the phone book and all other installed apps. You could easily send bitcoins to anyone of your acquaintances, even if they don't have a client!

edit: I just realized you actually posted in the thread i linked to so you are aware of the idea. I hope you like it and think of implementing something similar to what was proposed.

2. Integration with the android phone book. You should be able to assign a bitcoin adress to your phone contacts, so you could go from other apps such as people or the sms app directly to the send menu of bitcoin spinner by clicking on their profile picture. It would be a nice feature and easier to implement but would lose some of its value if #1 is implemented.

3. This is mostly a personal preference, but I really like Electrums way of backing up your wallet through a mnemonic code rather than through a QR-code. I feel like it gives you more control over how to keep your back-up safe. I would very much like the possibility to back up my mobile money the same way (which could possibly make synching between computer and phone easier as well, I don't know if you use the same type of deterministic algorithm though). This is fairly low priority to me though compared to the above suggestions, and I understand if you prefer to keep the app simpler and only provide one way to backup.

Note though, I'm not sure myself it could actually work as I've layed it out. 

I'm about to reread the TOR idea thread now and I see you were one of the more prominent advocates of paying with mining hashes there. With a service like this, TOR users could choose for themself wether they wanted to mine with their own computer in real time or pay for the hashes, thus allowing people with lesser hardware to buy bandwith as well.

The point is that paying with mining hashes have some advantages and some disadvantages over paying with bitcoins. The problem I'm trying to solve is any situation where the advantages outweigh the disadvantages. Right now though, I'm just trying to wrap my head around how valuable the advantages are and how you can minimize the disadvantages.

Some advantages:
Mining hashes can be instantly verified. You don't need to wait for a confirmation.
It will leave no public link between payer and payee in the block chain. Most hashes won't be of a valid block. It's just proof-of-work of a specified value. Those hashes that do create a valid block will be hidden among all regular mined blocks.
It allows microtransactions to a bigger degree than bitcoin itself.

One example where all of these properties could be useful is to pay for bandwith in an anonymous network in real time.

There are also some disadvantages.
The most prominent as far as I can see is that the payer needs to trust the payment processor to make good on their promise. However, the payee still does not. This could possibly be solved through smart contracts somehow.
If the pool server gets compromised, payment information could become public, but no more than what would normally have been in the block chain. This risk could also be minimized by making mining hash payments between multiple pools before sending to the true destination as I mentioned in my previous post. Then all of the pools need to be compromised to link payer to payee.

The point is you're not getting any coins back. You are getting mining hashes back directed towards an adress of your choice at a time of you choice, that may or may not create a valid block. Say I have an account at "the deepbit payment processor pool" and I want to make a payment to you. You give me an adress. I give the adress to deepbit who diverts the mining power of the pool to create hashes of the expected value of the payment. I get the hashes and give them to you. You can check that they represent real proof-of-work the same way a pool operator does.

The point I wanted to make was that the money availible for mining is not fixed. It can be increased if the standard method to deposit at pools where to make it through mining fees. If you wanted to deposit at a pool and I wanted to make a payment of the same sum, then the miners that gets to create my hashes could be compensated by your fee to the pool.

Couldn't you "deposit" money at the pool by giving them a transaction with a fee of the amount you want to deposit? That would solve the problem of the limited supply of "hash coins". The pool operator rewards himself with the "deposited" coins and saves them to reward his miners when he needs to divert their hashing power. You could even hide your deposit by creating "regular" transactions to yourself with fees to the miner that looks normal.

Yes, the centralized server is a disadvantage. Matching payments will be a lot harder than with mixing pools though, if not impossible, since you will be hiding among all the regular miners. The biggest problem of many mixer schemes is that there are too few users, which will not be the case here.

If you are really cautious I guess you could actually use mining hashes to transfer money from one pool payment processor to another. The first pool would only have the bitcoin adress of your original deposit and of the second pool, but not of the end destination. The second pool would only have some mining hashes that it accepted for payments and the end destination of those coins, but not your original deposit adress. If you do this thrice you would actually have a scheme that is pretty similar to how TOR works, but for bitcoin payments. The pool in the middle would actually not have a single one of your bitcoin adresses. It would only serve to seperate the first and third pool who respectively has your deposit adress and destination adress.

If you take the right precautions, the worst case scenario, if all the pools you use collude or get compromised, the information they would get would be no more than what would have been found in the block chain if you had made direct bitcoin transactions instead.

The idea came to me when I read the TOR thread about trading mining hashes rather than actual bitcoins to incentivize TOR nodes in a more anonymous way. I'm not sure it's entirely feasible though so I need some input on the idea. But lets say a pool started an internet wallet service where you can deposit bitcoins. You deposit 10 BTC, and the pool credits you with future proof of work worth of 10 BTC. When you want to spend your bitcoins to someone else you get a bitcoin adress, give this to the pool, who then diverts 10 BTC worth of hashing power towards this adress (minus an arbitrary fee). The 10 BTC you initially deposited would be used to reward the miners so they don't lose anything from diverting the hashing power. Once you get the hashes, you give these to the person you wanted to pay who can check their integrity to know their value. (and that person may actually be part of a pool himself and relay the hashes to it so he gets bitcoins without variance).

I have no idea if this is actually a good idea or even technically reasonable, but it seems to me like this would be a way to remove the block chain link between payer and payee. The payer would only be linked to the pool he deposited at. The pool wouldn't even know who it is contributing hashing power to. And the payee would get newly minted bitcoins straight from a block reward, or from another pool.

Now is the time you rip this suggestion to pieces.

Is it possible to combine the centralized coupon system and the mine-for-bandwith system through the mining pools somehow?

Lets say I connect to a big mining pool through free-tor. There I buy 9 BTC of future proof of work for 10 BTC (the pool make a profit of 1 BTC). When I need more bandwith from the TOR-network, I ask the nodes for a bitcoin adress each, give these adresses to the pool which distributes it to its miners, and provide me with the hashes. I give the hashes to the TOR-nodes who accepts them as payment. The TOR nodes don't know anything about each other, and the mining pool only know the bitcoin adresses that belong the TOR nodes I use, but can't associate the adresses with the nodes and much less with me.

I agree with those points, I just don't think that QR codes will stay around forever so that part shouldn't really be a factor in determing the future of bitcoin as far as I'm concerned.

Ok. I'm not a dev so I'm very cautios in suggesting anything. This is more out of curiosity and for understanding. But would it be technically possible to start over from scratch with a new block chain and altered protocol that allows P2SH in a clean manner and put all the current owners of bitcoins in the genesis block?

I'm just a user of bitcoin so I know my voice doesn't have the most weight. But I do see the value in the features that P2SH provides but hackish solutions still make me very wary, and I'm probably not the only one. So if it's at all possible to implement this in a clean manner that would put a lot of my worries to rest, even if it would be more cumbersome to transition.

And I don't really want to go into the dangers of such a transition with the merkle tree and whatever. I'm just wondering if it's technically possible, or if a clean implementation of P2SH is incompatible with the current adress syntax even with a new block chain.

Seriously, listen to the people here who try to help you. There are tools to restore files that have been deleted. Even if the file is deleted the data remains on your hard drive until it's overwritten. So STOP using windows restore and turn of the computer and let someone who knows what they are doing help you. Everything you do right now only diminishes your chances of retrieving your coins.

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

Yes it's the wrong wallet. Stop using that computer now! Get online from another computer and let someone more experienced help you with this.

Ok, thanks. I was trying to think of some other authentication method for who solved the block, but I couldn't get it to work securely in my head either the more I thought about it. I still felt like I had to ask since I've been surprised of what you can achieve with cryptography every other day since I learned about bitcoin and became more interested in the subject. And even if it wouldn't eliminate pooled mining it would disincentivize it and generate some decentralization compared to today. I don't see how adding costs to centralization would centralize the network even more. But that discussion is kind of irrelevant if it's not even possible.

P2Pool is pretty interesting though. But from how mining currently works, miners don't seem to value network security nearly as high as they value reduced variance, so I remain sceptical in how well it will kick of. But it's certainly a great inovation that should be encouraged.

Is there some scalability issues with P2Pool? For example, could every single miner join a P2Pool, or would we need multiple P2Pools? If it's the former I could see a point where even the variance-reducing miners would prefer P2Pool over other pools. A 95% Pie chart for P2Pool on bitcoinwatch would be neat.

Yes, I already noted that problem. I'll bold the relevant parts for you.

So yes, that is a very serious problem, and I'm aware of it. But the thing I have been asking about all this time is wether it's possible to disincentivize pooled mining in the bitcoin protocol without any negative side-effects like that one. I'm leaning towards it not being possible, but I'm not actually sure.

Millions of people play in the lottery so I'm sure they could mine for bitcoins as well even if it's somewhat of a gamble. Bitcoin unlike the lottery would actually still have a positive expected value. If we have some weak risk averse miners, others will come in and profit from the weak miners' irrational -EV move.

Also, I don't think we could possibly lose nearly enough processing power for it to matter. The profitability of mining goes through the roof long before that ever happens. Suppose we lost something extreme like 9 tenths of the current hashing power. We would still have a substantial amount, and those left in the game would gain 10x the amount of bitcoins while their costs remain constant. If a miner recieves $10 of bitcoin for $9 of expenses now, he would get $100 of bitcoin for $9 of expenses in the new scenario with less hashing power. That kind of ROI would surely lure the quitters back in to mining, regardless of variance. Rational miners will endure the variance and gain if others quit.

So I think my point still stands. Pooled mining does nothing for the end-users except creating a potential security risk from centralization.

Maybe you should try to make sure you understand what someone else is saying before you accuse them of bad reading comprehension. I know it's impossible for miners to change the adress after they mine a block with the current implementation. I was wondering if an alternative protocol in theory could make it so that they actually could change the adress afterwards without any negative side-effects, thus creating an environment where pooled mining requires trust and will be reduced to smaller circles of people.

My point is that pooled mining should be looked upon as a flaw in the protocol, not a feature. The centralization that pools create was never intended. When pooled mining was created everyone was saying "Oh cool, this reduces variance" when they should have been like "Oh fuck, this creates unnecessary centralization while adding nothing for the end users, can we patch it somehow?" I don't know if the protocol could be changed to make pooled mining heavily disincentivized, and I think you should be very conservative with protocol changes, but it's worth some thought at least.

P2Pool seem cool though, and is definitely an improvement. The problem is that it relies on other people to voluntary switch to it, which won't necessarily happen (just look at how many are unwilling to switch to a smaller pool). Pool owners are those who are most heavily incentivized to spread the idea of bitcoin mining, and their incentives certainly don't point towards P2Pool. So to truly decentralize bitcoin, we need something more.

I found the thread I was talking about (thanks for the effort though, seems like my thread was few months younger).

https://bitcointalk.org/index.php?topic=1458.0

Really, I believe the weakness here is the very concept of pooled mining. It wasn't intended. It's a bug, not a feature. It provides unneccessary centralization and disrupts the incentives inherent in bitcoin. The only feature is for variance-sensitive miners, but this issue would surely solve itself without pooled mining. If miners would be irrationally risk averse the profitability of bitcoin mining would rise and incentivize more risk seeking miners to join. So I think the proper solution to this problem is to make pooled mining impossible or at least severely disincentivized, if that's even possible.

A post I find interesting in the above thread is this:

Theoretically, could this possibly work in another way? If miners could "steal" the generated block from the pool operator, I believe the ultimate consequence will be that pools will be forced to shrink to smaller trusted circles, thus providing far more decentralization. I may very well be wrong, but I don't see why the miner reward adress needs to be hashed in the block itself, as long as it's hashed in future blocks.

EDIT: Actually I do see a very serious problem here since the winning miner needs to be sure that anyone he relays the block to doesn't simply change the reward adress to its own.

But I still think the optimal solution would be to disincentivize pooled mining within the actual bitcoin protocol, I'm just not sure how. Any suggestions of how this would be possible?

I remember reading an old thread about when the idea of pooled mining came up, but I can't find it now. Could anyone please link it to me if you have it?

Seriously, this post needs more love. As a bitcoin saver the way this protocol change has been tried to be rushed through is far more worrying than some potential technical bugs with the implementation. If this will become the precedent for how future protocol changes will be handled then I'm out of bitcoin. Satoshis way of a 2 year plan seem far more conservative and proper.

Sure. I know I have a wallet seed at least, because if I press the s button in the corner i get my seed together with my mnemonic code. I have also managed to encrypt the wallet with a password which seem to work fine as well. It's the recieve tab that doesn't seem to work. If I look at your screen shot of this tab you have a "New adress" button in the bottom left corner. I don't. I have a "QR" button and a "Copy to clipboard" button, nothing else. The field where my adresses are supposed to be is completely empty and without the "New adress" button I don't seem to be able to generate any adresses.

Thanks, great answer. I just read about BitcoinSpinner and it is open source so it shouldn't be that much work to modify it. I hope whoever does it implements deterministic key generation as well. That way I could use the same wallet seed on my phone and my computer and get a shared wallet without need for synchronization.

I haven't been able to try your client yet since I'm away from my linux computer and the windows version doesn't seem to work for me (everything seems to work except I'm not able to get any recieve adresses), but it seems very appealing to me and I can't wait to try it. Regardless, I have a few feature requests.

1. I think the send tab should have a "choose contact" button. It could be a bit confusing to have two different tabs for sending bitcoins depending on wether you know the reciever or not. I think it would make more sense if the main purpose of the contacts tab only was to manage contacts. Chossing a contact from the contacts tab should bring you to the send tab.

2. Also, you should be able to just write the nick name of a friend from the contact book in order to send money (maybe this is already the case, I haven't ben able to try this feature). No need to mess around with adresses. If I write "friend" and "friend" is associated with an adress the client should recognize it. Auto-completion for this would also be neat.

3. Multiple wallets would be a great feature for those like me that want shared wallets. If I have 3 wallets on my computer, one could be my savings account, one could be shared with my girl friend and one could use the same seed as my android phone. With a nice UI, this would make money management really easy.

ThomasV, do you have any future plans on an Android client? Your implementation shows a lot of promises for phone devices.

I disagree. Bitcoin provides a first-adopter advantage like no other currencies, even for governments. If bitcoin ever becomes big enough, there will be a serious incentive for governments to start accepting them. The first government to do so could secretely buy bitcoins and then boost their value by publicly stating their support. If other governments would follow suit the first-to-adopt-government would gain even more. It's all about the threshold where the expected gain in wealth of adopting bitcoins is valued higher than the expected loss of control. Thus this would most logically happen in a third world country where the government already have little control over their currency.