ZmnSCPxj [ARCHIVE] on Nostr: š
Original date posted:2019-03-13 š Original message: Good morning aj, First ...
š
Original date posted:2019-03-13
š Original message:
Good morning aj,
First off, I have little to no idea of the issues at the lower-level Bitcoin.
In any case ---
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.
>
> This is a bit more costly than a key path spend: you have to reveal
> the taproot point to do a script (+33B) and you have two signatures
> instead of one (+65B) and you have to reveal two keys as well
> (+66B), plus some script overhead. If we did the <P,Q> variant,
> we could provide a "PUSH_TAPROOT_KEY" opcode that would just push
> the taproot key to stack, saving 33B from pushing P as a literal,
> but you can't do much better than that. All in all, it'd be about 25%
> overhead in order to prevent cheating. [0]
>
> I think that output tagging doesn't provide a workable defense against the
> third party malleability via a deeper-than-the-CSV-delay reorg mentioned
> earlier; but requiring a non-NOINPUT sig does: you'd have to replace
> the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,
> and only the holders of the appropriate private key can do that.
At my point of view, if a NONINPUT sig is restricted and cannot be used to spend an "ordinary" 2-of-2, this is output tagging regardless of exact mechanism.
So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is still output tagging, as a cooperative close would still reveal that the output is not a 2-of-2.
Ideally, historical data of whether onchain coin was used in Lightning or not should be revealed as little as possible.
So in a cooperative close (which we hope, to be a common case), ideally the spend should look no different from an ordinary 2-of-2 spend.
Of course if the channel is published on Lightning, those who participated in Lightning at the time will learn of it, but at least the effort to remember this information is on those who want to remember this fact.
Now, this can be worked around by adding a "kickoff" transaction that spends the eltoo setup transaction.
The eltoo setup transaction outputs to an ordinary 2-of-2.
The kickoff outputs to an output that allows NOINPUT.
Then the rest of the protocol anchors on top of the kickoff.
The kickoff is kept offchain, until a non-cooperative close is needed.
Of course, as it is not a NOINPUT itself, it must need onchain fees attached to it.
This of course complicates fees, as we know.
Alternately maybe the kickoff can be signed with `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` so that it is possible to add a fee-paying UTXO to it.
Regards,
ZmnSCPxj
Published at
2023-06-09 12:54:26Event JSON
{
"id": "cbc28c1efa367f75535c7bf48edf692f68d2f0d0c474883b575f7b1a5210e5e8",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315266,
"kind": 1,
"tags": [
[
"e",
"86a47a61621252784fd45b6d576812ee01ce9af9bd2a53aeaae914577c5267a8",
"",
"root"
],
[
"e",
"bb5657db602bc52a246c706ab3af3e3af8b402ddd2daad6f50c1dc6ad38da7be",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2019-03-13\nš Original message:\nGood morning aj,\n\nFirst off, I have little to no idea of the issues at the lower-level Bitcoin.\n\nIn any case ---\n\n\u003e - alternatively, we could require every script to have a valid signature\n\u003e that commits to the input. In that case, you could do eltoo with a\n\u003e script like either:\n\u003e\n\u003e \u003cA\u003e CHECKSIGVERIFY \u003cB\u003e CHECKSIG\n\u003e or \u003cP\u003e CHECKSIGVERIFY \u003cQ\u003e CHECKSIG\n\u003e\n\u003e\n\u003e where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is\n\u003e a key they both know the private key for. In the first case, Alice\n\u003e would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish\n\u003e Bob would just do a SIGHASH_ALL sig with his own key. In the second,\n\u003e Alice and Bob would share partial NOINPUT sigs of the tx with P, and\n\u003e finish that when they wanted to publish.\n\u003e\n\u003e This is a bit more costly than a key path spend: you have to reveal\n\u003e the taproot point to do a script (+33B) and you have two signatures\n\u003e instead of one (+65B) and you have to reveal two keys as well\n\u003e (+66B), plus some script overhead. If we did the \u003cP,Q\u003e variant,\n\u003e we could provide a \"PUSH_TAPROOT_KEY\" opcode that would just push\n\u003e the taproot key to stack, saving 33B from pushing P as a literal,\n\u003e but you can't do much better than that. All in all, it'd be about 25%\n\u003e overhead in order to prevent cheating. [0]\n\u003e\n\u003e I think that output tagging doesn't provide a workable defense against the\n\u003e third party malleability via a deeper-than-the-CSV-delay reorg mentioned\n\u003e earlier; but requiring a non-NOINPUT sig does: you'd have to replace\n\u003e the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,\n\u003e and only the holders of the appropriate private key can do that.\n\nAt my point of view, if a NONINPUT sig is restricted and cannot be used to spend an \"ordinary\" 2-of-2, this is output tagging regardless of exact mechanism.\nSo the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is still output tagging, as a cooperative close would still reveal that the output is not a 2-of-2.\n\nIdeally, historical data of whether onchain coin was used in Lightning or not should be revealed as little as possible.\nSo in a cooperative close (which we hope, to be a common case), ideally the spend should look no different from an ordinary 2-of-2 spend.\nOf course if the channel is published on Lightning, those who participated in Lightning at the time will learn of it, but at least the effort to remember this information is on those who want to remember this fact.\n\nNow, this can be worked around by adding a \"kickoff\" transaction that spends the eltoo setup transaction.\nThe eltoo setup transaction outputs to an ordinary 2-of-2.\nThe kickoff outputs to an output that allows NOINPUT.\nThen the rest of the protocol anchors on top of the kickoff.\n\nThe kickoff is kept offchain, until a non-cooperative close is needed.\nOf course, as it is not a NOINPUT itself, it must need onchain fees attached to it.\nThis of course complicates fees, as we know.\nAlternately maybe the kickoff can be signed with `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` so that it is possible to add a fee-paying UTXO to it.\n\nRegards,\nZmnSCPxj",
"sig": "764de516b33077c33c7e4a186bf3f7fbaafe8e6741571718bb50a7790e42dca6a9d730e659fac4eb009478b1f8342bfb89d24f0d5d643adc2ee44a6595e2d64e"
}