Miner fees for batched transactions?

[PepeLapiu]

So I batched transactions in the past. And when I did, if the first transaction was at 1 sat/vB, I could just do 1.2 sat/vB for the second one, and I would save a considerable amount of money on fees.

But something has changed in the Electrum implementation of that.

Yesterday, I did some tests. I sent one tx at 1.2 sat/vB. And when I tried to send a second tx, I input 1.3 sat/vB. But the wallet batched the two transactions at 1.99 sat/vB. As you can see in the link below:
https://mempool.space/tx/044e97e73663dd351953b8c49d0a74ac8c35b38087d0aeb5b788ba91cd05d3ff?mode=details
But instead of batching the two txs into a single transactions at 1.3 sat/vB, it batched them at 1.99 sat/vB.

Than I tries adding some more sends into it at 0.1 sat/vB each. But each time, the total miner fees kept going up to 2.69, 3.34, and 3.95 sat/vB.
So in the end, I really don't save all that much in miner fees. Each transaction would have been at around 1 sat/vB each for around $0.20 USD if I were to send them separately. But batching 5 of them ended up costing $0.80 USD total. So I really didn't save much at all.

How can I increase miner fees with each added spend at around 0.1 or 0.2 sat/vB ? Is that no longer doable?

[DubemIfedigbo001]

How can I increase miner fees with each added spend at around 0.1 or 0.2 sat/vB ? Is that no longer doable?

With the updated electrum wallet pattern of calculating fees,  you need a workaround to do it.

This is because unlike initially when Electrum permits a slightly higher fee because it reuses the transaction inputs and you only pay the Delta. Currently, it has updated it's transaction logic on fee rate calculation and when you send a new batch transaction, it recalculates the fee (ancestor+child) and set the fee to meet mempool acceptable package rules.

The time you wouldn't spend more with the current update is when the mempool is near empty, or you manually construct a raw transaction.

The only possible way around this now is using electrum console to manually create a raw transaction which will give you more control over the inputs, outputs and fees rate. This is a more advanced feature though

[nc50lc]

Yesterday, I did some tests. I sent one tx at 1.2 sat/vB. And when I tried to send a second tx, I input 1.3 sat/vB. But the wallet batched the two transactions at 1.99 sat/vB. As you can see in the link below:
https://mempool.space/tx/044e97e73663dd351953b8c49d0a74ac8c35b38087d0aeb5b788ba91cd05d3ff?mode=details
But instead of batching the two txs into a single transactions at 1.3 sat/vB, it batched them at 1.99 sat/vB.

The correct way to batch transactions in one is to use "pay-to-many" with all of the recipient in one transaction.
That way, those 5 recipients wont have to be included one at a time via RBF on each.
Just type the recipients in the "Pay to" field like this:

Code:

BC1QADDRESS1,0.00011
BC1QADDRESS2,0.00012
BC1QADDRESS3,0.00013

For the fee rate in your method (utilizing batch rbf transactions), that relies on the RBF replacement rule that the fee of the replacement should pay for its own bandwidth and the replaced transaction(s)'s fee.
So its minimum is not a simple 0.1 sat/vB increase but calculated from the 1st transaction' absolute transaction fee plus the replacement transaction's size's minimum fee.

[PepeLapiu]

The correct way to batch transactions in one is to use "pay-to-many" with all of the recipient in one transaction.
That way, those 5 recipients wont have to be included one at a time via RBF on each.
Just type the recipients in the "Pay to" field like this:

Code:

BC1QADDRESS1,0.00011
BC1QADDRESS2,0.00012
BC1QADDRESS3,0.00013

For the fee rate in your method (utilizing batch rbf transactions), that relies on the RBF replacement rule that the fee of the replacement should pay for its own bandwidth and the replaced transaction(s)'s fee.
So its minimum is not a simple 0.1 sat/vB increase but calculated from the 1st transaction' absolute transaction fee plus the replacement transaction's size's minimum fee.

Unfortunately I can't just batch all the transactions in one tx. I built an automation software. And subsequent transactions may or may not come at all.

I'm not fond at all of this new way of batching tx's. This needs to revert to the old way.

[hosemary]

With the updated electrum wallet pattern of calculating fees,  you need a workaround to do it.

No, nothing has changed with how electrum calculates the fees.
OP had to make the transaction with that fees due to nodes standard rules.

The time you wouldn't spend more with the current update is when the mempool is near empty, or you manually construct a raw transaction.

Wrong. OP's problem had nothing to with the mempool's status. The mempools were almost empty when OP broadcasted those transactions.

The only possible way around this now is using electrum console to manually create a raw transaction which will give you more control over the inputs, outputs and fees rate. This is a more advanced feature though

Again wrong.
Even if OP had created a transaction with lower fees, it would be rejected by the nodes.
To make such transaction, you have to send it directly to mining pools and ask them to include it in the blockchain.

To add to nc50lc's reply:

You paid 169 sat as transaction fee for your first transaction and you replaced it with a transaction with the (virtual) size of ‎171 vB.
For the replacement transaction to be accepted by the nodes, you had to pay the minimum fee of 340 sat for that. Any transaction with lower fees would be rejected by the nodes.

Here is where the 340 sat came from:

169 + 171 = 340 sat.

169 sat was the fee paid for the replaced transaction.
171 sat was the fee required for the replacement transaction's own bandwidth.
 

For more information on RBF requirements, read BIP125 rules.

[nc50lc]

-snip-

I'm not fond at all of this new way of batching tx's. This needs to revert to the old way.

But it's been like that ever since Electrum implemented "Batch Unconfirmed Transactions" as well as "Increase Fee (RBF)" features.
The algorithm used is based from RBF's standard which isn't changed ever since.

Your previous experiences may have been on a condition where the fee rate and sizes of the transaction is just right for it to be bumped with additional 0.2 sat/vB or close.
Like if the first transaction has a single input while the its replacement has to use additional UTXOs to cover the additional output's amount.

For example:
Let's say that you've sent a small size transaction (1 input and 2 output) of 140 vB @ 1sat/vB = 140 satoshi absolute fee.
Then you've sent another transaction right after to batch it with that, but Electrum calculated that it has to use 6 more of your UTXO to cover the additional output's cost (if you have lots of small UTXOs)
It'll add about 30vB for the additional output, but since the inputs are now 7, the total size would be: 580vB, the min absolute fee would be 580sat + 140sat = 720sat.
At 720 satoshi absolute fee, the batched txn's fee rate would be: 720 sat ÷ 580vB = 1.24sat/vB.

[PepeLapiu]

-snip-
But it's been like that ever since Electrum implemented "Batch Unconfirmed Transactions" as well as "Increase Fee (RBF)" features.
The algorithm used is based from RBF's standard which isn't changed ever since.

Your previous experiences may have been on a condition where the fee rate and sizes of the transaction is just right for it to be bumped with additional 0.2 sat/vB or close.
Like if the first transaction has a single input while the its replacement has to use additional UTXOs to cover the additional output's amount.

For example:
Let's say that you've sent a small size transaction (1 input and 2 output) of 140 vB @ 1sat/vB = 140 satoshi absolute fee.
Then you've sent another transaction right after to batch it with that, but Electrum calculated that it has to use 6 more of your UTXO to cover the additional output's cost (if you have lots of small UTXOs)
It'll add about 30vB for the additional output, but since the inputs are now 7, the total size would be: 580vB, the min absolute fee would be 580sat + 140sat = 720sat.
At 720 satoshi absolute fee, the batched txn's fee rate would be: 720 sat ÷ 580vB = 1.24sat/vB.

What you are saying is NOT what I have experienced.

I'm a high volume p2p bitcoin trade with all my trades on HodlHodl fully automated with software I built.

In the past, maybe a year ago, I could use RBF to batch a new spend with unconfirned ones. And I would simply pay 0.1 or 0.2 sat/VB more than with the unconfirmed one.
By doing this, I could cut miner fee costs by half.
In trying to cut miner fees ever more, I tried to do it all without a change address. But Electrum would not allow batching when I didn't use a change address.

But now, it has changed. It's no longer letting me increase miner fees as I wish when adding new transactions to the batch. Whatever change was made, at the wallet level, or at the Mempool level, it sucks. Because it's forcing me to pay more in fees.

[PepeLapiu]

Here is the latest test I tried, which makes no sense at all.

I send one tx at 1.0 sat/vB. Somehow, that is the only transaction that sent with the fee I agree to pay.
Here is the mempool.space link to it:
https://mempool.space/tx/eb813d7d4ed2973cce907ee6e6055bc3d70498e37d67d17885d2b9604eabdd0d?mode=details

Than I sent a second on bactched with the first one. The specified miner fee I chose was 0.1 sat/vB, which normally would be rejected because it's below 1 sat/vB.

But it didn't reject it, and it also didn't send at all at my specified sat/vB. Instead, it doubled the miner fee for the batched tx's at 2.01 sat/vB. Which is essentially more exoensive than sending separately, without batching.

Seperately they would have been 0.15$ each. But batched, they were 0.36$. So at this point, in thus instance, RBF/batching is purely harmful.

So I decided to add an other one to the batch. I decided on a 1sat/vB fee for that third one. But dumb Electrum basically increased the miner fee from 2.01 sat/vB on this one. Basically not increasing the fee at a meaningful level.

So when I input 0.1 sat/vB, it doubles the fee from 1 to 2 sat/VB.
And when I input 1 sat/VB, it barely increases by only 0.01 sat/VB.

I don't like this one bit. I want the old Electrum I was using a year or two ago. This is regression.
/

[hosemary]

Please read BIP125 requirements.

But it didn't reject it, and it also didn't send at all at my specified sat/vB. Instead, it doubled the miner fee for the batched tx's at 2.01 sat/vB. Which is essentially more exoensive than sending separately, without batching.

Your first transaction was made with the absolute fee of 141 sat and your second transaction was 171.25 vbytes in size.
This means that the minimum required fee for the second transaction was 313 sat and the minimum required fee rate for that was 1.83 sat/vbyte.

The second transaction could be made with 31 sats less in fee.

So I decided to add an other one to the batch. I decided on a 1sat/vB fee for that third one. But dumb Electrum basically increased the miner fee from 2.01 sat/vB on this one. Basically not increasing the fee at a meaningful level.

Your second transaction was made with the absolute fee of 344 sat and your third transaction was ‎337.75 vbytes in size.
This means that the minimum required fee for the third transaction was 682 sat and the minimum required fee rate for that was 2.02 sat/vbyte.

Your third transaction couldn't be made more economical.

I don't like this one bit. I want the old Electrum I was using a year or two ago. This is regression.

Again, nothing has changed with how electrum caculates the fees.

The smaller the replacement transaction is, the bigger fee rate you have to use for that.
The larger the replacement transaction is, the smaller fee rate you can use for that.

[PepeLapiu]

The smaller the replacement transaction is, the bigger fee rate you have to use for that.
The larger the replacement transaction is, the smaller fee rate you can use for that.

Well, that makes no sense. The fee is in sat/vB so it should adjust with the size of the tx.
In any case, it wasn't like that before.
In the past, when I did an RBF, Electrum would send with the fee I specify. If my unconfirmed tx was at 10 sat/vB, it would only be rejected if I tried to do an RBF with less than 10 sat/vB.
If I submitted the second tx at 10.2 sat/vB, the batched tx would be around 10.2 sat/vB. Not double of the unconfirmed tx.

[nc50lc]

-snip-

What you are saying is NOT what I have experienced.
-snip-
But now, it has changed. It's no longer letting me increase miner fees as I wish when adding new transactions to the batch. Whatever change was made, at the wallet level, or at the Mempool level, it sucks. Because it's forcing me to pay more in fees.

Hmm it shouldn't be possible outside of my example scenario, it wouldn't comply to RBF standards otherwise.
Without any drastic difference in the original and replacement transactions' sizes, the average increase should be closer to 1sat/vB than 0.2sat/vB.

It would be best if you can provide actual examples of those past transactions and hopefully, mempool.space still logged its RBF history.

[hosemary]

Well, that makes no sense. The fee is in sat/vB so it should adjust with the size of the tx.

Did you read the link I shared in my previous post?

According to BIP125 rules, the fee you pay for the replacement transaction must be higher than the sum of the minimum relay fee and the total fee of the transactions that would be removed from the mempool after the replacement.
Take note that the rule reffers to the absolute fee, not the fee rate.

[PepeLapiu]

It would be best if you can provide actual examples of those past transactions and hopefully, mempool.space still logged its RBF history.

I looked up some of my old tx's from 2 years ago. Doesn't look like mempool.space logs in RBF history that far back.

[PepeLapiu]

Here is essencially what I used to do.

 I charge my buyers for the miner fee. So if you are buying $100 worth of BTC, and the miner fee is $10, I treat it as a $90 trade.

Some of my buyers trusted me and did not require fast confirmation. They would tell me to take my time and go easy on miner fees. So long as they can see the trade in the mempool, they were happy. So I would charge them $5 for miner fee, instead of $10. They get more coin that way.

And if the next buyer also wants cheaper miner fee, I would batch them all with RBF at 0.2 sat/VB more than the previous trade.

And if the next buyer wants fast confirm, I charge him the full $10 fee, and Bach him with the other two, at a fee high enough to confirm on next block.

This way, they pay less in fees, and I often ended up paying slightly less in fees than I would charge them.

Or also, I would often get two buyers one behind the other. So that they both want fat confirm, but I'm able to batch them if the first one hasn't confirmed yet.

Or during high fee periods, I could have as many as 10 trades who were willing to wait a day for confirm. So I would tell them the tx will confirm at noon every day, and they only get charged half fee.

It all worked out pretty good. All this was automated with my software on HodlHodl. And I always increased fees by 0.2 sat/vB with each spend I added to the batch.

[nc50lc]

It would be best if you can provide actual examples of those past transactions and hopefully, mempool.space still logged its RBF history.

I looked up some of my old tx's from 2 years ago. Doesn't look like mempool.space logs in RBF history that far back.

That's unfortunate, it would've cleared whatever misunderstanding with the previous batch transactions that you used to do.
Since it's not about the fee rate, it has to be calculated precisely from the mentioned values.
There's not even a fee rate in the transaction data, it's calculated by the client (Electrum) on-the-fly based from its size and left-over amount.

One possible case based from the statement above: since it's automated, it might had been failing to broadcast the first few batch txns due to the low additional fee and saved as "local transaction".
The last batching transaction that had high fee caused those to be batched with enough fee. (since Electrum includes local transactions with it)
And since the local transactions aren't in any node's mempool, only the first transaction will subject to RBF's rule.

But since we have no data to analyze, the query can't be resolved.
Just take note that Electrum implemented RBF based from its unchanged standard and falling to do so will cause the transaction to be rejected by nodes.