Observations: I was a bit confused at how the exact same filename and file extension describes both an actual particially signed bitcoin tx and also a signed bitcoin tx. Im not sure if it would make sense to have a .sbt extension just to not confuse people or at least add a "signed-" prefix when saving the signed tx .psbt file, so you do not accidentally overwrite or just confuse files.
Overwriting the unsigned PSBT file shouldn't be an issue since it doesn't have any purpose after saving the signed PSBT file.
For the name, it's actually a good idea to automatically rename it with "
signed", not an absolute necessity though.
But you can always rename it before saving if it's confusing. (
the name is editable when saving)
Does the PSBT carry any compromising date on any of its stages? what about if you save the output of "copy to clipboard" on a txt file? specially when signed
There's also some paranoid concern about the new wallet format vs the older one in terms of how keys are dealt with. But overall, it is an interesting and useful workflow there. This is what Bitcoin devs should work on, not facilitate spam on the network.
The thing is, this convenient HD cold-storage + HD watch-only workflow isn't possible with the old wallet type, at least based from your statement of how "
keys are dealt with".
The new wallet type is using the standard BIP44, BIP49, BIP84 and BIP86 derivation paths which opens a way to create a watch-only wallet version with its extended public key at 'account_index' because the lower levels aren't "
hardened".
The old wallet type on the other hand, was using full "
hardened" derivation up to its address' prvKeys, so to create a watch-only wallet, each of the public keys have to be imported to the online wallet since those can only be derived from its parent extended private key, not xpub.
Of course, it's just derivation path so it can be implemented in the legacy wallet but it wont be able to handle complex scripts such as TapRoot.
[/quote]
Well they should keep old wallet format even if it's more cumbersome to deal with. Im still not convincing migrating is a good idea. The typical argument is something like "but you need to leak X address for the derivation to be a problem". Well it's still an higher risk vs having to leak each private address per public address separated. QED.