Date: Thu, 9 Dec 2021 07:56:19 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Schoof <alex.schoof@gmail.com>
Message-ID: <YbH884j/+rZNcMjG@petertodd.org>
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>
 <CA+2b5C1bfHnNtz6jWRmzr-2Dz3DpyvE1Z_LFCsJgBpbP-bULYQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="pa2N1icXw6EwdAH2"
Content-Disposition: inline
In-Reply-To: <CA+2b5C1bfHnNtz6jWRmzr-2Dz3DpyvE1Z_LFCsJgBpbP-bULYQ@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 =?iso-8859-1?Q?H=E9ctor_Jos=E9_C=E1rdenas?= Pacheco <hcarpach@gmail.com>
Subject: Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin
 Lightning
Precedence: list


--pa2N1icXw6EwdAH2
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote:
> 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 sea=
ls
> 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=
 the 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 ri=
sk. Am I
> getting that right?

Re: "some common aggregation service provider", you might be misunderstandi=
ng
the protocol: since seals are trustless with regard to validity, I can vali=
date
your seal, regardless of which aggregation service you use.

But other than that, I think we're on the same page!

A concrete example would be an exchange: they do a lot of transactions, so =
they
could choose to be their own aggregator, and wouldn't need any multisig at =
all
because they can trust themselves not to censor themselves. :) Meanwhile, o=
ne
of their customers might use 3-of-5 as you suggest, as they only do a few
transactions a month.

Interestingly, in some scenarios it might be worthwhile to both run your own
aggregator, and use multisig. Eg Alice could use a 2-of-3 with two third-pa=
rty
aggregators, and her own aggregation chain. If both third-parties are up, s=
he
does no on-chain transactions at all; if one third-party is down, she can u=
se
her own, and the remaining third-party. Thus she would only do an on-chain
transaction to defeat censorship/failure.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--pa2N1icXw6EwdAH2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmGx/O4ACgkQLly11TVR
LzfWYRAAvEuQRZUD/i5zS7BjPV8Ln+8m93ZaNm/WBfGh5q46P8uUY0jCUHz8ytPo
OBXzBiS2N1jS8QlIITZLzO5bo3k1QY3q10YTzuy32o1jdSSNcjE9Wrvvs8F5y4Wx
E8Y8ox+Yxz0AHjKgiKbTl+GEWnTwJoQWDWfdYaPHOcDhkNe7bacD/AcXi6wyH/dV
/eDRMeWM3Hj4ofSqjFT6dQ4qNWxJkr7G5Y+mNFmSNKXbl+3wsQejHdydBOcNYkQh
e3xTJ0JksmO+3T0WEMoiGaH3s3Gjx185U5KhP4r16heaFDnLlepx6b8j6V7/8++Q
bDRiAMa22hu4+s5K3A8dxicOHGn7JxzGRKeX/e47iVaon8J3SM3HcnSDBEVhP4/c
HDfWtm3N1XT0kk4VVBpzY1S3SpqfagYfMEbkzlzG4uQZzbpq522YZb/gP7B8UsHj
7iymWZoAwgZDs97lum1BnryKynYL4Pte2uo2vlVQKAXhcxG6iA8yQj7urf7+oY07
pjhfolvHOPMSCPomo7W4nt1SywtVCasP0rs8K/IYu6WhpBRqRGvD2knXBYLbQIW/
77p3S60EOOB9ohr6K4WDTFV3TeLO+/Z75rZclnCNspJ6EXSYLZ/qNg5y4nSSzuYw
uLQdcgjhHdHnZJ9+aqUVUYxcbiy/vT2k9R6KtYaTmScIkOTuEaw=
=f75x
-----END PGP SIGNATURE-----

--pa2N1icXw6EwdAH2--