Good morning Antoine, > TLUV doesn't assume cooperation among the construction participants once the > Taproot tree is setup. EVICT assumes cooperation among the remaining > construction participants to satisfy the final CHECKSIG. > > So that would be a feature difference between TLUV and EVICT, I think ?
`OP_TLUV` leaves the transaction output with the remaining Tapleaves intact, and, optionally, with a point subtracted from Taproot internal pubkey. In order to *truly* revive the construct, you need a separate transaction that spends that change output, and puts it back into a new construct. See: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html I describe how this works. That `OP_EVICT` does another `CHECKSIG` simply cuts through the separate transaction that `OP_TLUV` would require in order to revive the construct. > > I thought it was part of Taproot? > > I checked BIP342 again, *as far as I can read* (unreliable process), it > sounds like it was proposed by BIP118 only. *shrug* Okay! > > A single participant withdrawing their funds unilaterally can do so by > > evicting everyone else (and paying for those evictions, as sort of a > > "nuisance fee"). > > I see, I'm more interested in the property of a single participant > withdrawing their funds, without affecting the stability of the off-chain > pool and without cooperation with other users. This is currently a > restriction of the channel factories fault-tolerance. If one channel goes > on-chain, all the outputs are published. See also: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html Generally, the reason for a channel to go *onchain*, instead of just being removed inside the channel factory and its funds redistributed elsewhere, is that an HTLC/PTLC is about to time out. The blockchain is really the only entity that can reliably enforce timeouts. And, from the above link: > * If a channel has an HTLC/PTLC time out: > * If the participant to whom the HTLC/PTLC is offered is > offline, that may very well be a signal that it is unlikely > to come online soon. > The participant has strong incentives to come online before > the channel is forcibly closed due to the HTLC/PTLC timeout, > so if it is not coming online, something is very wrong with > that participant and we should really evict the participant. > * If the participant to whom the HTLC/PTLC is offered is > online, then it is not behaving properly and we should > really evict the participant. Note the term "evict" as well --- the remaining participants that are presumably still behaving correctly (i.e. not letting HTLC/PTLC time out) evict the participants that *are*, and that is what `OP_EVICT` does, as its name suggests. Indeed, I came up with `OP_EVICT` *after* musing the above link. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
