That is a very valid request, especially these days
I'll look into it after the San jose conference.

OK, so lets get some real life stats on the table. The following plot was made by observing blocks 229764 - 229939



Every + is a transaction. Total transactions 60608 in 175 blocks

X-axis denotes how many blocks it took for a given transaction to confirm from the time where it was observed (0 means next block)
Y-axis denotes the fee paid pr byte measured in satoshis

Raw data: raw_tx_data.csv (confirming-block-height, fee-pr-byte, confirmation-time-in-blocks, txid)

Plot made like this:
cat raw_tx_data.csv | cut -d ',' -f 2,3 | sed -e 's/,/ /g' | gnuplot -p -e "set yrange [-1:60]; set terminal png size 1500,1000; set output 'fig.png'; set xrange[-100:8000] ;plot '-'"

Analyze away.

The only way I see a miner can game my proposal is by adding transactions sending to himself with large fees.
When doing that he would not broadcast the transactions, but silently include them in his block. (If he broadcasts them another miner would be likely to collect the fee if he finds the block first.)

Let me know if you think there is another way to game it.

There is simple way to detect and filter those transactions out. Simply disregard transactions that you did not see observe as unconfirmed before they were included in a block.

Using this mechanism means that your node has to be running for some time before it can give a good estimate for a fee.

I don't intend to totally automate it. The user would be presented with something like

"Choose the transaction fee for your transaction:
Fast: Fee X*2 BTC (Send)
Normal: Fee X BTC (Send)
Economic: Fee X/2 BTC (Send)
(Cancel)
"

Miners gaming the fee calculation is a risk though, as they can include transactions sent to themselves with enormous fees. My thinking is to try to get around this by cutting away the top 25% and letting the user choose the economic option (half of the remaining average) or cancel.
If a miner tries to drive up the fee he will have to let more than 25% of the transactions be sent from himself to himself,  and have at a loss due to unrealized profits from fees in 'legit' transactions.

Since mining is not a monopoly and the average fee-pr-byte is calculated over say 144 blocks the miner who wants to drive up the fees will have a loss to the remaining miners (unrealized fees), and will have to share the gain with them.

If the miners collude they can drive the fees to whatever they want, but this is aslo the case with the current structure, by simply not including any transactions with say a 10% fee.

Transaction fees are a hot topic these days as we get closer to the maximum block size. If the block size is not increased fees are bound to grow, but unfortunately many bitcoin clients (including my own BitcoinSpinner) do not handle this well. Right now I am using a fixed fee of 0.0005 for every 1000 bytes, and eventually this will not cut it.

Transaction fees are complex  (especially for end users), and for BitcoinSpinner I want a solution where the fee applied makes the transaction likely to get into the next few blocks.

Miners who use an unmodified bitcoind for mining still allow a chunk of gratis transactions with high priority, but I think this will go away due to maximizing profit, and eventually miners will look at fee/transaction-size-in-bytes (eventually considering chains of unconfirmed transactions and their associated fees, etc). So, generally speaking I believe that there will be a price measured in satoshis for getting a byte into the next block. (And not for every 1000 byte chunk as it is now)

So to me the question: How do I predict the cost of getting my transaction into the next few blocks?
Is really: How do I predict the cost of getting a byte into the next few blocks?

My half-baked thinking on this is to:
1. Look at the last 144 blocks (24 hours)
2. Filter away gratis transactions
3. Filter away the bottom 25% and top 25% transactions that include a fee (measured in fee-pr-byte)
4. Calculate f1 = my-transaction-size-in-bytes * <the average fee pr byte in the remaining transactions>
5. Calculate f2 = the fee using traditional fee mechanisms for my transaction (0.0005 pr 1000 bytes)
6. Final fee =  max(f1,f2)

(Obviously step 4 and 5 will have to iterate until a fix point is reached as the size of the transaction may be affected by the fee size.)
Step 6 is there to avoid situations where f1 < f2, and miners still use the classic fee rules

On top of this the user could configure his wallet to be:
Economic: f1 = f1 * 1/2 (get confirmed when there is room)
Normal: f1 unmodified (get confirmed at a 'normal' rate)
Priority: f1 = f1 * 2 (get confirmed quickly)

This way end users have some control over their fees/confirmation-times without having an extended math degree, plus we get a fee market going.

What do you think?

The fee is a little low. It should be 0.0005 * roundup(transaction-size / 1000) = 0.0015 according to the standard (BitcoinQT) implementation. Transaction size is 2597.
The fee paid is 0.001.
I wouldn't worry, a miner is likely to pick it up soon.

It is going to be interesting the day that blockchain.info leaks encrypted wallets. I wonder how many out of their 175.000 wallets use insecure passwords.

If you have exported your private key you can move your coins using for instance blockchain.info or MultiBit, until you can get a new wallet up and running on your new phone.

If you add HD wallets and offline transactions to the list you end up with Armory.

BitcoinSpinner was designed to be easy to use for ordinary people. Adding the above features violate that.

Also, very few people fully understand the fee structure of Bitcoin. Setting your own transaction fee will make people say "Hell, I don't wanna pay any stinking fees", making your transactions stuck.

[Edit] However, anyone can take the source, fork it and do whatever they want

You mean BitInstant, mot BitPay. Had too many beers?

In short "Keep your private keys private". Rule number ONE in Bitcoin land.

I think it was perfect with its flaws and everything. Stirring some curiosity.

+1

Correction. 102

Encrypted keys are prone to brute force attacks. And, end users are notoriously bad at choosing strong passwords -> kindergarten cryptography.
In the end you will have to rely on physical security (e.g. paper backups) to obtain two paramount properties:
1. The ability to make sure you can restore your private key
2. The inability for someone else to obtain your private key

This is why I suggest anyone storing large amounts with BitcoinSpinner to:
1. Use a dedicated device (I installed cyanogen, no sim-card, no other apps)
2. Use two wallets backed up on paper QR-codes. As soon as you restore wallet A on top of wallet B, then wallet B is deleted from your device, and there is no way to get to the key. (yes, wallet B is your savings wallet)

The definition of "large amounts" and proper physical security is up to you.

Hgmichna has some good suggestions for retrieving the backup and put it on paper. I myself took a picture with a camera and placed the SD-card in my printer.

o_dima, thanks for the input. As Gizmo states, he made a patch for this, but I didn't apply it yet, so it is all my fault. Right now I am 110% booked with some great stuff that will be demo'ed at the May conference, and I am not likely to release an update until after that.

The testnet server was used during initial development. It hasn't been running for a long time to reduce cost.

You found 2 of 3. The last one is a bit hard to find.

As far as I remember there should be scheduled downtime today. (30 mins)

Thanks! This makes proud to be in the Bitcoin 100.