📅 Original date posted:2022-02-18
📝 Original message:Good morning Erik,
> > As I understand your counterproposal, it would require publishing one transaction per evicted participant.
>
> if you also pre-sign (N-2, N-3, etc), you can avoid this
It also increases the combinatorial explosion.
> > In addition, each participant has to store `N!` possible orderings in which participants can be evicted, as you cannot predict the future and cannot predict which partiicpants will go offline first.
>
> why would the ordering matter? these are unordered pre commitments to move funds, right? you agree post the one that represents "everyone that's offline"
Suppose `B` is offline first, then the remaining `A` `C` and `D` publish the eviction transaction that evicts only `B`.
What happens if `C` then goes offline?
We need to prepare for that case (and other cases where the participants go offline at arbitrary orders) and pre-sign a spend from the `ACD` set and evicts `C` as well, increasing combinatorial explosion.
And so on.
We *could* use multiple Tapleaves, of the form `<A> OP_CHECKSIG <BCD> OP_CHECKSIG` for each participant.
Then the per-participant `<A>` signature is signed with `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `<BCD>` with default `SIGHASH_ALL`.
Then if one participant `B` is offline they can evict `B` and then the change is put into a new UTXO with a similar pre-signed scheme `<A> OP_CHECKSIG <CD> OP_CHECKSIG`.
This technique precludes pre-signing multiple evictions.
>
> > But yes, certainly that can work, just as pre-signed transactions can be used instead of `OP_CTV`
>
> i don't see how multiple users can securely share a channel (allowing massive additional scaling with lighting) without op_ctv
They can, they just pre-sign, like you pointed out.
The same technique works --- `OP_CTV` just avoids having ridiculous amounts of combinatorial explosion and just requires `O(log n)` per eviction.
Remember, this proposal can be used for channel factories just as well, as pointed out, so any objection to this proposal also applies to `OP_CTV`.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-07 23:04:31
in reply to nevent1q…mfhw
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 23:04:31Event JSON
{
"id": "0b3e80e2c26d28e742b2caf673f269a82cfdd043373e93b52f8b78b87b5d9262",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686179071,
"kind": 1,
"tags": [
[
"e",
"5fe4c1ba6946d2f34766b22b464f89bbe95cc399bd5effb836c23d627bbd5700",
"",
"root"
],
[
"e",
"83456352cf43bc5dcbc087b8364abfd887d308e8a24a55c3fc814f60b3bc103f",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2022-02-18\n📝 Original message:Good morning Erik,\n\n\u003e \u003e As I understand your counterproposal, it would require publishing one transaction per evicted participant.\n\u003e\n\u003e if you also pre-sign (N-2, N-3, etc), you can avoid this\n\nIt also increases the combinatorial explosion.\n\n\u003e \u003e In addition, each participant has to store `N!` possible orderings in which participants can be evicted, as you cannot predict the future and cannot predict which partiicpants will go offline first.\n\u003e\n\u003e why would the ordering matter? these are unordered pre commitments to move funds, right? you agree post the one that represents \"everyone that's offline\"\n\nSuppose `B` is offline first, then the remaining `A` `C` and `D` publish the eviction transaction that evicts only `B`.\nWhat happens if `C` then goes offline?\nWe need to prepare for that case (and other cases where the participants go offline at arbitrary orders) and pre-sign a spend from the `ACD` set and evicts `C` as well, increasing combinatorial explosion.\nAnd so on.\n\nWe *could* use multiple Tapleaves, of the form `\u003cA\u003e OP_CHECKSIG \u003cBCD\u003e OP_CHECKSIG` for each participant.\nThen the per-participant `\u003cA\u003e` signature is signed with `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` and is pre-signed, while the remainder is signed by `\u003cBCD\u003e` with default `SIGHASH_ALL`.\nThen if one participant `B` is offline they can evict `B` and then the change is put into a new UTXO with a similar pre-signed scheme `\u003cA\u003e OP_CHECKSIG \u003cCD\u003e OP_CHECKSIG`.\nThis technique precludes pre-signing multiple evictions.\n\n\u003e\n\u003e \u003e But yes, certainly that can work, just as pre-signed transactions can be used instead of `OP_CTV` \n\u003e\n\u003e i don't see how multiple users can securely share a channel (allowing massive additional scaling with lighting) without op_ctv\n\nThey can, they just pre-sign, like you pointed out.\nThe same technique works --- `OP_CTV` just avoids having ridiculous amounts of combinatorial explosion and just requires `O(log n)` per eviction.\nRemember, this proposal can be used for channel factories just as well, as pointed out, so any objection to this proposal also applies to `OP_CTV`.\n\n\n\nRegards,\nZmnSCPxj",
"sig": "2dad8e438adb9b524db6c7de660233544b5afddae8db7db68f3862d41f5651c95afa45bc50fd746d12a4fb6d16081f3ead8964fe0aea5056d07d675556086e29"
}