Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
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 :
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" ;)
Thanks for your comment.
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.
"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).
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:
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.
This addresses Multibit-Legacy#23 partially by providing a trusted md5 check file. Multibit-Legacy#23 will be resolved completely when multidoge.org, the main distribution site for the binaries generated here, has SSL. While users could be fooled into downloading a malicious multibit binary, they can at least refer to this md5 check file, since it's stored in a secure location -- GitHub repos do require some kind of authentication, and are themselves always-SSL. [See Multibit-Legacy#23]