From: Alex Schoof <alex.schoof@gmail•com>
To: pete@petertodd•org
Cc: "Bitcoin Protocol Discussion"
<bitcoin-dev@lists•linuxfoundation.org>,
lightning-dev <lightning-dev@lists•linuxfoundation.org>,
"Héctor José Cárdenas Pacheco" <hcarpach@gmail•com>
Subject: Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
Date: Thu, 9 Dec 2021 07:12:45 -0500 [thread overview]
Message-ID: <CA+2b5C1bfHnNtz6jWRmzr-2Dz3DpyvE1Z_LFCsJgBpbP-bULYQ@mail.gmail.com> (raw)
In-Reply-To: <YbHVaU19CFvOQ3MB@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
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@petertodd•org> wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 2436 bytes --]
next prev parent reply other threads:[~2021-12-09 12:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-06 9:54 [bitcoin-dev] " Héctor José Cárdenas Pacheco
2021-12-06 10:20 ` Karl
2021-12-06 11:31 ` [bitcoin-dev] [Lightning-dev] " Martin Habovštiak
2021-12-06 16:35 ` Christian Moss
2021-12-09 9:12 ` Peter Todd
2021-12-09 9:49 ` Christian Moss
2021-12-09 10:07 ` Peter Todd
2021-12-09 12:12 ` Alex Schoof [this message]
2021-12-09 12:56 ` Peter Todd
2021-12-06 12:38 ` [bitcoin-dev] " Christian Moss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+2b5C1bfHnNtz6jWRmzr-2Dz3DpyvE1Z_LFCsJgBpbP-bULYQ@mail.gmail.com \
--to=alex.schoof@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hcarpach@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox