Topic: "Raise network fee" assumes 1kB transaction... and spends outrageous fee (Read 1126 times)
March 05, 2017, 03:14:32 PM
Just to update those only reading here, it seems fixed -> https://github.com/bitcoin-wallet/bitcoin-wallet/pull/382
March 05, 2017, 01:19:38 PM
March 02, 2017, 04:32:15 PM
When using the "raise network fee" option, Bitcoin Wallet for Android 5.14 disregards the fee category the transaction was initially sent at (ECONOMIC, NORMAL, PRIORITY) but blindly takes the PRIORITY fee value, and multiply it by 2 (hence implicitly assuming a transaction of 1kB since PRIORITY is supposed to be a value in sat/kB):
This causes unnecessarily high fees. For example today I had a small 225-byte transaction stuck unconfirmed after 10 mined block despite a fee of ~28000 sat (~126 sat/B, a NORMAL fee). When I tried to raise its network fee it generated a second 192-byte tx with a fee of 320000 sat because PRIORITY right now is at 160000:
So in total I paid ~348000 sat for 417 bytes or ~835 sat/B, which is 4 times higher than necessary according to https://bitcoinfees.21.co which recommends ~220 sat/B for an estimated delay of 0 blocks. IMHO the code should be changed to properly compute the fee in sat/B instead of assuming a 1kB transaction. And I question the validity of picking 2*PRIORITY. Shouldn't the logic of raising the fee be "pick the next higher-category fee" and only if at PRIORITY already, multiply by 2 (or 1.5 or some other less drastic value)?
Thoughts, anybody?
Code: (RaiseFeeDialogFragment.java)
feeRaise = data.get(FeeCategory.PRIORITY).multiply(2);
This causes unnecessarily high fees. For example today I had a small 225-byte transaction stuck unconfirmed after 10 mined block despite a fee of ~28000 sat (~126 sat/B, a NORMAL fee). When I tried to raise its network fee it generated a second 192-byte tx with a fee of 320000 sat because PRIORITY right now is at 160000:
Code:
$ curl https://wallet.schildbach.de/fees
ECONOMIC=25000
NORMAL=125000
PRIORITY=160000
So in total I paid ~348000 sat for 417 bytes or ~835 sat/B, which is 4 times higher than necessary according to https://bitcoinfees.21.co which recommends ~220 sat/B for an estimated delay of 0 blocks. IMHO the code should be changed to properly compute the fee in sat/B instead of assuming a 1kB transaction. And I question the validity of picking 2*PRIORITY. Shouldn't the logic of raising the fee be "pick the next higher-category fee" and only if at PRIORITY already, multiply by 2 (or 1.5 or some other less drastic value)?
Thoughts, anybody?
Jump to: