SegWit withdrawals are overpaying fees

[cbeams]

I just did two transfers within my v1.4.0 (pre-release) Bisq wallet to test out SegWit transaction fee savings.

The first transfer was from a P2PKH address to a Bech32 address. I set my withdrawal transaction fee to the minimum value of 2 sat/byte. The result was a 188 byte / 188 vbyte transaction that paid 384 sats in fees, for an effective fee rate of 2 sat/vbyte (384 sats / 188 vbytes = 2.04 sat/vbyte):

All of this was as expected, given that the transaction was a "hybrid" P2PKH-to-Bech32 and not a "pure" SegWit transaction.

The second transfer was from the receiving Bech32 address of the first transaction to a newly generated Bech32 address, so I expected to get the fee reduction benefits of a pure SegWit transaction. The withdrawal transaction fee remained at 2 sat/byte. The result was a 188 byte / 110 vbyte transaction that still paid 390 sats in fees, for an effective fee rate of 2.0 sat/byte but 3.6 sat/vbyte, ending up in the same cost as the first transaction with no actual fee savings:

It appears that Bisq is calculating mining fees to be paid based on size in bytes (as it always has) and has not been updated to calculate mining fees based on vbytes when appropriate, i.e. when dealing with an actual Bech32-to-Bech32 SegWit transaction like the second one above.

Expected behavior is that I should have paid ~376 sats for the first transaction (188 vbytes * 2 sat/vbyte), and that I should have paid ~220 sats for the second transaction (110 vbytes * sat/vbyte) for a ~42% savings.

Actual behavior is that I paid the same ~380 sats for both transactions, realizing no actual savings.

Transaction IDs for the two transactions above are available on request. Ping me in Keybase if you need them.

[oscarguindzberg]

yes, you are paying more than you should.
tx fee optimizations for segwit not implemented yet.
You can see WIP https://github.com/oscarguindzberg/bisq/commits/fee-estimation
Working on that now.

[cbeams]

Perfect, thanks.

[cbeams]

I gather these changes won't make it into 1.4.0 final? If not, we should mention this caveat in the release notes. People could technically still get fee savings without it this change, but they'd have to intentionally reduce their withdrawal transaction fee to a value ~42% lower than what they would have entered. Of course this workaround breaks down toward the minimum fee rate barrier of 2 sat/byte. But if someone would have done a pure SegWit withdrawal at 10 sat/byte, they could set the withdrawal transaaction fee value to, say, 6 sat/byte and still end up paying effectively around 10 sat/vbyte.

But that's only if the user actually has Bech32-based utxos to withdraw from, which they probably won't until the trade protocol has been updated to actually use Bech32 internally. I'm sure all of this has been thought of already, @oscarguindzberg, and that's probably why vbyte-based fee estimations are being worked for delivery post 1.4.0, but I didn't see this written down anywhere in the 1.4.0 release notes, so I assume it's something that might cause confusion / unmet expectations for other users.

When announcing 1.4.0, we should probably emphasize that it's now finally possible to transfer out of Bisq to Bech32 wallets, but not to expect any fee savings just yet, because all Bisq trading transactions still happen against P2PKH addresses.

[ripcurlx]

When announcing 1.4.0, we should probably emphasize that it's now finally possible to transfer out of Bisq to Bech32 wallets, but not to expect any fee savings just yet, because all Bisq trading transactions still happen against P2PKH addresses.

I'll add this to the v1.4.1 release notes - thanks for pointing it out!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cd2357]

Is this still an issue with v1.6.4?

AFAIK SegWit should now be fully supported both in the BTC and BSQ wallets.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.