From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`
Date: Wed, 23 Feb 2022 11:42:54 +0000 [thread overview]
Message-ID: <EoJPTKIHFCBpB505PNjhQp3Iuou-FhQqNwzqVOvFh5W2qx_d0phXLuVPGdjQhYqEma6BX1TfDxRQ1XpCaqZQPF2PWMhTnyTrEnkmtKFpmnw=@protonmail.com> (raw)
In-Reply-To: <CALZpt+EUm06LxMmaQd0wxZ5cNtE_+jCQUWDmVrGTJx6ADQT4mA@mail.gmail.com>
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
prev parent reply other threads:[~2022-02-23 11:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 2:45 ZmnSCPxj
2022-02-18 13:53 ` Erik Aronesty
2022-02-18 14:48 ` ZmnSCPxj
2022-02-18 15:50 ` Erik Aronesty
2022-02-18 16:06 ` ZmnSCPxj
2022-02-18 13:55 ` Jonas Nick
2022-02-18 18:09 ` Antoine Riard
2022-02-18 23:39 ` ZmnSCPxj
2022-02-19 0:56 ` Jeremy Rubin
2022-02-19 1:17 ` ZmnSCPxj
2022-02-19 1:46 ` Greg Sanders
2022-02-19 7:21 ` Billy Tetrud
2022-02-19 11:41 ` ZmnSCPxj
2022-02-19 21:59 ` Billy Tetrud
2022-02-22 0:17 ` Antoine Riard
2022-02-23 11:42 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='EoJPTKIHFCBpB505PNjhQp3Iuou-FhQqNwzqVOvFh5W2qx_d0phXLuVPGdjQhYqEma6BX1TfDxRQ1XpCaqZQPF2PWMhTnyTrEnkmtKFpmnw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox