BIP375: fixes to Updater role

[nymius]

Description

While reviewing test vectors for BIP 375, and by looking closer at the spec, I noticed the following:

• The updater role mentions the addition of PSBT_IN_BIP32_DERIVATION data for p2wpkh, p2sh-p2wpkh and p2pkh, all members of the Inputs for Shared Secret Derivation from BIP 352, but doesn't mention the addition of PSBT_IN_TAP_BIP32_DERIVATION data for p2tr inputs with key path spend path enabled, which are also part of the Inputs for Shared Secret Derivation from BIP 352 list.
• The argued reason for this is confusing: so the public key is available for creating the ecdh_shared_secret when the private key is not known. This is not making clear that the ECDH shares, on the sending side, can only be produced by the sender private keys.

There is a third point, that was raised before in the BIP 376 specification:

• It's not clear from the specification which format should the Updater use to not reveal the derivation path and fingerprint on these fields.

To address this:

• I rephrased the rationale for BIP32_DERIVATION addition in f208b9d
• I added the mention of PSBT_IN_TAP_BIP32_DERIVATION field in 7d7e034.
• I specified the same format than BIP 376 to not reveal derivation data in 6838026

cc: @andrewtoth

[andrewtoth]

The argued reason for this is confusing: so the public key is available for creating the ecdh_shared_secret when the private key is not known. This is not making clear that the ECDH shares, on the sending side, can only be produced by the sender private keys.

The reasoning here is for verifying the ECDH shares with the DLEQ proofs that are generated by a signer without the sender private keys. Other entities can handle the PSBT, and in order to verify they would need the public key of the input A.

Without the PSBT_IN_BIP32_DERIVATION, the proof cannot be verified for p2wpkh, p2sh-p2wpkh and p2pkh. However, it can be verified for p2tr because the public key is known. That is the reasoning for the omission. I suppose the explanation for this can be made more clear in the BIP.

[nymius]

The reasoning here is for verifying the ECDH shares with the DLEQ proofs that are generated by a signer without the sender private keys. Other entities can handle the PSBT, and in order to verify they would need the public key of the input A.

I see. This is a completely different perspective than the one I was using.
The omission of the case I'm addressing in this PR is because that's already understood from the BIP 174 Updater spec or is there any other reason?

Without the PSBT_IN_BIP32_DERIVATION, the proof cannot be verified for p2wpkh, p2sh-p2wpkh and p2pkh. However, it can be verified for p2tr because the public key is known. That is the reasoning for the omission. I suppose the explanation for this can be made more clear in the BIP.

...and the public key is known because it is in the PSBT_IN_WITNESS_UTXO, right?

[andrewtoth-exo]

The omission of the case I'm addressing in this PR is because that's already understood from the BIP 174 Updater spec or is there any other reason?

The derivation data from the BIP174 Updater spec is implied to be for the signer to find the correct keys and to detect change. Now it is needed by both signer and extractor for these specific output scripts for verifying DLEQs.

the public key is known because it is in the PSBT_IN_WITNESS_UTXO

Correct.

[nymius]

@andrewtoth Is this a case of impersonation?

Anyways, I think we can close this and focus the discussion on how to make this clearer.

[andrewtoth]

I control @andrewtoth-exo as well and forgot to switch before commenting. Apologies for the confusion.

[nymius]

Closing because of misunderstood rationale: the original changes weren't intended to produce signatures but to verify DLEQ proofs.