Revisit signing flow and UX in the presence of sighash flags

[bigspider]

Currently, if any input is not signed with SIGHASH_ALL/SIGHASH_DEFAULT, we show a generic warning.
There are potentially several aspects that might be changed:

• we currently check that SUM(output_amounts) ≤ SUM(input_amounts); that check is too restrictive if inputs don't commit to the entire transaction (e.g.: SIGHASH_SINGLE; related issue Mark input as external PSBT Partial sign #123)
• How should the UX reflect and handle those advanced use cases?

One way could be to have an "advanced" transaction validation mode, where all inputs (and their SIGHASH_FLAG if appropriate) and all outputs are shown on-screen.

[kewde]

To add a bit more context, all the browser extensions that I have interacted with circumvent this check completely by adding external dummy inputs if all the inputs their sighashes permit it. One typical use-case is listing an Ordinal NFT for sale.

app-bitcoin-new/src/handler/sign_psbt.c

Lines 1341 to 1346 in ea2e273

	if (st->inputs_total_amount < st->outputs.total_amount) {
	PRINTF("Negative fee is invalid\n");
	// negative fee transaction is invalid
	SEND_SW(dc, SW_INCORRECT_DATA);
	return false;
	}

While it certainly doesn't answer the questions you posed w.r.t UX, one quick win could be changing the non negative fee check to only run if all inputs use a default sighash (SIGHASH_ALL/SIGHASH_DEFAULT).