Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures

[Michael Folkson <michaelfolkson@protonmail.com>]

Thanks for this Jonas. One question that was asked on Telegram (credit: Antoine D) and isn't clear to me skimming the blog post and the draft BIP is whether half aggregation needs a new output type or not like we expect cross input signature aggregation (CISA) to [0]. My understanding is Schnorr signature batch verification (no aggregation of signatures) can be done today but half aggregation and CISA would need a soft fork and potentially a new output type in addition.

(I know this work is in its early stages and won't be proposed for a soft fork anytime soon. A few of us are just trying to get a basic sketch in our heads of what they require and whether they could be enabled in the same upgrade.)

[0]: https://bitcoin.stackexchange.com/questions/106240/will-cross-input-signature-aggregation-need-a-new-output-type/



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


------- Original Message -------
On Friday, July 8th, 2022 at 16:53, Jonas Nick via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Half-aggregation has been mentioned several times on this list in various
> contexts. To have a solid basis for discussing applications of half-aggregation,
> I think it's helpful to have a concrete specification of the scheme and a place
> for collecting supplemental information like references to cryptographic
> security proofs. You can find the BIP draft at
>
> https://github.com/ElementsProject/cross-input-aggregation/blob/master/half-aggregation.mediawiki
>
> Similar to BIP-340, this BIP draft specifies only the cryptographic scheme and
> does not prescribe specific applications. It has not received an extensive
> security review yet. Thanks to Elliott Jin and Tim Ruffing for the review so
> far. One new feature that the specified scheme has is "incremental aggregation"
> which allows aggregating additional BIP-340 signatures into an existing
> half-aggregate signature.
>
> While BIP-340 has a pseudocode specification and a reference implementation in
> python, this BIP draft has a formal specification written in hacspec [0] and
> auxiliary pseudocode. The formal specification is a mathematically precise
> description of the scheme, which paves the way for computer-aided formal proofs.
> Software tools ("proof assistants") allow proving properties about the formal
> specification ("no integer overflow") and apply formal software verification
> ("implementation is behaviorally equivalent to the spec"). I don't have concrete
> plans (nor the skillset) to use these techniques. Still, I think this is an
> exciting area to explore because it has the potential to increase the Bitcoin
> ecosystem's robustness significantly and has little downside. Since hacspec's
> syntax is a subset of Rust's syntax, one can use the standard rust toolchain to
> compile, execute and test the specification.
>
> You can find a blog post that gives a broader context at
> https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/
>
> [0] https://github.com/hacspec/hacspec
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev