Mandatory tx fee

[davout]

The preferences window won't let me set the tx fee to zero. Using version 0.3.2 on OSX

[jim618]

Hi davout,

This is by design - there is a minimum fee of 0.0001 (a tenth of a milli). Also the default fee for a fresh install is 0.0005 (half of a milli).

The reason for this is that whilst in theory it is possible to send BTC with zero fee in practice it is not. For the "regular user" (i.e. someone who just wants to use bitcoin and does not really know the details) their user experience is quite poor with zero fee tx. We have probably both experienced this with Instawallet (zero fees added) where you sometimes have to wait until the next morning before the miners decide to add your tx to a block.

It would create too much frustration to users (and too many support calls for me) to have zero fees.

The minimum fee of 0.0001 BTC is actually a bit too low for the current miners - they start ignoring you at less than 0.0005 BTC I find.

If you have an application where you absolutely must have zero tx fees (say a nanopayment system) you can fork the code and just change MultiBitModelSEND_MINIMUM_FEE

Regards,

Jim

[davout]

Hey Jim,

Thanks for the reply.

Having a sensible default is very good, getting in the way of users who explicitly set it otherwise when is definitely a really poor design practice. Also I beg to differ, most transactions will happily pass the isStandard check and get relayed and included properly without a fee.

It is very irritating to even a moderately advanced user when an application gets in the way like this when there really is no reason to do so.

The best design would be as follows :

• First change the minimum fee from 0.0001 to 0.0005 since even with MultiBit's recommended minimal fee you'll experience inclusion delays for non-standard transactions as you said yourself,
• Make the setting really configurable for users, but, if the fee is zero or below the minimum fee put a big scary confirmation box with a big bold warning

Your call, but most users will definitely get annoyed when MultiBit tells them they are idiots who shouldn't be allowed to configure the fee to a perfectly legal value "for their own protection" ;)

Cheers!

[DavidKDeutsch]

This is a little silly; take a look at any block, and plenty of them are populated mostly with zero fee transactions. I guess I'll do my own fork to remove the restriction, but it would be nice if everyone had it.

[jim618]

Thanks for your comment. The main issue with having a zero fee minimum is that currently in bitcoinj you cannot calculate the required minimum fee. As I am sure you know it depends on the size of the transaction and the age and size of the transaction inputs. It is nontrivial to work out because adding funds to pay a fee with a transaction output can alter the required fee. There is a knapsack algorithm in the Satoshi to work it out.

If and when support for fee calculation is added into bitcoinj it will be straightforward to add it into MultiBit and then it won't be required to have a 'fee field' at all.

Fee calculation is one of the few things that bitcoinj does not support so if you have any free time it would be a useful feature to work on. I am sure all the bitcoinj mailing list would be happy to help with the algorithm details as we all want it.

Cheers.

[DavidKDeutsch]

"As I am sure you know it depends on the size of the transaction and the age and size of the transaction inputs."

No, to be honest I did not know that. I looked it up and saw the general gist; are the rules solely to combat things like DDOS attacks (I saw that there were restrictions on tiny transactions because of this)? And are all the rules just something miners follow by convention, or is it actually part of the protocol, i.e. any block that does not follow them is considered invalid by the network? The latter would actually explain why there are so many trivial, tiny transaction fees in the blocks I see. But above you said "In theory it is possible to send BTC with zero fee," and gave me the impression that the minimum tx fee was more to prevent users from getting frustrated when their transactions took several hours. Also, in the algorithm I saw, the tx fee depended on block size, which of course the client cannot know in advance.

I was just planning to do what daveout suggested, i.e. make it totally configurable by the user with a big scary dialog (though by "planning," I mean I will probably never get around it, to be honest). In any event, if the algorithm you mentioned is already in code somewhere, I can't imagine it would be hard to port.

Finally, I just want to say that the client is awesome. I am curious though: how does it work without downloading the entire block chain, and what does one give up in security because of this? In practice, I am not really worried about security, as even a client that downloads the whole chain would have to trust the root block of the whole thing (or at least I think; please correct me if I am wrong).

[jim618]

Hi David, The tx fee algorithm I must admit I do no understand why it is so complicated but I can believe there are reasons for every part. Some of it must be anti-spam and there is a fudge factor for when a block gets nearer the maximum block size. Not being a miner some of the subtleties of mining tradeoffs I am unaware of.

Probably if no-one volunteers once I get the current batch of work out of the way (putting in wallet encryption etc) I will volunteer to work on an implementation and get it into bitcoinj.

That would simplify things as you could just call down into bitcoinj and get the minimum transaction fee and a 'fee-valid' transaction. You would then present it to the user with the minimum fee in the SendConfirm screen.

Yes the minimum fee is currently in there so that it is pretty much guaranteed that the transaction will get in a block 'soon'. If someone sends a small, recently received BTC amount with no fee (which is quite likely for a new user) if it takes hours (or worst case days) for it to confirm then from their point of view the whole bitcoin experience is 'broken'. I want to avoid this.

Thanks for the comment on MultiBit!

How it works is as follows: (I've capitalised the classnames)

1) There is one Peer that is nominated the download peer. This is connected to a remote bitciond - when it sees a new Block, it sends it to MultiBit (MB) 2) The Peer is aware of all the Wallets. 3) All the Blocks that get received (with all their Transactions) get passed to all the Wallets. 4) The Wallets go through all the Transactions in the new Block seeing if any of them are relevant to the keys (ECKey) in the Wallet. 'Relevant' means either they spend some of the keys' BTC, or send it some BTC. The relevant Transactions are stored in the Wallet. 5) The block header (i.e. NOT the Transactions) are added to the BlockChain and stored to disk (by the ReplayableBlockStore class). This is only 100 bytes per block.

Thus bandwidth wise it DOES actually download the whole blockchain, but it only stores the relevant transactions and the blockchain connection data (it needs the latter for when there are block chain reorganisations).

Security wise probably the biggest risk is that an attacker surrounds a running version of MB with 'Cheating Nodes' that give it an incorrect BlockChain. By default MB connects to 4 distinct nodes but if the attacker controlled the network access this would not protect you.

The biggest disadvantage with not storing all the transactions is that it makes importing an arbitary private key very expensive. At the moment you have to re-download all the blocks from the key creation date.

In the future I intend to improve this considerably by having the stored blocks also store a Bloom filter which will tell you whether a bitcoin address appears in that block. MB will then be able to quickly scan the local blockchain and get a list of the blocks it needs to download. It can then to get them all at once. I calculate this will take up about 10 MB of data for the current blockchain which is not too bad considering what it gives you.

Regards