Topics: CISA: rewrite based on feedback from Murchandamus & fjahr

_topics/en/cross-input-signature-aggregation.md

@@ -7,7 +7,8 @@ shortname: cisa
 
 ## Optional.  An entry will be added to the topics index for each alias
 aliases:
-  - Half aggregation
+  - Half aggregation of signatures
+  - Full aggregation of signatures
 
 ## Required.  At least one category to which this topic belongs.  See
 ## schema for options
@@ -21,6 +22,9 @@ primary_sources:
     - title: "Cross-input signature aggregation research repository"
       link: https://github.com/BlockstreamResearch/cross-input-aggregation
 
+    - title: Half-Aggregation of BIP 340 signatures
+      link: https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/half-aggregation.mediawiki
+
 ## Optional.  Each entry requires "title" and "url".  May also use "feature:
 ## true" to bold entry and "date"
 optech_mentions:
@@ -41,6 +45,15 @@ see_also:
   - title: BLS signatures
     link: topic bls signatures
 
+  - title: Signature adaptors
+    link: topic adaptor signatures
+
+  - title: Scriptless multisignatures
+    link: topic multisignature
+
+  - title: Signer delegation
+    link: topic signer delegation
+
 ## Optional.  Force the display (true) or non-display (false) of stub
 ## topic notice.  Default is to display if the page.content is below a
 ## threshold word count
@@ -49,28 +62,68 @@ see_also:
 ## Required.  Use Markdown formatting.  Only one paragraph.  No links allowed.
 ## Should be less than 500 characters
 excerpt: >
-  **Cross-input signature aggregation** is a proposal to reduce the
-  number of signatures a transaction requires.  In theory, every
-  signature required to a make a transaction valid could be combined into a
-  single signature that covers the whole transaction.
+  **Cross-input signature aggregation (CISA)** is a proposal to reduce
+  the number of signatures a transaction requires, which would require a
+  consensus change.  In theory, every signature required to make a
+  transaction valid could be combined into a single signature that
+  covers the whole transaction.
 
 ---
-For example, Alice controls two [P2TR][topic taproot] UTXOs.  Normally,
-if she creates a transaction spending both UTXOs with a keypath spend,
-she'll need to include one 16-vbyte signature in each output.  However,
-any node could aggregate both public keys from the UTXOs and Alice could
-produce a single 16-vbyte [MuSig]topic musig]-style [scriptless
-multisigature][topic multisignature] that corresponded to the aggregate
-public key, proving that she controlled the private key for both of the
-original public keys.
-
-Although inputs would still need to include a significant amount of
-other data, such as the 36-vbyte outpoint that uniquely identifies the
-UTXO being spent, CISA could provide a modest reduction in the size of
-transactions with multiple inputs.  It could make the per-participant
-transaction fees for a [coinjoin][topic coinjoin] moderately cheaper than each
-participant creating a transaction on their own, which could lead to
-more people using coinjoin-style privacy.
+There are two forms of CISA that are compatible with Bitcoin's secp256k1
+curve parameters:
+
+- **Full aggregation** involves the signers of different inputs in a
+  transaction cooperating interactively to create a single signature for
+  the entire transaction.  The aggregated signature would be the same
+  size as a regular signature, e.g. 64 bytes (16 vbytes) for a
+  [BIP341][]-style [schnorr signature][topic schnorr signatures].
+
+- **Half aggregation** involves the signers of different inputs in a
+  transaction producing a valid transaction in the normal way.  Notably,
+  they don't need to cooperate interactively and can instead coordinate
+  non-interactively using scripted multisignatures, sighash flags, or
+  other features.  Once a valid transaction has been produced, any one
+  can convert all valid BIP340-style signatures in the transaction into
+  a single half-aggregated signature.  For a transaction with _n_
+  signatures, the size of the half-aggregated signature would be `32n +
+  32` bytes (`8n + 8` vbytes).
+
+For a transaction that has an equal number of inputs and outputs, such
+as the simplest type of [coinjoin][topic coinjoin] transaction, the
+maximum space savings of full aggregation is around 15%.  For
+half aggregation, it's about half that.  The savings is less for
+transactions with fewer inputs.
+
+![Plot of transaction size savings for full-agg and half-agg vs unaggregated transactions](/img/posts/2024-01-agg-savings.png)
+
+A transaction without aggregation allows every signature to commit to a
+[signature adaptor][topic adaptor signatures].  A transaction with full
+aggregation may only have one signature adaptor for the entire
+transaction---and every signing party must agree to the same commitment.
+A transaction with half aggregation cannot contain any signature
+adaptors.
+
+Full aggregation must be carefully designed to avoid problems such as
+key and nonce cancellation attacks which could allow an adversary to
+steal funds.  The standard protections against cancellation attacks that
+are implemented in [scriptless multisignature protocols][topic
+multisignature] like [MuSig2][topic musig] may not be available in
+certain soft fork proposals for [signer delegation][topic signer
+delegation], meaning full aggregation needs to be carefully evaluated
+for possible dangerous interactions.  Half aggregation may not produce
+as many potentially harmful interactions, leading some proponents to
+[claim][halfagg doc] that "the difference in complexity between
+half-aggregation and full aggregation is so significant that basing a
+CISA on half-aggregation is a legitimate approach." <!-- TODO:I'm
+writing beyond my expertise here; please feel free to open a PR with
+more details -harding -->
+
+Either type of aggregation can be added in a soft fork that adds a new
+signature verification method, such as by using a new witness version.
+It would also be possible for a soft fork to enable non-interactive full
+aggregation in conjunction with different curve parameters for Bitcoin,
+such as in the [BLS signature scheme][topic bls signatures].
 
 {% include references.md %}
 {% include linkers/issues.md issues="" %}
+[halfagg doc]: https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/half-aggregation.mediawiki

img/posts/2024-01-agg-savings.gnuplot

@@ -0,0 +1,36 @@
+set terminal pngcairo size 800,300
+
+set style line 1 lc rgb 'black' lt 1 lw 3    # Black line style
+set style line 2 lc rgb 'grey' lt 1 lw 3     # Grey line style
+
+set key off  # Turn off the legend
+
+savings(x, y) = ( (x - y) / x ) * 100
+
+# All sizes for P2TR keypath from https://bitcoinops.org/en/tools/calc-size/
+# 10.5 is overhead; 43 is output size
+tx_size(inouts, input_size) = 10.5 + inouts * input_size + inouts * 43
+# 57.5 is P2TR keypath spend, of which 16 bytes is the signature
+unagg_size(inouts) = tx_size(inouts, 57.5)
+# Half agg is n*8 + 8
+halfagg_size(inouts) = tx_size(inouts, 57.5 - 8) + 8
+# Full agg is n*0 + 16
+fullagg_size(inouts) = tx_size(inouts, 57.5 - 16) + 16
+
+#unset xtics
+#unset ytics
+set grid
+set xtics 1
+set ytics 4
+set format y "%g%%"
+set xlabel "Number of inputs (with an equal number of outputs, as in a prototypical coinjoin)"
+set ylabel "Reduction in transaction size"
+
+set label "Full aggregation" at 5,14.5
+set label "Half aggregation" at 5,8
+
+set xrange [1:10]
+set yrange [0:17]
+set output '2024-01-agg-savings.png'
+#plot unagg_size(x) ls 1, halfagg_size(x) ls 2, fullagg_size(x) ls 3
+plot savings(unagg_size(x), halfagg_size(x)) ls 2, savings(unagg_size(x), fullagg_size(x)) ls 1