reduce BSQ fee estimation constant for segwit

[ghost]

Fee estimation for Maker/Taker tx is done using the BTC wallet. If BSQ is being burnt, a constant is added to represent the size of adding a BSQ input (2 inputs, 3 outputs tx).

• For legacy BSQ this was 150 vBytes which would result typically in a 325 vByte tx.
• For segwit BSQ we can reduce the constant to 65 which will result typically in a 240 vByte tx.

The number 65 was calculated by figuring the vsize of an offer tx both pre and post Segwit BSQ wallet functionality.
It was verified by checking the estimated vsize and the resultant transaction's vsize after applying the code change.

One caveat with this solution is that Make/Take offer using legacy BSQ UTXO will be estimated 25% low because the fee estimation code is not aware of BSQ wallet details.

I leave it up to the maintainers whether they think this approach is acceptable or not.
If it is too risky, perhaps scaling-in the reduction could be a compromise? (Possibly based on the block height)

[sqrrm]

I think this might be too low. I just had a look at this and the table I came up with was, to be on the safe side

Tx size:

Element	size (vbyte)
Overhead	10
Inputs	41 * N
Outputs	31 * N_sw + 34 * N_p2pkh
Sig p2pkh	108
Sig SW	29

So I think the BSQ sw input should be counted as 41 + 29 = 70 vbytes extra, although it's sometimes a bit smaller.

Got inspiration from here https://bitcoinops.org/en/tools/calc-size/

[ghost]

70 sounds good. Do you have any thoughts on the caveat (legacy BSQ utxo) described above?

[sqrrm]

For the atomic protocol I use this code to calculate the size. It overestimates a little bit due to sigs sometimes being a byte shorter, but otherwise quite accurate I think. This works since each side is only paying for their own and known inputs and outputs. Not sure if this will work for the normal trade protocol.

        // Overhead
        var size = payForOverhead ? 10L : 0L;

        // Inputs and signatures
        for (var input : parent.tx.getInputs()) {
            size += 41 + (input.hasWitness() ? 29 : 108);
        }

        // Outputs
        for (var output : parent.tx.getOutputs()) {
            size += ScriptPattern.isP2WPKH(output.getScriptPubKey()) ? 31 : 34;
        }

        return txFeePerVbyte.multiply(size);

[ghost]

Unfortunately the Bisq code which does fee estimation has no visibility into the utxo being used. BitcoinJ is used for that and it also has no visibility into the BSQ side of things, hence that constant BSQ_INPUT_INCREASE.

[sqrrm]

Indeed, so for now I think this is fine. It's also the taker that pays for the whole tx which makes even worse to get an accurate calculation.

Perhaps we should wait with this change and add in the next release when more BSQ utxos are segwit. If included right now it would guarantee to be wrong in the beginning.

[ghost]

Showing how the change affects the dynamic between using BTC vs BSQ for overall fees. Currently, for small offers it is only economical to use BSQ when mempool fees are < 30 sat/vB.

 
After this PR it would be economical to use BSQ when the mempool fees are < 60 sat/vb.

[ripcurlx]

As we are having already 76+% running on v1.6.4 I think it is fine to merge this for the upcoming release.

[ripcurlx]

utACK