unsigned transaction size differs on import to offline machine

[xris]

Generating a transaction on my online watch wallet I get a size of 2000-something, but when I transfer to my offline signing wallet I get a size of 3000-something pre-signing (a good couple hundred greater!)!. Same versions of electrum. I saved the tx from online machine by copying to clipboard and saving to a text file.

For investigative purposes I created a watch wallet on the offline machine, and strangely when I import the unsigned transaction to this watch wallet, the transaction size appears correctly!

The unsigned transaction involves an old non-segwit address sending multiple outputs to a segwit address.

Obviously the differential in transaction size means the fee rate is wrong, so this seems like a bug.

Any assistance would be appreciated re ensuring I'm signing the right transaction (the size differential has monkey-wrenched this).

Possibly related issue: https://github.com/spesmilo/electrum/issues/6671

[SomberNight]

How did you create the watching-only wallet that created the unsigned tx? In menubar>Wallet>Information, what is wallet type, seed type, keystore type?

[xris]

Thank you for the response.

I intentionally created the watch wallet with just the public address (rather than the master public key) in order to sweep the address's utxo's to a new offline wallet. Therefore script type is "address" & no seed/keystore.

[SomberNight]

That is precisely why the tx size estimation is highly imprecise. In general it is not possible to calculate with exact numbers without knowing the input script types/templates, and the script type cannot be known just from the address.

[SomberNight]

If you want better estimates, you should use the master public key.

[xris]

Forgive my ignorance, but if the inputs are all restricted to those associated with the public address how does the having the master public key help? Any recommended reading to better understand this?

Edit: i.e. if I load the public address on the online computer and sweep it to a single outside address w/o change address (which would just go back to the public address since have no other change address), how would having the MPK alter the online viewing or the transaction construction? Thanks for any clarity in this regard.

[SomberNight]

In menubar>Wallet>Information, what is wallet type, seed type, keystore type?

If you give this same info for the offline wallet created with the seed (or master pubkey), I might be able to give more specific answers.

Regardless, an address often narrows down the possible scripts that can be used but it does not allow to exactly pinpoint the script template. From a master public key however (which Electrum adds type information to, e.g. xpub/ypub/zpub), or more generally from an output script descriptor (which Electrum does not atm use but e.g. Bitcoin Core does), it is possible to reconstruct the script template and give a very precise estimate of how the signed transaction will look and how large it will be.

For example, given an old "1..." address; just from the address it is not possible to tell whether the public key used to create it is compressed (33 bytes) or uncompressed (65 bytes). From the master public key it is possible, as they are encoded differently. In this specific example, Electrum will guess the public key is compressed (as all modern wallets use compressed keys), but e.g. if it turns out you have an Electrum seed created before version 2.0 (released early 2015), then the guess will be incorrect and will result in greatly underestimating the eventual tx size.

You can see how the guessing works here: https://github.com/spesmilo/electrum/blob/9c1a51547a301e765b9b0f9935c6d940bb9d658e/electrum/transaction.py#L678-L698

[xris]

This is very helpful, I appreciate it! I had assumed the size was deterministic and did not know it was an estimate due to lacking input information. So given that information, if one performs a transaction where it is actually much larger at offline signing, then should this discrepancy simply reduce the final satoshi/size fee rate (assuming the total fee is locked in on transaction construction?)?

I'd transferred just the public address initially to not have to get into dealing with coin control and putative leaking of master public key data on the online computer. But it seems having initially more accurate transaction/fee-rate construction is a better compromise re ease/security.

Re wallet type: indeed it is an old bitcoin core wallet that I dumped keys from and imported into an electrum wallet. To even get the unsigned transaction across I had to chunk the data into >50 QRs! At least I wrote some software to help expedite!

If the information you posted is in the electrum docs, apologies for missing it. If it's not, it would be a good addition for those of us in the minority re dealing with old wallet data.

Thanks again.

[xris]

I'm wondering if there is any way for electrum to flag/notice/alert such discrepancies, but seems like would be contingent upon unsigned/signed transactions carrying metadata for the comparison.

[SomberNight]

So given that information, if one performs a transaction where it is actually much larger at offline signing, then should this discrepancy simply reduce the final satoshi/size fee rate (assuming the total fee is locked in on transaction construction?)?

Yes, the output values and input values are locked in, from which the absolute fee is derived. It is the size of the transaction which is incorrectly estimated at first, so the feerate estime is also incorrect; so in the end the tx size and feerate will be different.

I'm wondering if there is any way for electrum to flag/notice/alert such discrepancies

I guess it would be possible for the online wallet to mark the tx size and feerate as estimates when the unsigned tx is constructed. Note though that the guesses for the script types use the most common scripts for given address types, so they often result in precise estimates.

Alternatively, to be able to detect the discrepancy at signing time on the offline wallet - as the offline wallet cannot currently know whether the online wallet had sufficient information - we would need to extend the partial tx format (e.g. use proprietary PSBT fields) to store data such as the previously shown tx size / feerate in the tx. I don't think this latter approach is worth pursuing though.

[xris]

Thanks again for the response. I might be in a weird edge case space. I have what seems to be a old non-deterministic wallet (dumpwallet yields no seed). I don't want to do a simple sweep because (afaik) that will consolidate unconnected addresses & dust. So I figured consolidating address by address would be the best way using the private keys associated with non-zero balance addresses imported into electrum. However, then I run into this fee calculation issue due to the online machine not having the full information about the public key. Any further recommendations re handling this would appreciated. Otherwise I will try to just accommodate the fee discrepancy by adjusting the fee on the online machine for the actual transaction size. I suppose sweeping individual old private keys (associated with each non-zero address balance) into individual new wallets might be an alternative.

Somewhat relatedly, any recommendations for better understanding & decoding the electrum PSBT formats other than searching through the electrum codebase? I've been trying to better understand all this by doing manual inspection of the data, but obviously the encoding isn't super friendly for this.

Thanks