đź“… Original date posted:2021-12-09
đź“ť Original message:
On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote:
> The multisig scheme is interesting. From my understanding of Single Use
> Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
> you would want to pick some common aggregation service provider ahead of
> time and if that provider disappears, you’re stuck and cant close the next
> seal. If instead you say “this seal commits to three of the five of these
> next seals” then you mitigate both availability and censorship risk. Am I
> getting that right?
Re: "some common aggregation service provider", you might be misunderstanding
the protocol: since seals are trustless with regard to validity, I can validate
your seal, regardless of which aggregation service you use.
But other than that, I think we're on the same page!
A concrete example would be an exchange: they do a lot of transactions, so they
could choose to be their own aggregator, and wouldn't need any multisig at all
because they can trust themselves not to censor themselves. :) Meanwhile, one
of their customers might use 3-of-5 as you suggest, as they only do a few
transactions a month.
Interestingly, in some scenarios it might be worthwhile to both run your own
aggregator, and use multisig. Eg Alice could use a 2-of-3 with two third-party
aggregators, and her own aggregation chain. If both third-parties are up, she
does no on-chain transactions at all; if one third-party is down, she can use
her own, and the remaining third-party. Thus she would only do an on-chain
transaction to defeat censorship/failure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/6edd19ec/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-09 13:04:35
in reply to nevent1q…65xp
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-09 13:04:35Event JSON
{
"id": "b403a998d6c84cde1ed444b527f6df552bc9b8ad453db1f100d57bf8cbaa7f9b",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686315875,
"kind": 1,
"tags": [
[
"e",
"b46f2057db0272a7ba31a2acb3724df48f19ce432b6c7cfa249ce761de951d4f",
"",
"root"
],
[
"e",
"603c4cac9327152c984b76c66c37d70906d9bd2d2b82e45bc2a8943eb8e826f6",
"",
"reply"
],
[
"p",
"faa7cfc9ee0c9b69494bd7640c40d266cfcae2aa009a89c3be36825b8900ecfc"
]
],
"content": "📅 Original date posted:2021-12-09\n📝 Original message:\nOn Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote:\n\u003e The multisig scheme is interesting. From my understanding of Single Use\n\u003e Seals, since seal n commits to seal n+1, for the on-chain aggregation seals\n\u003e you would want to pick some common aggregation service provider ahead of\n\u003e time and if that provider disappears, you’re stuck and cant close the next\n\u003e seal. If instead you say “this seal commits to three of the five of these\n\u003e next seals” then you mitigate both availability and censorship risk. Am I\n\u003e getting that right?\n\nRe: \"some common aggregation service provider\", you might be misunderstanding\nthe protocol: since seals are trustless with regard to validity, I can validate\nyour seal, regardless of which aggregation service you use.\n\nBut other than that, I think we're on the same page!\n\nA concrete example would be an exchange: they do a lot of transactions, so they\ncould choose to be their own aggregator, and wouldn't need any multisig at all\nbecause they can trust themselves not to censor themselves. :) Meanwhile, one\nof their customers might use 3-of-5 as you suggest, as they only do a few\ntransactions a month.\n\nInterestingly, in some scenarios it might be worthwhile to both run your own\naggregator, and use multisig. Eg Alice could use a 2-of-3 with two third-party\naggregators, and her own aggregation chain. If both third-parties are up, she\ndoes no on-chain transactions at all; if one third-party is down, she can use\nher own, and the remaining third-party. Thus she would only do an on-chain\ntransaction to defeat censorship/failure.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/6edd19ec/attachment.sig\u003e",
"sig": "5f8444710ae19e34f058a3d17d6fbc7ab5d4d75c7ddff934e812714d4b63fd3af4bfd11ac259a7bab7dc828e483b4c3306a8dd2291543a0f5ce6713304f0f9a0"
}