Published on: 2020-02-25T19:16:03+00:00
In a recent email exchange between ZmnSCPxj and Antoine, the discussion focused on various topics related to Lightning Network (LN) and Bitcoin. One topic explored was the possibility of splicing as a form of merged closing plus funding, which would require changing the short channel ID and channel ID for compatibility purposes. The conversation also touched on the need for an alias to maintain channel routing-score across splicing. Privacy concerns were raised in relation to Coinjoin traffic, with the suggestion that redirecting it through LN could potentially enhance privacy properties in the future.The controversy surrounding Replace-By-Fee (RBF) was another point of discussion. ZmnSCPxj proposed that RBF should always be turned on, even if there is no facility to re-interact and increase fees. This would force surveillors to record information themselves, although merchants who refuse RBF transactions may complain. Another issue highlighted was the incentive for participants in MuSig to only broadcast the highest-fee version if not all participants contribute equally to fees.The conversation then shifted towards the importance of nailing down details of a format that could be used by other protocols such as submarine swaps and lightning loops. Splicing was further explored as a potential solution to address liquidity reasons in LN nodes and its impact on CoinJoin spending delta versus LN ones.In a separate discussion on the Bitcoin-dev mailing list, Antoine asked how a Bitcoin transaction could leak protocol usage. Several factors were identified, including output type, spending policy, outputs ordering, nLocktime/nSequence, RBF-signaling, equal-value outputs, weird watermark, fees strategy like CPFP, and in-protocol announcements. The utxo selection algorithm and nVersion were also mentioned as possible sources of leakage. CoinJoinXT was suggested as a potential privacy enhancement solution in a Taproot/Schnorr world. It allows participants to arrange the effect of CoinJoin without the on-chain watermark through a short interaction, with multisig requiring Taproot/Schnorr.On the Lightning-dev mailing list, ZmnSCPxj discussed the use of nLocktime and a weird watermark on unilateral closes in LN channels. HTLCs were noted to only exist on unilateral closes, while mutual closes wait for HTLCs to settle before closing. ZmnSCPxj also provided links for further reading on the difficulties with unilateral closes. The post addressed questions about protocol-specific semantic incompatibility between CoinJoin and cooperative LN transactions, RBF-by-default, and artificially increasing the number of outputs to mimic CoinJoin transactions.Furthermore, the issue of coinjoin interceptions and their detection by chain observers was raised. While banning coinjoined coins or any other coins linked through a common owner would undermine long-term fungibility, it was suggested that all on-chain transactions should conform to a common transaction pattern that provides unobservability. The adoption of a common transaction format could help blur multiple protocol on-chain transactions and circumvent potential bans. Questions were posed regarding the compatibility of this format with various protocols, including Coinjoin and cooperative LN transactions, as well as concerns about utxo bloat/fees resulting from artificially increasing the number of outputs to mimic Coinjoin transactions.Overall, the discussions revolved around exploring various aspects of Lightning Network, CoinJoin, privacy enhancement, RBF, splicing, and the need for a common transaction format to enhance unobservability.
Updated on: 2023-08-02T01:51:40.449154+00:00