Topic: why no passphrase for settxfee? (Read 2426 times)

I long time ago I assumed it was per transaction and set it to .1 to speed up an important transaction.  Paid a ~2btc fee 

GUI: https://github.com/bitcoin/bitcoin/issues/1714
Settings: https://github.com/bitcoin/bitcoin/issues/1715

Should do rate limiting then too.

I would assume per KB right?

It's probably bad that I can't tell if you mean maxtxfee to be an absolute maximum or a max per KB.

EITHER: requiring that the wallet be unlocked for the settxfee RPC call to succeed
OR: adding a new configuration option "-maxtxfee" (default: 0.01 maybe) that can't be set via RPC
 ...  seems reasonable to me.

We've had an implicit assumption that if an attacker gets access to the RPC interface you're sunk, and while I think that's true (attacker could run a tight loop of "sendtoaddress" that will fail until the moment you unlock the wallet to send some bitcoins somewhere), I also think security in depth is a good idea.

Can you open an issue on github please?

RE: gui not telling you about the fee:

Can you open a separate issue on github about that, too?  That's just a bug, in my humble opinion.

It isn't security:
You seem to keep skipping pass the point that it wouldn't provide security.  The reason for encrypting the keys is not to be an end-all protection against theft.  Ask someone infected with a keylogger, or trojan which replaces copied bitcoin addresses with one owned by the attacker how effective an encrypted wallet it.  It isn't.  So why do we encrypt private keys if funds can still be stolen?  Simple it requires the thief to have both the wallet and passphrase.  If the system/OS is compromised then the theif directly or indirectly will but there are many instances where  thief may only gain access to the wallet file such as accidentally left on a donated/junked computer, survives a format, poorly configured dropbox, stolen usb drive, sent to email as a backup, etc.  

User should know the fee
I don't use bitcoin-qt much but if it doesn't always show the user the fee (even if fee is the default amount) then I agree that is an issue.  Not just a security issue but also a poor UI issue.  Your banking example is good.  The user should know the fee for every tx.  Most users will probably ignore it but the fee should be displayed for every tx.  


Note: I suck at UI work (my field is in back end db development).   It probably can be expressed better, but even that would be better than no info.

About bitcoind
Adding validating to bitcoind "are you sure you wish to pay a fee of x" is counterproductive".   It is designed to be used for automation (hotwallets, merchant systems, service providers, mining, etc).  There should be no confirmations just request and response.   BTW if a thief has access to your bitcoind RPC well your wallet is going to be 0.0000000 BTC real quick.  When you execute unlock they will quickly spend out your entire wallet in a fraction of a second.  I wouldn't worry about a thief making you pay to much in fees is via a compromised RPC.  You won't have any coins to overpay fees with.

My concern is that encrypting the wallet gives people a false sense of security when using bitcoin-qt. It leads them to think 'I can leave bitcoin-qt open because nobody can make transactions anyway because my wallet is encrypted thus my balance is completely safe'.

Problem is, if someone changes their tx fee while they leave their 'secure' bitcoin-qt open, the next time they make a transaction, they will lose potentially a lot of money from the fee.

This is a completely contrived case, but if there's one thing I know about people, it's that they always do end up doing something you think as a developer 'why would you do that?'

The config can be used to alter the balance of the user. Thus, it should not be left unsecured. Am I wrong on this?

If a bitcoin client were truly secure, it should be able to be left entirely exposed and not be susceptible to having the balance altered by anyone other than the owner of the software. It should not be left to 'the chance that the user took the specific OS security measures'.

This debate kills me because I know myself that I can secure my wallet, but I also know that many people will not, through ignorance or accident, and even though this attack is fairly obscure, it is still may lead to someone losing money for 'no reason'. That bothers me.

You should always make sure that only authorized people can access your RPC interface, either by firewalling it, or using a strong password.

Requiring the wallet passphrase is not intended as authentication to the RPC daemon, it's simply a necessity to decrypt the wallet keys.

I have been reading more about the fees to better understand this.


I appreciate this, however crypto and security is not about absolutes, it is about appropriate security, and it seems appropriate that the fee setting should not be able to be arbitrarily changed. I find it hard to believe that a client could not implement an appropriate solution that would enable this to be the case (even if at the OS level it's still considered insufficient). The current solution seems to not be appropriate for the amount of damage that could be caused by this.


edit 2:

Again, I understand your point that this is the role of the OS and that any measure to secure this in the client is just 'feel-good', and I agree with you that proper OS security is the way to go for solving this issue, but I can't shake the feeling that if the client could incorporate a solution to prevent the majority of attackers from exploiting this, why wouldn't it? Why leave this to chance? It still wouldn't stop people who have better understanding from manipulating it, but it would at least stop any old grunt from changing it. It all comes back to the actual real world use cases for this software, and people right now are definitely susceptible to this kind of thing, whereas even a 'feel-good' measure would prevent 99% of the likelihood of it happening. I suppose another way of putting it is: should bitcoin have an encrypted config?

There is no good way to do that in most operating systems.  It is a fundemantal security issue that goes far beyond Bitcoin.  How do you know the client is actually the client?  How do you know the legit client hasn't been modified in memory?  How do you know the attacker isn't intercepting and modifying any warnings or messages from the client?  How do you know the attacker isn't modifying your input (you send coins to 123... attacker modifies that so client sends them to 1456.... then attacker intercepts and modifies the GUI so you see coins sent to 123...)?How do you know no parameters in the client have been modified?  How do you know there is no other process watching the client? watching the I/O?  etc.

Those are all security jobs for the OS.  If the OS is compromised or has a flawed security model then trying to make it secure at the client level is just going to fail.

The real solution is a hardware wallet.  Essentially the "client" becomes computer, custom OS, and program all in one.  Since the developer can control all aspects of the software/hardware stack you can create a more secure solution.   If Bitcoin becomes large enough I see customer hardware clients being the direction things are headed.

Yep I get what you're saying. The fee is only depending on the client, and the security of the client is depending only on the OS.

I guess there's nothing can be done to change this. It just sucks that a disgruntled employee could easily change the fee on the company client, and this loophole isn't apparent to most end-users. It does nothing to benefit the attacker, but it definitely hurts the target.

I've been using the client for a long time now and only just realised if I had accidentally left my rpc open or someone had access to my qt client, they can easily give my funds to miners without me realising until it's too late. It's a very tough way to learn about the perils of securely operating a computer, when it seems like the client should handle this a bit more gracefully.

Perhaps all I'm saying is why is this aspect of security left to the user who probably knows very little (or at least not enough) about securing their OS? Why not make it part of the client so that the client takes better care of their users?

I also just noticed that the message when sending funds does not say anything about the fee about to be charged. I set my fee to 1 BTC and transferred 0.01 BTC to someone, and it only asked if I wanted to send 0.01 BTC, even though my wallet will loose 1.01 BTC. This is... kinda bad! To be certain of my future wallet balance after the transfer I must always check the fee setting before pressing send.

I admit, I am conflicted between the 'developer elegance and reasoning' and the 'end user experience'. I understand the case for both, and am hoping to improve the end user experience.

I think you are still missing the point.  A passphrase in the client to change the setfee wouldn't be useful and only provide "feel good security".  If an attacker has compromised the system to where they can execute arbitrary code they could modify the bitcoin.conf, send tx using the bitcoind API, or even replace the client with a trojan client which uses a custom fee (and hides it from the user) or piggybacks off users unlock request, or sends a copy of the wallet.dat and passphrase to the attacker. 

It would be the job of the OS to ensure that unathorized users can modify programs and files.  If the OS fails in that duty a passphrase in the client isn't going to stop an attacker and adding a token passphrase to the client is just going to dupe a user into thinking they are still safe when they aren't.

From a developer point of view, certainly the purpose of encryption is for securing private keys only, I agree with that. Multisig will add the next step to secure transactions rather than private keys. But it seems that these two security features will still not give 100% control over the security of the movement of funds, since someone without any credentials can still alter the transaction fee, and thus cause 'unexpected' funds movement. I know the client shows a message saying 'this will be the fee' when a transaction is made, but for bitcoind with automated payments etc, or for lazy users who don't read messages, this isn't good enough. You can't know for certain that the fee about to be paid is what you last set it to, because it may have been changed in the meantime. Reality may say this is 'unlikely' to happen because of reason xyz (make sure to set up the environment properly, pay attention to notifications etc); but for dealing with monetary transactions, unlikely isn't good enough.

Any change which can affect the users balance should require some permissions. There doesn't seem to be any reason to allow this setting to be changed by anyone. The reason for no passphrase on settxfee appears to be that the passphrase was designed only to secure the private keys. However, it seems that the goal of 'securing the balance' has not been fully achieved.

My workaround for this in my automated environment is before calling sendtoaddress I always call settxfee. This is not a good solution.

Should settxfee have a passphrase? Is this something to suggest to the dev team?

Because an attacker could do that by modifying the client also (DLL injection for windows).   The purpose of the encrypted wallet (not to be confused with the client but the actual wallet database) is to prevent theft of private keys.  Nothing more.

In the bitcoin client, calling settxfee doesn't require the wallet to be unlocked by the passphrase. It seems like this is something that should be strictly controlled. A malicious user could cause serious damage by setting your tx fees to a large value, and you wouldn't realise it until after the next transaction was made and your balance suddenly became surprisingly low.

Is there a reason why this call doesn't require the wallet to be unlocked?