đź“… Original date posted:2021-12-09
đź“ť Original message: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?
Alex
On Thu, Dec 9, 2021 at 5:23 AM Peter Todd <pete at petertodd.org> wrote:
> On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> > pete at petertodd.org, so single use seals require an onchain transaction
> to
> > post the proof of publication to the ledger (assuming bitcoin is used as
> > the ledger) when an asset is transferred, but it can scale because you
> can
> > batch many proofs (transfer of ownerships) into a merkle tree and just
> add
> > the merkle root into the single tx going into the ledger?
>
> Exactly. And since the aggregation is trustless with respect to validity,
> users
> can choose what kind of censorship risk they're willing to take (as well as
> mitigate it with "multisig" schemes that use multiple aggregators in
> parallel).
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211209/0a9cde55/attachment.html>;
Alex Schoof [ARCHIVE] /
npub1l2…t6swn
2023-06-07 23:00:53
in reply to nevent1q…g2e6
Author Public Key
npub1l2nulj0wpjdkjj2t6ajqcsxjvm8u4c42qzdgnsa7x6p9hzgqan7q9t6swnPublished at
2023-06-07 23:00:53Event JSON
{
"id": "eed53c9100b41e9c36615649d1afc52fc5d26c11458f9535b81fe5d8a9d64a88",
"pubkey": "faa7cfc9ee0c9b69494bd7640c40d266cfcae2aa009a89c3be36825b8900ecfc",
"created_at": 1686178853,
"kind": 1,
"tags": [
[
"e",
"97b5e00e1be3178d6cf7aa01780cf6ce95fda0db98cd98076f9fdb70146b4136",
"",
"root"
],
[
"e",
"d9259d87b792f33c2c0d9667ae96d876391783bbeabe468c0627ced493644bb8",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2021-12-09\n📝 Original message:The multisig scheme is interesting. From my understanding of Single Use\nSeals, since seal n commits to seal n+1, for the on-chain aggregation seals\nyou would want to pick some common aggregation service provider ahead of\ntime and if that provider disappears, you’re stuck and cant close the next\nseal. If instead you say “this seal commits to three of the five of these\nnext seals” then you mitigate both availability and censorship risk. Am I\ngetting that right?\n\nAlex\n\nOn Thu, Dec 9, 2021 at 5:23 AM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:\n\u003e \u003e pete at petertodd.org, so single use seals require an onchain transaction\n\u003e to\n\u003e \u003e post the proof of publication to the ledger (assuming bitcoin is used as\n\u003e \u003e the ledger) when an asset is transferred, but it can scale because you\n\u003e can\n\u003e \u003e batch many proofs (transfer of ownerships) into a merkle tree and just\n\u003e add\n\u003e \u003e the merkle root into the single tx going into the ledger?\n\u003e\n\u003e Exactly. And since the aggregation is trustless with respect to validity,\n\u003e users\n\u003e can choose what kind of censorship risk they're willing to take (as well as\n\u003e mitigate it with \"multisig\" schemes that use multiple aggregators in\n\u003e parallel).\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-- \n\n\nAlex Schoof\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211209/0a9cde55/attachment.html\u003e",
"sig": "5a761e76a4746ecf4627c07cae4cc7079b100dd894621c51763338e81abd6fc62087d2ee0b85ea64e58cf2cdb1c718d9a42e6c5400f729d2703f5eeca3b8cafe"
}