Safer NOINPUT with output tagging

Summary:

The bitcoin-dev mailing list recently discussed the use of output tagging in multiparty eltoo channels, which can result in reduced fungibility. The discussion centered around settling a three-party channel where A, B, and C have respective balances of 2, 3, and 6 BTC. One proposal suggested establishing a channel factory of three or more members protected by an n-of-n multisig output. The factory contains direct spends to members, lightning channels between pairs of members, and channel factories between subgroups of members. When initially set up, the factory has direct spends to each member, matching the amount they contributed. Lightning channels or sub-factories can be created on-chain, which is the same decision. Updates to transactions in a lightning channel or sub-factory do not generally involve updating the containing factory. However, NOINPUT impacts channel factories because cheating could come from any member of the group; therefore, a commitment to the state that's spendable only by any later state, and is then redeemed after a timelock is workable.If one cannot get all group members to cooperatively close, closing a factory means publishing it to the blockchain. The settlement tx has to spend with a NOINPUT sig since the state commitment could have had to spend different things. Tagging NOINPUT-spendable outputs would mean tagging state commitment outputs and settlement tx outputs if they're lightning channels or sub-factories. An eltoo-like protocol that works without going on-chain if you can't predict in advance who will become absent is a childchain. If other parties' signatures must not be required, there must be a way of having a common verifiable 'last state' to prevent a party from simultaneously forking the state with two different parties and double-spending.It was suggested that if one party is unresponsive in the multiparty eltoo channels, the remaining participants can remove them from the channel without downtime by creating settlement transactions which pay off the unresponsive party and fund a new channel with the remaining ones. However, in eltoo the settlement txid is not final, therefore the funding output of the new channel must be NOINPUT tagged. If the expectation is that the unresponsive party returns, fungibility is not reduced due to output tagging because the scheme can be used off-chain until the original channel can be continued.The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging: a certain bit in the tx version must be set or a certain bit in the scriptPubKey must be set. A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. Tagging with tx version will protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx.NOINPUT brings more smart contract capacity, and at the same time, one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts wanted, while minimizing the risks of misuse. The risk being mitigated is a payer mistakenly paying to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is common. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT).

Updated on: 2023-05-20T18:47:57.849363+00:00