Author: Johnson Lau 2019-02-09 16:48:40
Published on: 2019-02-09T16:48:40+00:00
The article explores different types of settlement transactions in a 3-party channel with varying balances. There are three types of settlements, namely simple, fully combinatorial, and partially combinatorial. The focus is on the fully combinatorial settlement type that allows any two parties to trade with each other as long as there is enough liquidity in their branch channel.Multi-sig outputs in this model are eltoo-style scripts, and A and B further distribute the value of (A & B) by a 2-party eltoo channel. One benefit of this model is that it allows the three parties to re-distribute the channel capacities without closing any channels if they are all online simultaneously. However, the increased costs of uncooperative settlement is a problem, and the number of settlement transactions will grow factorially in a fully hierarchical settlement model.To prevent this catastrophic event, the group needs to continuously evaluate the risks of each party being missing and modify the settlement model accordingly. In some cases, the other parties might not be able to continue until the unresponsive party returns. An eltoo-like protocol that works if you can't predict in advance who will become absent would be 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.The bitcoin-dev mailing list has seen discussions around the use of output tagging in multiparty eltoo channels and its impact on fungibility. Output tagging can be used to remove an unresponsive party from a channel without downtime by creating settlement transactions that pay off the unresponsive party and fund a new channel with the remaining participants.However, the use of SIGHASH_NOINPUT and NOINPUT tagged funding output in eltoo channels may result in reduced fungibility as it can lead to accidental double payments and signature replay risks. To mitigate this risk, outputs must be explicitly tagged by the payer for them to be spendable with NOINPUT.Two possible ways of tagging have been proposed: setting a certain bit in the tx version or scriptPubKey. Tagging with scriptPubKey offers per-output basis tagging but is only possible with native-segwit, meaning P2SH-segwit addresses would become 'risky' for payers. Tagging with tx version protects P2SH-segwit and existing wallets are protected by default, but it is a layer violation and all outputs in the same tx must be tagged.Additionally, an extension to the version tagging can make NOINPUT safer by signing the version of the previous transaction. The use of output tagging in eltoo channels does not complicate the protocol nor bring any extra block space overhead. However, upgrading all existing bech32 implementations to refuse sending to tagged addresses by default may be necessary.Overall, output tagging in eltoo channels can provide additional smart contract capacity while minimizing the risks of misuse, but careful consideration and analysis of the pros and cons of different tagging methods are required to ensure compatibility with other proposals that require NOINPUT and prevent adverse effects on fungibility.
Updated on: 2023-05-20T18:51:54.777575+00:00