š
Original date posted:2022-07-17
š Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Michael Folkson [ARCHIVE] /
npub103ā¦2kpam
2023-06-07 23:11:19
in reply to nevent1qā¦4wpv
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpamPublished at
2023-06-07 23:11:19Event JSON
{
"id": "6f128ed76e468ce9436b50eee12110102263ccb1b9cb7e1ebd0896f66a0b4906",
"pubkey": "7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a",
"created_at": 1686179479,
"kind": 1,
"tags": [
[
"e",
"0d72a15ee72366e53511c642de2a3b7516b96b2b8bf94b48e88958ece595c21c",
"",
"root"
],
[
"e",
"f46820ed78c26852bc44d87c7940214dc9ec2746bb5f77a7f00993e621ed0e3d",
"",
"reply"
],
[
"p",
"eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f"
]
],
"content": "š
Original date posted:2022-07-17\nš Original message: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.\n\n(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.)\n\n[0]: https://bitcoin.stackexchange.com/questions/106240/will-cross-input-signature-aggregation-need-a-new-output-type/\n\n\n\n--\nMichael Folkson\nEmail: michaelfolkson at protonmail.com\nKeybase: michaelfolkson\nPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\n\n------- Original Message -------\nOn Friday, July 8th, 2022 at 16:53, Jonas Nick via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e Half-aggregation has been mentioned several times on this list in various\n\u003e contexts. To have a solid basis for discussing applications of half-aggregation,\n\u003e I think it's helpful to have a concrete specification of the scheme and a place\n\u003e for collecting supplemental information like references to cryptographic\n\u003e security proofs. You can find the BIP draft at\n\u003e\n\u003e https://github.com/ElementsProject/cross-input-aggregation/blob/master/half-aggregation.mediawiki\n\u003e\n\u003e Similar to BIP-340, this BIP draft specifies only the cryptographic scheme and\n\u003e does not prescribe specific applications. It has not received an extensive\n\u003e security review yet. Thanks to Elliott Jin and Tim Ruffing for the review so\n\u003e far. One new feature that the specified scheme has is \"incremental aggregation\"\n\u003e which allows aggregating additional BIP-340 signatures into an existing\n\u003e half-aggregate signature.\n\u003e\n\u003e While BIP-340 has a pseudocode specification and a reference implementation in\n\u003e python, this BIP draft has a formal specification written in hacspec [0] and\n\u003e auxiliary pseudocode. The formal specification is a mathematically precise\n\u003e description of the scheme, which paves the way for computer-aided formal proofs.\n\u003e Software tools (\"proof assistants\") allow proving properties about the formal\n\u003e specification (\"no integer overflow\") and apply formal software verification\n\u003e (\"implementation is behaviorally equivalent to the spec\"). I don't have concrete\n\u003e plans (nor the skillset) to use these techniques. Still, I think this is an\n\u003e exciting area to explore because it has the potential to increase the Bitcoin\n\u003e ecosystem's robustness significantly and has little downside. Since hacspec's\n\u003e syntax is a subset of Rust's syntax, one can use the standard rust toolchain to\n\u003e compile, execute and test the specification.\n\u003e\n\u003e You can find a blog post that gives a broader context at\n\u003e https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/\n\u003e\n\u003e [0] https://github.com/hacspec/hacspec\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "f534251417a87b636f1ec135320d8791a95ccbe8bdb033b9ca2d93459cf49f53d01faa0e99303506f6ac077b78e156e38cf8d2d76f4b9bab9e3c35c73a0c3249"
}