Attack scenario: The attacker gains access to the wallet but does not have a passphrase. He then sets the transaction fee to the maximum (0.1 BTC per transaction) and waits until the wallet publishes transactions.
If enough transactions are published (for example an exchange wallet) he then invests his top buck in cloud mining and mines a new block and includes the transactions that were published with the inflated fee.
If the attacker has access then he can keep trying sending until it succeeds, meaning someone unlocked it.
The way exchange wallets work is that they unlock to publish transactions a d then lock again. Mainly programatically.
On Mon 3. Dec 2018 at 18:59, João Barbosa notifications@github.com wrote:
If the attacker has access then it can retry sending until it succeeds meaning someone unlocked it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/14824#issuecomment-443826900, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6sZ87wOEDjpjbG-3bwov0rb4INMXqwks5u1XR0gaJpZM4Y2s_w .
Right, I was suggesting they could send right after the unlock - seems more plausible than your scenario?
Anyway, how would this work in multi wallet if the RPC endpoint is not wallet specific?
Multi wallet implement raw signing with custom keys as far as I know. ty fee remains the same.
On Mon 3. Dec 2018 at 20:04, João Barbosa notifications@github.com wrote:
Right, I was suggesting they could send right after the unlock.
Anyway, how would this work in multi wallet if the RPC endpoint is not wallet specific?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/14824#issuecomment-443850266, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6sZ5l8EYlqDNCYRgC85Eo5SMNkQEbuks5u1YO7gaJpZM4Y2s_w .
It seems to me that the "attack" vector here is pretty slim, as it would likely rely on compromise of the host (at which point many other attacks are possible), before setting the per-wallet tx feerate (since #12909) using settxfee. Next the (exchange?) wallet user would have to initiate transactions without setting conf target or feerate manually, which also seems unlikely to me, in order to be taken advantage of.
The payoff (if the attack is not simply a grief) requires having significant-enough hashpower to then collect the fees from those transactions by winning the next block.
If the sender specifies either conf target or feerate as part of the call then these override the the value of m_pay_tx_fee.
In addition to this, the wallet.m_pay_tx_fee member variable seems unlikely to ever be converted to a persistent wallet database entry which would end up being encrypted by the wallet passphrase, as OP suggests could protect against this.
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.
Closing due to lack of interest. Pull requests with improvements are always welcome.