extension
extension copied to clipboard
leather-wallet
CPFP transaction with similar Fee rates still have lower Effective fee rate
The Hiro wallet seems to be lowering the effective fee rate unintentionally.
In this situation where the Fee rate is simlar for the child and parent I expect the effective fee rate to be the same too... so it looks like the correct fee rate.... yet the effective fee rate is still only ~half... why?
If we know why that is perhaps we can prevent it.
Example:
https://mempool.space/tx/048f07ebe4b2f092f59fcddf33c8052c08ac759df21d1b6e4962a156a86be271
@alter-eggo might you have a sense of what's causing this behavior off the top of your head, or would it require investigating?
@markmhx @314159265359879 what does effective fee rate mean here? current average fee per tx?
Well that is a problem, I do not understand the number here either.
Normal example
if two transactions Child and Parent have the same size 200 vB. Parent/Ancestor was send with 60 sat/vB and child with 150 sat/vB then the effective fee rate would be (60+150)/2=) 105sats/vByte (taking into account the weight though it would look like (60*200 vB+150*200 vB)/400 vB = 105 sats/vB
In this example
(7.98 sat/vB*924.5 + 7.99 sat/vB*1540 vB)/2464.5 vB = ~7.986 sats/vB but at the question mark (screenshot first post) it says 3.87 sat/vB
It looks like the original transaction was replaced (I assume with another wallet).
I will post here if I see it again.
This issue is frustrating some of our most loyal users.
In this case the wallet is CPFP-ing the transactions and it is not taken into account the history as it is setting the fee. Since we can't assume the user to know about CPFP-ing. I think the user actually wishes to set the "effective fee" to 32 sats/vB. The wallet could really help by adjusting the fee rate so the effective fee rate actually ends up at 32 sats/vB (so for the whole pending chain instead of just the current one being sent... that would mean the actual fee rate needs to be higher and the wallet could set that instead). I guess that could lead to surprise for the user too... but I think we can do something in the UX to help explain that.
the wallet is CPFP-ing the transactions and it is not taken into account the history as it is setting the fee
How can the wallet CPFP a transaction? Surely we only show inscriptions once their confirmed, and as such would never allow the user to send one that is still waiting to be put into a block? @314159265359879
@kyranjamie ah I didn't explain the scenario very well.
The user has inscriptions in their wallet that have long been confirmed, months ago. Then wants to distribute them to other people/addresses. Preferably sending them in rapid succession not waiting for one to be confirmed before sending the next one.
They send the first one (A) (input 1, output 1) with funds from the native segwit address (input 2), input 2 is not completely spend on fees so some of it remains in output 2.
The next ordinal inscription they send (B) uses output 2 from the prior transaction (which is still pending) to fund the transfer fee. That is what makes it become a CPFP-chain, without the user explicitly choosing to do so.
so right now the wallet includes UTXOs in the selection that aren't confirmed yet?
I see, and so the solution is to exclude pending UTXOs, or increase fees if we detected it's CPFP?
It is my understanding that users like the ability to use unconfirmed UTXO's so I would say the preference is the later: wallet detects CPFP and then sets the effective fee rate to what the user has selected.
Example
- pending transaction has a size of 200 vB is send with a 200 sat fee (1sat/vB)
- user creates new transaction also 200 vB and selects a 2000 sat fee (10 sat/vB)
- On the review screen the wallet detects CPFP ( and shows explainer), and sets the fee rate of this transaction to 19.5 sats/vB so that the effective fee rate becomes 10 sats/vB.
- Confirms the transaction with 19.5 sats/vB
The wallet would need the fee and size of all pending transactions in the same CPFP chain.
@markmhendrickson should we rename this to an enhancement: When users CPFP (unknowningly) because they use pending incoming BTC to fund their next transaction allow users to set the effective fee rate for all transactions in the chain, instead of the fee for the current transaction which can lead to all kinds of effective fee rates based on the size ratio between old and new transaction(s)
Sometimes users have transactions pending from a month or more ago and they influence a transaction they send today. They send it with a rate of 116 sats/vB but because of the large vB size of the old transactions the effective fee rate is much lower (~32 sats/vB):
An involved user suggested that we could warn users when they are sending a CPFP transactions (this is the default when they send a transactions with inputs from a pending transactions).
I think we could even show the influence of specific fee rates on the current transaction and what effect it has on the effective fee rate of all transactions.
I think we should allow users to set the effective fee rate in such a case. This can mean a very high fee rate for the new transaction but that would make sure that all transactions pending get the same fee rate, the one the user is aiming for.
Yes, please. I received unconfirmed utxos with low fee from unknown sources and when sending max amount the wallet included the unconfirmed utxo. Now the tx is stuck with low effective rate :-/ (because of sending max amount, I can't increase the rate)
