Published on: 2022-08-22T07:56:12+00:00
The message discusses an edge case that BIP322 only partially solves - Proof of Payment. In P2P transactions, there is always a risk that the other party will be dishonest and deny receiving payment. This type of dispute is rampant in cryptocurrencies as it can be used as a scam attempt to extract more money from the buyer. BIP322 signed messages can prove that the UTXO(s) belong to the buyer, but not *who* it was sent to.The proposal is to use P2WSH 2-of-2 multisig to solve this problem. The script challenge consists of something like OP_SHA256 OP_EQUAL. The idea behind the scheme is to make it verifiable to the public. Alice signs a BIP322 message from a UTXO and provides one of the signatures, Bob is forced to sign another BIP322 message from his address if he wants his money, and provides another signature. Both signatures are published on the blockchain. The signatures in the Multisig transaction prove who has control of which inputs, so it can be proven who paid who.A delegation scheme for privacy purposes has been proposed that utilizes multisig to make the possible delegatees known at signing time. This would replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH multisig, where N is the number of people you want to be able to create the signature, and their respective pubkeys are included in the script. The possible delegatees are fixed at signature creation time and cannot be extended by creating more transactions. The challenge solution in "to_sign" is then replaced with a witness stack containing n ... 1 0. The signature is generated as if it were for a real P2WPKH-multisig transaction.The proposal has some advantages: no recursive transactions, address verification is provable, there is no opcode or new algorithm introduced, so no soft-fork is required, and signature fraud is still impossible to carry out. There is also a major privacy advantage in that only the delegatee who actually signs the message has a revealed public key, the others' are hidden. There are some disadvantages, such as everyone knows the public keys of the delegators, so there is no privacy. However, this is possibly a non-issue in light of the signature fraud problem. Additionally, Taproot is not widely deployed in applications yet.Moreover, some people have suggested writing this delegation scheme in TapScript, which could avoid revealing the unspent public keys. Single leaf k-of-n multisig is functionally identical to "Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, but it won't hide the non-signing public keys. That leaves multi-leaf k-of-k multisig, which swells as k increases, but for the purposes of delegation, K will always be 1, because we only utilize 1-n multisig signatures as per the previous message.This post discusses a proposal for BIP322 polishing, specifically regarding delegating signatures to other scriptPubKeys for privacy purposes. Instead of using a complicated transaction scheme, the proposal suggests using a multisig approach that makes possible delegatees known at signing time. The proposal outlines steps to replace the message challenge and challenge solution with a witness stack containing n...1 0, generating the signature as if it were for a real P2WPKH-multisig transaction. The pros of this approach are outlined, including no recursive transactions and provable address verification, while the con is that public keys of delegators are known, potentially compromising privacy. Input from others is requested, particularly from luke-jr who participated in the original Github discussion on delegation.A proposal has been made to solve the delegation problem in BIP322. This solution is built on Jeremy Rubin's transaction delegation post and allows a person to delegate signing to another person. This delegation can be useful for various purposes such as Lightning Network, CoinJoin, Mixers, and Silent Payments. The delegation works by signing a preliminary transaction with specific inputs and outputs. The signed message includes the Message, Address, and Signature. BIP322 specifies that the signature is just the raw transaction format of "to_sign". The address used can represent a kind of company; it can represent a channel, a coinjoin, or a silent payment. Bech32 is used to encode the "address" to make it look like a real address.The advantages of this scheme include privacy, arbitrary number of delegations, and delegated signatures can wrap Full and Full with UTXOs signing formats. There are no disadvantages to this scheme. The FAQ section clarifies how the delegation works, how to differentiate between non-delegated and delegated signatures, and how to verify a delegated BIP322 transaction if the address-hash is private. The proposal is cc'd to Kalle for consideration.
Updated on: 2023-08-02T07:16:51.606559+00:00