calc_tx_vsize() may be off by one wrong (111 vs 110 for 1 P2WPKH in, 1 P2WPKH out)

[kristapsk]

JoinMarket-Org/joinmarket-clientserver#1421 (comment)

@kristapsk I'm not sure about the origin of the 111 value you have for p2wpkh->p2wpkh but I'm able to confirm that 110 is the right rounded-up value for vsize (rounding up is the stated correct thing to do in the BIP) by sending e.g. this transaction:

https://mempool.space/signet/tx/ef8fac70297c9ae5ae5b7944f12ff57e6a6e13f0564b7a13e8ad35545f982085 on signet, showing 109.5 vsize.

With 72 byte signatures (encoded 3045..) you do indeed get 109.5 -> 110. What I find a little confusing is that, while it's definitely possible to get smaller, I don't think it's possible to get bigger. See this serialization of the signature in the above transaction:

3045022100b4cdcf8b364017fe7e5a3ca7dfa8358ac467ae70d6c2d7aa6c2e44c5627674f4022050e2d847cb40a12e19b5b158fa3cf20142fb32990e68f38c8647cc4507568b4901

the first component (the r in (r,s)) has 2100b4... ; that extra x00 is used whenever the value is "negative", i.e. starts with >= x80 (here, xb4..). We don't have any such thing for s because low-s is enforced on the network (though I believe only a standardness rule, but that shouldn't matter here).

So while it's common to see 3044... instead of 3045.., meaning the total (including sighash_all byte x01 at the end) is 71 instead of 72, we don't see 73 I think (and even if we did, because it is witness discounted, that only adds 0.25, so 109.75 instead of 109.5, if i got that right. So in short I'm curious why you had 111 there?