jim618
commented
9 years ago Replace by fee looks like a useful way of rescuing transactions that are in limbo.
We would much rather users don't generate these sorts of transactions. On the miner fee slider we (currently) have an allowable range of 1000 to 10000 sat per KB of transaction, with a default of 3000 sat. As of June 2015 these settings seem to get tx into blocks in a timely fashion and so we are not getting reports of 'limbo transactions'.
To implement RBF would entail upgrades to bitcoinj and is a little tricky from the UI point of view. As blocks are found at random and we currently don't have access to the number of tx in the Core mempool, nor their fees it is tricky from both the code's and user's point of when a tx is 'stuck'.
Thus at the moment there isn't a user problem and it's not a clear/ simple fix.
Fee management is an area where change is inevitable so I think we should keep this issue open as 'Discussion' for when (as is inevitable) fee management in the future needs to be refined / improved.
On the RECEIVE side: If a user sent MBHD a tx and then used FSS RBF the user interface would currently show two tx, for the same amount, and one would be confirmed and the other would just stay unconfirmed. Not ideal but things would keep working. Again, bitcoinj would probably need updates to handle this 'yeah I know this looks like a double spend but it's actually FSS RBF'.
petertodd
First seen safe replace-by-fee is now actively mined by f2pool (21% of the network hash) and we can expect more pools to support this soon. The feature allows users to increase the fee of an existing transaction and rebroadcast it. This offers the possibility of significant usability improvements for bitcoin users who send a transaction with an insufficient fee, or at a time when the network is busy confirming spam transactions, can now rebroadcast with a higher fee to bump the priority. No more stuck transactions.
code can be found here: https://github.com/bitcoin/bitcoin/pull/6176