So this half aggregation BIP draft could potentially play the role that BIP340 did for BIP341/342 but it is too premature to start formalizing what the equivalent of BIP341/342 for this draft BIP would look like. And given there 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 interesting 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 describes some of the challenges of implementing CISA/CISHA as a consensus change. A couple of things that stand out to me if this was attempted in the long 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 couldn't be applied. It could even be the case that a new output type is defined 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 than a single signature spend path). With SegWit v0 (and today with SegWit v1) the intention is to get the entire community to move to the new output type. But there could be a long term future where you pick an output type depending on your use case. I recall that Mimblewimble only worked if scripting was ditched entirely and every spend was assumed to be a single signature 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 <jonasdn...@gmail.com> wrote: > To be clear, whether "half aggregation needs a new output type or not" does > not > become clear in the draft BIP because it is out of scope. Half-aggregation > has a > few possible applications. The draft only specifies the cryptographic scheme. > > The StackExchange post you link to argues that CISA requires a new output > type. > The same argument applies to half aggregating signatures across transaction > 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 verification of > Taproot output key spends (Schnorr signatures) and script spends (key tweaks). _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
