ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-18 📝 Original message: Good morning, Sent with ...
📅 Original date posted:2019-05-18
📝 Original message:
Good morning,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 16, 2019 3:55 PM, Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Thanks for your answers and links, the previous discussions probably happened before I joined this list so I'll go dig into the archive ;)
>
> > I think it makes sense for us to consider both variants, one committing
> > to the script and the other not committing to the script, but I think it
> > applies rather to the `update_tx` <-> `settlement_tx` link and less to
> > the `funding_tx` <-> `update_tx` link and `update_tx` <-> `update_tx`
> > link. The reason is that the `settlement_tx` needs to be limited to be
> > bindable only to the matching `update_tx` (`anyprevout`), while
> > `update_tx` need to be bindable to the `funding_tx` as well as any prior
> > `update_tx` which differ in the script by at least the state number
> > (hence `anyprevoutanyscript`).
>
> > Like AJ pointed out in another thread, the use of an explicit trigger
> > transaction is not really needed since any `update_tx` can act as a
> > trigger transaction (i.e., start the relative timeouts to tick).
>
> Thanks for confirming, that was how I understood it too.
>
> > Specifically we can't make make use of the collaborative path where
> > we override an `update_tx` with a newer one in taproot as far as I can
> > see, since the `update_tx` needs to be signed with noinput (for
> > rebindability) but there is no way for us to specify the chaperone key
> > since we're not revealing the committed script.
>
> Can you expand on that? Why do we need to "make use of the collaborative path" (maybe it's unclear to me what you mean by collaborative path here)?
The collaborative path is the use of the taproot-tweaked public key to sign, without revealing any scripts.
The bip-taproot proposal specifically disallows all `SIGHASH` that is not the current set of valid `SIGHASH` flags when using this path, and thus does not include `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
New `SIGHASH` types *are* allowed in bip-tapscript (i.e. when signing for a `OP_CHECKSIG` variant inside a taproot script), and this is where the proposal of aj builds upon.
For myself, I do not see any point in using the collaborative path unless we are cooperatively closing anyway.
And once we are cooperatively closing, we can agree to spend the funding txo without requiring that `SIGHASH_ANYPREVOUT` be used (since we already have fallbacks in case of cooperation failure, i.e. the existing update/settlement txes).
So again I do not see this to be an issue.
(I could be wrong)
Regards,
ZmnSCPxj
📝 Original message:
Good morning,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 16, 2019 3:55 PM, Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Thanks for your answers and links, the previous discussions probably happened before I joined this list so I'll go dig into the archive ;)
>
> > I think it makes sense for us to consider both variants, one committing
> > to the script and the other not committing to the script, but I think it
> > applies rather to the `update_tx` <-> `settlement_tx` link and less to
> > the `funding_tx` <-> `update_tx` link and `update_tx` <-> `update_tx`
> > link. The reason is that the `settlement_tx` needs to be limited to be
> > bindable only to the matching `update_tx` (`anyprevout`), while
> > `update_tx` need to be bindable to the `funding_tx` as well as any prior
> > `update_tx` which differ in the script by at least the state number
> > (hence `anyprevoutanyscript`).
>
> > Like AJ pointed out in another thread, the use of an explicit trigger
> > transaction is not really needed since any `update_tx` can act as a
> > trigger transaction (i.e., start the relative timeouts to tick).
>
> Thanks for confirming, that was how I understood it too.
>
> > Specifically we can't make make use of the collaborative path where
> > we override an `update_tx` with a newer one in taproot as far as I can
> > see, since the `update_tx` needs to be signed with noinput (for
> > rebindability) but there is no way for us to specify the chaperone key
> > since we're not revealing the committed script.
>
> Can you expand on that? Why do we need to "make use of the collaborative path" (maybe it's unclear to me what you mean by collaborative path here)?
The collaborative path is the use of the taproot-tweaked public key to sign, without revealing any scripts.
The bip-taproot proposal specifically disallows all `SIGHASH` that is not the current set of valid `SIGHASH` flags when using this path, and thus does not include `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
New `SIGHASH` types *are* allowed in bip-tapscript (i.e. when signing for a `OP_CHECKSIG` variant inside a taproot script), and this is where the proposal of aj builds upon.
For myself, I do not see any point in using the collaborative path unless we are cooperatively closing anyway.
And once we are cooperatively closing, we can agree to spend the funding txo without requiring that `SIGHASH_ANYPREVOUT` be used (since we already have fallbacks in case of cooperation failure, i.e. the existing update/settlement txes).
So again I do not see this to be an issue.
(I could be wrong)
Regards,
ZmnSCPxj