MIME-Version: 1.0
References: <DD7D5A8B-F61F-4302-ACF4-CE731843D97D@gmail.com>
 <CALL-=e5mF9TqbbD=Cf-bawbw4dq2PGjC9W_nqAQeHsB829ZpNg@mail.gmail.com>
 <CALkkCJas_pf7Un45CJyFg8j9cBk8PtKN4iYAL81TtLSRNnKqeg@mail.gmail.com>
 <CANQKmgLyaYAjL_=LziTCFT=Ahc2SXjJrWc+RO59pxd3mnJApfQ@mail.gmail.com>
 <YbHImwix1z8BgAc2@petertodd.org>
 <CANQKmg+D22GrLFDBAawop1uha3GG5F4TmixMajcTPQUdTF4-PQ@mail.gmail.com>
 <YbHVaU19CFvOQ3MB@petertodd.org>
In-Reply-To: <YbHVaU19CFvOQ3MB@petertodd.org>
From: Alex Schoof <alex.schoof@gmail.com>
Date: Thu, 9 Dec 2021 07:12:45 -0500
Message-ID: <CA+2b5C1bfHnNtz6jWRmzr-2Dz3DpyvE1Z_LFCsJgBpbP-bULYQ@mail.gmail.com>
To: pete@petertodd.org
Content-Type: multipart/alternative; boundary="000000000000d3761d05d2b58659"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 =?UTF-8?Q?H=C3=A9ctor_Jos=C3=A9_C=C3=A1rdenas_Pacheco?= <hcarpach@gmail.com>
Subject: Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin
	Lightning
Precedence: list

--000000000000d3761d05d2b58659
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=99re stuck and cant close t=
he next
seal. If instead you say =E2=80=9Cthis seal commits to three of the five of=
 these
next seals=E2=80=9D 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 a=
s
> > 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
>
--=20


Alex Schoof

--000000000000d3761d05d2b58659
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">The multisig scheme is interesting. From my understanding=
 of Single Use Seals, since seal n commits to seal n+1, for the on-chain ag=
gregation seals you would want to pick some common aggregation service prov=
ider ahead of time and if that provider disappears, you=E2=80=99re stuck an=
d cant close the next seal. If instead you say =E2=80=9Cthis seal commits t=
o three of the five of these next seals=E2=80=9D then you mitigate both ava=
ilability and censorship risk. Am I getting that right?=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Alex</div><div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 9, 2021 at 5:23 =
AM Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left=
:1ex;border-left-color:rgb(204,204,204)">On Thu, Dec 09, 2021 at 09:49:11AM=
 +0000, Christian Moss wrote:<br>
&gt; <a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd=
.org</a>, so single use seals require an onchain transaction to<br>
&gt; post the proof of publication to the ledger (assuming bitcoin is used =
as<br>
&gt; the ledger) when an asset is transferred, but it can scale because you=
 can<br>
&gt; batch many proofs (transfer of ownerships) into a merkle tree and just=
 add<br>
&gt; the merkle root into the single tx going into the ledger?<br>
<br>
Exactly. And since the aggregation is trustless with respect to validity, u=
sers<br>
can choose what kind of censorship risk they&#39;re willing to take (as wel=
l as<br>
mitigate it with &quot;multisig&quot; schemes that use multiple aggregators=
 in parallel).<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><br><br>Alex Schoof</div>

--000000000000d3761d05d2b58659--