This innovation aims at simplifying transactions while maintaining a level of mutual authentication between parties such as friends and family, where the sender wishes their identity to be known to the recipient. This is challenging given Bolt 12's design to protect the privacy of both payer and payee.

To facilitate this, a standard method for selective identity revelation during payments is proposed, necessitating a consensus across different wallets for seamless functionality. The proposal includes two main components: contact key distribution and mutual authentication. Nodes supporting this feature would generate a unique contact_key derived from the node's seed, which could be shared with trusted contacts either through inclusion in Bolt 12 offers or BIP21 URIs. This approach ensures that users can choose privacy for public transactions while still sharing their identity with selected individuals.

For distributing these keys, two methods are suggested. The first involves a new TLV field in Bolt 12 offers, making integration with existing lightning implementations straightforward but potentially leading to redundancy if multiple offers share the same contact_key. The second method proposes an optional query parameter in BIP21 URIs, based on Matt Coral's proposed BIP21 replacement, addressing the issue of duplication but at the cost of larger QR codes and the necessity of using BIP21 URIs over plain offers.

Mutual authentication, assuming successful key distribution, would enable users to identify payments coming from their contacts. Several options are discussed for achieving this, including directly using the invreq_payer_id field provided by Bolt 12, deriving a per-contact invreq_payer_id, and employing bLIP-31 for mutual message authentication. While the first option is simple, it risks unintended identity revelation and lacks nuance. The second option introduces a method to derive unique identifiers for each contact, mitigating some of the drawbacks of the direct use approach. However, the third option, utilizing bLIP-31, is deemed unsuitable due to its complexity and limitations regarding the number of contacts and compatibility issues with trampoline payments.

In conclusion, the post seeks feedback from developers and implementers on the preferred methods for enabling selective identity revelation in Bolt 12 payments. The goal is to refine bLIP 42 based on community input to create a standard that enhances user experience without compromising privacy or security.