📅 Original date posted:2019-05-20
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
>> 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)
You are correct. I forgot that the updates, besides being signed by both
parties, also need to enforce the correct ordering through the CLTV
opcode which cannot be part of the key path (thanks AJ for the correct
name). Hence only collaborative closes can use the key path, which means
we sadly don't gain much from using taproot in the update-settlement
structure, i.e., the unilateral case is always visible on-chain.
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:55:02
in reply to nevent1q…jkkv
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:55:02Event JSON
{
"id": "882a02f1b6b909914d63147a903df1a7f6938e993e8e30b7500f807ea1c30dba",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315302,
"kind": 1,
"tags": [
[
"e",
"b22173092cbd165b2936a26ab2149ed70db928dfd0cf654a4602754ec10a6751",
"",
"root"
],
[
"e",
"a90b9f524f5917ed4aea4df1a5367a0cf4a9fd014584d597f8f0339c9cea1fa8",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-05-20\n📝 Original message:\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\n\u003e\u003e Can you expand on that? Why do we need to \"make use of the\n\u003e\u003e collaborative path\" (maybe it's unclear to me what you mean by\n\u003e\u003e collaborative path here)?\n\u003e\n\u003e The collaborative path is the use of the taproot-tweaked public key to\n\u003e sign, without revealing any scripts. The bip-taproot proposal\n\u003e specifically disallows all `SIGHASH` that is not the current set of\n\u003e valid `SIGHASH` flags when using this path, and thus does not include\n\u003e `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.\n\u003e\n\u003e New `SIGHASH` types *are* allowed in bip-tapscript (i.e. when signing\n\u003e for a `OP_CHECKSIG` variant inside a taproot script), and this is\n\u003e where the proposal of aj builds upon.\n\u003e\n\u003e For myself, I do not see any point in using the collaborative path\n\u003e unless we are cooperatively closing anyway. And once we are\n\u003e cooperatively closing, we can agree to spend the funding txo without\n\u003e requiring that `SIGHASH_ANYPREVOUT` be used (since we already have\n\u003e fallbacks in case of cooperation failure, i.e. the existing\n\u003e update/settlement txes). So again I do not see this to be an issue.\n\u003e (I could be wrong)\n\nYou are correct. I forgot that the updates, besides being signed by both\nparties, also need to enforce the correct ordering through the CLTV\nopcode which cannot be part of the key path (thanks AJ for the correct\nname). Hence only collaborative closes can use the key path, which means\nwe sadly don't gain much from using taproot in the update-settlement\nstructure, i.e., the unilateral case is always visible on-chain.\n\nCheers,\nChristian",
"sig": "f440df10ce354309162f82201f7405c0bc26facc0a089992dc6927c1767099799645f72bfb720c28ea628f5b370051569d3c4187e4a5a3b1a59b92bf5b0f230d"
}