Use scantxoutset?

[Sjors]

There's a Bitcoin Core PR that proposes to add scantxoutset which returns UTXOs for a given xpub.

This is obviously less powerful than the current watch-only approach, because you'd lose transaction history. Though perhaps Electrum itself can hold on to the history?

[chris-belcher]

Thanks for telling me. I'll have a think for how it could be used.

Electrum does store transaction history but it always follows the server, so if the server returns an empty history then Electrum will delete it's own stored history.

[Sjors]

Having less private information permanently stored in the server would be nice.

[chris-belcher]

This could be made to have a nice UI if the Electrum client was made to understand that the history was unknown, and then could display a message to the user something like "Complete history unknown".

At least for now, scantxoutset could maybe be used for the "sweeping a private key" feature in Electrum's menu Wallet -> Private keys -> Sweep.

Another issue is gap limits. If there is a UTXO on address 31 then Electrum with a gap limit of 30 won't request it. This could be solved by having Electrum Personal Server could figure out which addresses should have been requested and then send dummy statuses and dummy transactions to the client, to make it request more addresses until the UTXO addresses come up. Those transactions would show up as Not Verified unless EPS can fake a merkle proof. Maybe they could serve as a "history not known" message if you made the addresses be something like `1DummyTransactionHistoryNotKnown"

Maybe the UI for this could be that the rescan-script gives an option of using either the slow and unprune-requiring rescanblockchain or the fast scantxoutset.

[chris-belcher]

Thinking about this some more. I think this could be most useful for restoring from old backups without waiting for a rescan.

The idea of dummy transactions could work well. They'd tell the Electrum wallet the necessary details (address and amount). Even if the transactions appear as Not Verified because there's no merkle proof, they could still be useful to the user (Because they'll know whether it's worth it to take the time to rescan)

An annoying issue is that Electrum hides the amount of confirmations when it hasn't received a valid merkle proof. This could be remedied by writing a PR for Electrum that creates a command-line switch for completely trusting the server, where Electrum would label every transaction as verified. But for restoring from old backups the number of confirmations won't even matter very much.

[chris-belcher]

The server could also simply lie to the client and say the dummy transactions are unconfirmed. Then the Electrum client won't ask for merkle proofs. And the users would still get information about amount and address. Electrum already doesn't show the number of confirmations when a transaction is Not Verified.

[benma]

Thinking about this some more. I think this could be most useful for restoring from old backups without waiting for a rescan.

👍

It's fine if this command is used to find the utxos and related transactions, and just include those in the history. Some of the tx history would be missing (related to spent coins), but that's the trade-off with this command, and is acceptable.

Though sending fake/dummy transactions to trick electrum into behaving a certain way sounds hacky.
Note that there are multiple wallets using the electrum protocol, which might not share the same behavior. It's better to fix a sane api/protocol, and patch relevant issues upstream in Electrum.