simpleSignTxn() new method proposal

[pcfun19]

I suggest introducing a new method for generating signatures, which eliminates the need for a policy or information about other signers. This approach involves reading a Partially Signed Bitcoin Transaction (PSBT), utilizing the sighash type, UTXO type (determining if it's SegWit through the presence of a witness), transaction ID, value, vout, and output information. From these elements, it constructs a preimage, which is then displayed on a Ledger device. This allows the user to verify the amounts being spent and the recipients' addresses before signing and returning the signature.

Crucially, this method does not require knowledge of co-signers' extended public keys (xpubs) or any similar keys. It solely ensures that the user is aware of the transaction's details they are signing. The user's software then uses this signature to reconstruct the final transaction, adding other necessary signatures for broadcasting.

This approach enables Ledger devices to sign any redeem/witness scripts without the need to support specific types (standard multi-sig or complex... it is indifferent) or requiring users to gather information from other signers that adds complexity to the user experience. The user only needs their own keys and derivation paths, enabling the wallet to sign the preimage that is the same for any kind of redeem/witness script.

Do you think such a method is feasible and can be implemented?

[bigspider]

Hi @pcfun19, thanks for your comment.

In terms of UX, this is underspecified: showing things that are not easy to understand/verify is equivalent to blind signing if it leads users to skip validation on the device's screen.

This also applies to showing "too much information". For the typical transaction:

• all the inputs are coming from a uniform script type (your account)
• the change output is going back to the same account
• SIGHASH_ALL is used

These assumptions make it safe to minimize the amount of information that is shown to users, as it's no longer important to know exactly what inputs from your account you're spending - it's enough to check all the non-change outputs.

Wallet policies strengthen this greatly by allowing the user to identify from which account they are spending, with hardware guarantees (that is, malware in the software wallet can't tamper with that). The expectation is that people will have multiple accounts, and many of them will involve multiple keys (other co-signers). Wallet policies allow to know exactly from which account you're spending. That's important: if you have a 2-of-2 with your wife, and another 2-of-2 with your colleague at work, it's not enough to know that you're "spending 0.1 btc and sending it to bc1pxxx..", you want to know that you're "spending 0.1 from your work account and sending it to bc1pxxx". Without that, if your co-worker gets access to your computer, it's trivial for them to install malware to trick you to spend your wife's money when you think you're using the company account. Of course, this inherently requires full knowledge of the script on the hardware signer's end, including all of the cosigner's xpubs.

Your approach would possibly be safe in a setting where:

• there is no change address (or you have some other way to identify the change address - that needs to be specified)
• you're not using the same device / seed in multiple setups.

The second assumption, in particular, is not one I'm comfortable with as the default behavior of most users.

As I think wallet policies capture exactly what is needed in the vast majority of the use cases, if more advanced / different signing modes were to be added, the fact that the signing behavior is outside of the "wallet policy model" would have to be very clear in the UX, otherwise the strong security guarantees of wallet policies are lost.

Another option is to have separate apps for use cases that are beyond wallet policies.
Or it could be that wallet policies themselves could be generalized in a way that (safely) covers more use cases.

At this stage, I don't know well enough the landscape of use cases that are not covered from wallet policies; please feel free to document your use case as exactly as possible (what is the setup? What do the descriptors look like? What information is shown to the user? What additional checks does the device perform on the transaction, if any?)

[pcfun19]

I am not sure how it would temper. Without wallet policy Ledger would still hash the witness/redeem/pubkey script of each utxo (depending on type of utxo) so it would show to the user from which account he is spending without the need of a wallet policy. Not sure what I am missing here but probably you know better so I leave it on your judgement.

I believe with PSBT passing utxos and ouputs, sighash type etc all ledger should do is to hash whatever needs to be hashed to show addresses from and to, with respective amounts, generate sighash to sign if user approved that information and return signature. Not sure how one could temper what ledger shows on screen and signs even if someone got access to your computer or whatever.

If change address is all about then for outputs you would simply require developers to pass the derivation path in PSBT's respective output and generate the hashed address from that path anyway. But for script wallets that wouldn't be the case anyway as there is no change address to my knowledge, so we talk only for pub key HD wallets cases and that could be the workaround.

Ultimately, it is the responsibility of software developers to design applications that present valuable information to users. For instance, if a developer configures the software to display an address rather than a path in the output, a Ledger device may not recognise it as a change address and will display it as a regular output address. However, the user will still be aware of the specific address to which they are consenting to send funds. It is the developers' role to enhance the Ledger's functionality in providing more insightful information. Nevertheless, even without such enhancements, a Ledger device owner is aware of the origin and destination of the funds they are authorising for transfer.

Idk, I am probably missing something anyway.

[bigspider]

Centralizing the discussion for this and other issues in #210.