Published on: 2021-07-22T14:44:11+00:00
The author of the taproot privacy BIP proposal has created python-like pseudocode to clarify the specification based on feedback. The pseudocode incorporates the suggestion of selecting a random input instead of the first one. It is important for wallet developers to include this BIP in their implementations as it will enhance the privacy and fungibility of off-chain protocols. Additionally, it will improve incentives for miners in Bitcoin's low-inflation future. The provided pseudocode includes a function called "apply_anti_fee_sniping_fields" which sets the transaction version to 2 in accordance with bip68. If any of the transaction inputs have more than 65535 confirmations or are taproot inputs, the function sets nlocktime. Otherwise, there is a 50% chance that either nlocktime or nsequence will be chosen. If a specific condition is met and randint(10) == 0, the function sets transaction.nlocktime to max(0, transaction.nlocktime - randint(0, 99)). If not, it randomly selects an input index and sets transaction.inputs[input_index].nsequence to transaction.inputs[input_index].confirmations(). Similarly, if the condition is met and randint(10) == 0, the function sets transaction.inputs[input_index].nsequence to max(0, transaction.inputs[input_index].nsequence - randint(0, 99)).The bitcoin-dev mailing list recently discussed potential amendments to BIP68, which focuses on the use of nSequence in transaction inputs. The current proposal states that nSequence should only apply to the first input when multiple inputs are present. However, participants in the discussion highlighted complications that could arise for protocols like DLC and dual funded lightning, where input ordering is unknown until both parties reveal their inputs. To address these concerns, it was suggested that the BIP be revised to state that "at least one of the inputs of the transaction" should have nSequence applied, and on-chain wallets should randomly select an input when applying nSequence. These changes would also impact CoinJoins and transactions involving multiple parties contributing inputs.The article emphasizes the potential complications that could arise from limiting nSequence to the first input of a transaction with multiple inputs. This issue could affect protocols like DLC and dual funded lightning, where input ordering is not known until all inputs are revealed. To ensure compatibility with these protocols, it is proposed that nSequence should apply to "at least one of the inputs of the transaction" instead of just the first input.The proposal introduces a new type of wallet behavior using BIP341 taproot, which enhances anonymity for off-chain protocols utilizing point-time-locked contracts (PTLCs) such as CoinSwap, Lightning, and Discrete Log Contracts. By incorporating nSequence in taproot transactions, on-chain wallets like Bitcoin Core can improve the privacy and fungibility of bitcoin. The proposal suggests using nSequence instead of nLockTime anti-fee-sniping protection, as nSequence values are currently uncommon and would designate off-chain settlement transactions as ordinary spend transactions. It is crucial for the community and wallet developers to implement this proposal to build up the anonymity set of nSequence transactions alongside the adoption of taproot by wallets. Fee sniping poses hypothetical challenges to Bitcoin mining in a low-inflation future, and anti-fee-sniping protection using nLockTime or nSequence contributes to pushing the blockchain forward. While nLockTime is currently used, it presents absolute lock time, whereas many off-chain protocols employ relative lock times. Hence, both nLockTime and nSequence should be utilized, with wallets choosing either an nLockTime value or nSequence values to discourage fee sniping. When creating transactions involving UTXOs protected by BIP341 taproot, wallets should also include a second random branch that sets the nLockTime or nSequence value further back. This enhances privacy for transactions that are delayed after signing due to factors like high-latency mix networks. If the UTXOs being spent have more than 65535 confirmations, wallets should use nLockTime instead of nSequence. It is important to note that this proposal does not require consensus changes and can be adopted gradually by wallets. However, for greater privacy, it is recommended for software to adopt it as soon as possible during the implementation of taproot wallets. By doing so, taproot adoption will already incorporate the nSequence code. More information on this proposal can be found in the provided references.
Updated on: 2023-08-02T03:59:33.810647+00:00