BIP375: fixes to Updater role

nymius commented at 3:37 pm on March 12, 2026: contributor

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 f208b9d4f93b57f80cbdc92a3f08808869cfd255
I added the mention of PSBT_IN_TAP_BIP32_DERIVATION field in 7d7e0343cab5fa6b501a8bc5811ee94a30139830.
I specified the same format than BIP 376 to not reveal derivation data in 6838026ac3611141ed9291f769c7a52d57a57a8f

cc: @andrewtoth

BIP375: replace public keys by private keys to create ECDH in phrase

On the sender side, the public key information provided by the Updater
is used by the Signer in the silent payment output derivation phase to
obtain the private keys required to produce the ecdh shares.
The sender cannot produce the shares from its own public keys, but its
private keys.
This was implied by the former phrase and this change removes the
ambiguity.

f208b9d4f9

BIP375: add PSBT_IN_TAP_BIP32_DERIVATION in Updater role

P2TR outputs with enabled key path spend are also required to derive
ECDH shares. The Updater role wasn't mentioning this but all the others
Inputs Available for Shared Secret Derivation (P2WPKH, P2PKH,
P2SH-P2WPKH) as per BIP 352.
P2TR is also part of these and should be mentioned too.

7d7e0343ca

BIP375: specify format for zeroing derivation data in Updater role 6838026ac3

jonatack added the label Proposed BIP modification on Mar 12, 2026

jonatack added the label Pending acceptance on Mar 12, 2026

andrewtoth commented at 11:58 pm on March 12, 2026: contributor

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 commented at 1:44 pm on March 13, 2026: contributor

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 commented at 2:53 pm on March 13, 2026: none

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 commented at 3:10 pm on March 13, 2026: contributor

@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 commented at 3:22 pm on March 13, 2026: contributor

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

nymius commented at 3:42 pm on March 13, 2026: contributor

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

nymius closed this on Mar 13, 2026

murchandamus removed the label Pending acceptance on Mar 13, 2026

BIP375: fixes to Updater role #2120