bitcoin-dev
BIP 322 use case
Posted on: May 5, 2024 14:50 UTC
The discussion focuses on the intricacies of implementing proof-of-funds and proof-of-sender mechanisms within the context of bitcoin transactions, highlighting the necessity for these proofs to maintain certain properties for security and privacy reasons.
Proof-of-funds is described as a method that verifies a numeric amount rather than an address, leveraging UTXOs (Unspent Transaction Outputs) without directly associating them with the message signer's identity. This approach is crucial for ensuring plausible deniability and facilitating the separation between hot and cold wallets. It allows for the possibility that multiple users could claim distinct bitcoin amounts using the same UTXOs.
In contrast, the proof-of-sender mechanism aims to authenticate a sender's claim of having initiated a specific transaction, identified by its transaction ID (txid) and output index. The complexity arises when trying to design these mechanisms to support coinjoins—transactions that mix multiple users' coins for enhanced privacy—without necessitating ongoing communication among participants post-transaction. The solution seems to hinge on the concept of delegation, where signing authority is delegated, potentially to a deterministic keypair in some scenarios. To prevent distinguishability between delegated and non-delegated signatures, the suggestion is made that delegation should be universally applied.
Additionally, the text proposes a technical enhancement to the current message signing standards: the introduction of a unique identifier akin to the bech32 "bc1" prefix used in Bitcoin addresses. This would simplify the process of signature verification by providing a clear indication of the signature's format. Furthermore, there's an acknowledgment of the Partially Signed Bitcoin Transactions (PSBTs) format's relevance and potential for improving compatibility with the proposed proof mechanisms. However, PSBTs come with their own set of limitations, such as the requirement for each input to contain complete input data, which can become cumbersome when transactions reuse outputs as inputs. A suggested workaround involves allowing inputs within a PSBT to reference data from previous inputs to alleviate this redundancy.
Overall, the email underscores the technical challenges and considerations involved in enhancing bitcoin's transactional privacy and security through advanced cryptographic proofs, emphasizing the need for solutions that accommodate the diverse requirements of privacy-enhancing technologies like coinjoins, while also navigating the constraints imposed by existing transaction formats and standards.