Published on: 2019-02-19T20:36:51+00:00
The discussion on the bitcoin-dev mailing list revolves around various aspects of implementing a wallet that prevents address reuse and the compatibility of such a feature with NOINPUT. Johnson Lau suggests that addressing address reuse should be a social agreement between the payer and the payee, as it cannot be banned at the protocol level. He proposes publishing the key after a coin is confirmed as a stronger way to prevent address reuse. Luke Dashjr argues against implementing a nanny in the protocol, stating that it limits developers who want certain features. He also highlights the issue of address reuse rejection when using NOINPUT for everything.The acceptability of address reuse in Bitcoin transactions depends on the contract between the payer and payee and cannot be banned at the protocol level. NOINPUT, which allows multiple transactions to spend the same output, has limitations and risks associated with it. To prevent accidental double payments, Lau suggests tagging outputs to make them spendable with NOINPUT. Two possible ways to tag are discussed: setting a certain bit in the tx version or scriptPubKey. Each method has its advantages and disadvantages. The tradeoff between smart contracts and dumb contracts is also mentioned, with the aim of finding a design that enables desired smart contracts while minimizing misuse risks.The discussion also delves into the compatibility of tagging with multiparty eltoo channels, settlement transactions, and various attack scenarios. Alejandro Ranchal Pedrosa proposes Transaction Fragments as a solution to an eltoo-like protocol that works without going on-chain when participants' actions cannot be predicted in advance. Signature replay risks associated with NOINPUT are addressed, and Lau suggests extending version tagging to enhance NOINPUT safety.Another topic of discussion is the potential impact of tagging on fungibility in multiparty eltoo channels. A solution is proposed where settlement transactions are created with different locktimes, and the branch channel is opened on a tagged output. If cooperative channel closing is desired, it can be done on an untagged output without using NOINPUT to avoid fungibility loss.The bitcoin-dev community plays a vital role in identifying and addressing potential issues related to proposals like NOINPUT and ensuring compatibility between various proposals. The aim is to maintain the stability and security of the Bitcoin network while enabling desired smart contracts and minimizing risks.In a recent email exchange between Christian Decker and Johnson Lau, they discussed the use of OP_CSV (BIP112) in a 2-of-2 branch. It was argued that BIP68 relative locktime is not necessary since both parties need to agree on it. However, with taproot, the use of BIP68 actually saves more than just a few bytes. The conversation also discussed the idea of tagging an output to make it spendable with NOINPUT, which is compatible with eltoo. This would allow for walletless offchain software, where on-chain wallets can directly put their funds into an off-chain system without requiring an on-chain transfer. However, there are concerns regarding address reuse, dual-funding, and the need for a standard way of signing transactions without broadcasting them.The discussion also delved into the process of setting up, updating, and closing a Lightning Network channel using eltoo. This involves creating a setup transaction, followed by update transactions and a settlement transaction. Collaborative close and unilateral close were explained as different scenarios depending on the agreement between parties. The number of transactions involved depends on whether cheating occurs.Johnson Lau further explained the process of setting up and closing a payment channel between two parties using Bitcoin. This involves multiple steps, including creating setup, update, and settlement transactions. The concept of collaborative close and unilateral close was explained, along with the number of transactions involved depending on the scenario.The bitcoin-dev mailing list also discussed the design considerations of a channel setup using BIP118, 143, and 141-P2WSH without taproot. The compatibility of this setup with Statechains was explored, as well as the impact on fungibility if taproot was added. It was clarified that combining the trigger and setup transactions is not currently possible, and the purpose of having separate timeouts would be defeated if they were combined.Concerns were raised about the compatibility of NOINPUT with proposals such as Graftroot and Statechains, as well as the impact on fungibility if Taproot was added to Eltoo. The discussion also explored the use of output tagging and NOINPUT in the context of Eltoo and Statechains. The tradeoff between privacy, complexity, and fungibility was considered.In another email exchange, Johnson Lau discussed the risks of signature replay associated with NOINPUT and proposed a solution of "tagging" outputs that are spendable with NOINPUT. Two possible ways of tagging outputs were mentioned, either by setting a certain bit in the tx version or scriptPubKey. The implications of tagging for fungibility were discussed, along with the advantages and limitations of each tagging method.
Updated on: 2023-08-02T00:18:41.848463+00:00