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 <p...@petertodd.org> wrote: > On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote: > > p...@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
