Date: Wed, 20 Jul 2022 11:16:40 +0000
To: Jonas Nick <jonasdnick@gmail.com>
From: Michael Folkson <michaelfolkson@protonmail.com>
Reply-To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <_B_M5x2e1pkA8CmR-EY7NaMHZwBFJ3ST3GrEHzfL4P68CVsCgNKLb4OycJM7JSp625jnh7R5LSQXuRY1Ve0-kr0FKVrBdWnMh149YTNk78M=@protonmail.com>
In-Reply-To: <2f511890-23a7-882a-332c-85cda02fba7a@gmail.com>
References: <33f275c2-06b1-4b4a-2a75-cafe36836503@gmail.com>
 <uxodWlVSmJqvVHDuGevdDbsc5lXiyV6zONlNJtj6gDylkTXQzkPPokLXKJAVULMwPbduJJ7Fb-s0ZYKpduvIZ-LkCsfXClkDH5WhOFsTHts=@protonmail.com>
 <2f511890-23a7-882a-332c-85cda02fba7a@gmail.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
Precedence: list

So this half aggregation BIP draft could potentially play the role that BIP=
340 did for BIP341/342 but it is too premature to start formalizing what th=
e equivalent of BIP341/342 for this draft BIP would look like. And given th=
ere are use cases for this half aggregation BIP that can be worked on today=
 (e.g. Lightning gossip [0], Lightning gossip seems to be a very interestin=
g research area at the moment with a number of possible upgrades) it makes =
sense to focus on those first.

There is a section[1] in the CISA repo which I missed originally that descr=
ibes some of the challenges of implementing CISA/CISHA as a consensus chang=
e. A couple of things that stand out to me if this was attempted in the lon=
g term. One is that there would almost need to be two tiers of verification=
: verification for single signature key path spends where CISA, CISHA could=
 be applied and verification for Taproot script paths where CISA, CISHA cou=
ldn't be applied. It could even be the case that a new output type is defin=
ed specifically for the CISA, CISHA use case where there is no access to a =
script path at all (i.e. where users don't have a need for anything other t=
han a single signature spend path). With SegWit v0 (and today with SegWit v=
1) the intention is to get the entire community to move to the new output t=
ype. But there could be a long term future where you pick an output type de=
pending on your use case. I recall that Mimblewimble only worked if scripti=
ng was ditched entirely and every spend was assumed to be a single signatur=
e spend.

Anyway...thanks for indulging me on the long term stuff :)

[0]: https://github.com/ElementsProject/cross-input-aggregation#sigagg-case=
-study-ln-channel-announcements

[1]: https://github.com/ElementsProject/cross-input-aggregation#integration=
-into-the-bitcoin-protocol

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Sunday, July 17th, 2022 at 21:45, Jonas Nick <jonasdnick@gmail.com> wrot=
e:


> To be clear, whether "half aggregation needs a new output type or not" do=
es not
> become clear in the draft BIP because it is out of scope. Half-aggregatio=
n has a
> few possible applications. The draft only specifies the cryptographic sch=
eme.
>
> The StackExchange post you link to argues that CISA requires a new output=
 type.
> The same argument applies to half aggregating signatures across transacti=
on
> inputs (CISHA, if you will). The only difference to "full aggregation" is=
 that
> the transaction signature is a single half-aggregate signature instead of=
 a
> 64-byte signature. You're right that it's possible to do batch verificati=
on of
> Taproot output key spends (Schnorr signatures) and script spends (key twe=
aks).