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 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> pete@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Alex Schoof