public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Folkson <michaelfolkson@protonmail.com>
To: Jonas Nick <jonasdnick@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
Date: Wed, 20 Jul 2022 11:16:40 +0000	[thread overview]
Message-ID: <_B_M5x2e1pkA8CmR-EY7NaMHZwBFJ3ST3GrEHzfL4P68CVsCgNKLb4OycJM7JSp625jnh7R5LSQXuRY1Ve0-kr0FKVrBdWnMh149YTNk78M=@protonmail.com> (raw)
In-Reply-To: <2f511890-23a7-882a-332c-85cda02fba7a@gmail.com>

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 <jonasdnick@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).


      reply	other threads:[~2022-07-20 11:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 15:53 [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures Jonas Nick
2022-07-17 13:26 ` Michael Folkson
2022-07-17 20:48   ` Jonas Nick
2022-07-20 11:16     ` Michael Folkson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='_B_M5x2e1pkA8CmR-EY7NaMHZwBFJ3ST3GrEHzfL4P68CVsCgNKLb4OycJM7JSp625jnh7R5LSQXuRY1Ve0-kr0FKVrBdWnMh149YTNk78M=@protonmail.com' \
    --to=michaelfolkson@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jonasdnick@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox