tx size calculator

[ajtowns]

bitcoinops.github.io/en/tools/calc-size.md

Lines 19 to 23 in a38d0dc

	p2pkh_ss: 107 # 1 + 72 + 1 + 33
	p2sh23_ss: 254 # 1 + 1 + 72 + 1 + 72 + 1 + 1 + (1 + 1 + 33 + 1 + 33 + 1 + 33 + 1 + 1)
	nsequence: 4
	p2wpkh_witness: 27 # (1 + 73 + 34)/4
	p2wsh23_witness: 63.5 # (1 + 1 + 73 + 73 + 106)/4

Unless I'm misunderstanding, I think this assumes signatures are 72 bytes, but they're usually 71 bytes due to bitcoin/bitcoin#13666 and similar PRs in other software these days? At block 00000000000000000003478c6874f3901d7e1651e8e0a7b9291c49c1f571af6a I see 469 legacy sigs that are 71 bytes, and 148 thaat are 72 bytes (and 2 that are 70 bytes), fwiw.

See also #322 (comment)

[murchandamus]

I have in the past always calculated with the maximum, as people building a transaction at minFeerate will get a non-standard transaction if they are short one sat.

[bitschmidty]

I dont have a preference on the approach here. @ajtowns thoughts on @murchandamus "worst case" approach?

[ajtowns]

"worst case" for bitcoin core is 71 bytes -- you only get 72 bytes if you're also using older software that doesn't do low-R grinding. Not sure what's best -- I was using it to predict what core txs would look like and was confused at the discrepency; if others are using it to estimate a tx size in order to manually calculate fees to plug in to wallets that don't do low-R grinding, being more conservative might make sense.

The page currently says:

ecdsa_signature (72) (about half of all signatures generated with a random nonce are this size, about half are one byte smaller, and a small percentage are smaller than that)

which describes the behaviour prior to low-R grinding; with low-R grinding, 255/256 signatures are 71 bytes, and 1/256 are 70 bytes, give or take. So updating that text might be worthwhile if nothing else?

[murchandamus]

It would make sense to mention that wallets using low-R grinding would expect smaller signatures. Only about a quarter of signatures are produced with low-R grinding, so continuing to show the conservative value seems like the right move overall:

via: https://transactionfee.info/charts/bitcoin-script-ecdsa-rs-values/

[bitschmidty]

It would make sense to mention that wallets using low-R grinding would expect smaller signatures

Seems like a reasonable compromise on this issue. @murchandamus if youre up for it, I think a wording change or addition somewhere on the page would address this?