DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures

[DanGould]

DahLIAS

https://eprint.iacr.org/2025/692.pdf

main contribution: proving the security of a new interactive full aggregation scheme

• O(1) signature size for for collaborative txs
  • Every signature is associated with a different message
• discussions go back even before taproot
• BIP 340 Schnorr signatures allow half-aggregation
• Would require a soft fork
• Significantly bolster cost savings argument for payjoin
• Even better argument for larger multiparty transactions

Fabian's report

HRF sponsored high-level report
predates DahLIAS full aggregation scheme, so it talks more about
half-aggregation

Question

if we have interactivity could we get away with a more naive approach then
current halfagg?

DahLIAS protects against

prove that the construction is secure as long as key tweeks are avoided (no
taproot commitments or BIP32, which makes it not practical)

Discuss: How does DahLIAS interactivity play into payjoin

• 2 rounds
  • 1. Nonce exchange round (can happen before message is known)
  • 2. Partial signature production & aggregation

Combine CISA and Payjoin Interactions

It seems that our existing models accomodate CISA without additional rounds of
communication

If sender sends only a nonce in relation to the specific receiver (session) key
and has a similar restriction wrt sender inputs then the nonce could be bound to
sender's component of message. Then you could ensure nonces are unique per tx.

2-party Payjoin (BIP 78 and 77)

Sender -> Receiver. Sender can share a nonce

Receiver -> Sender Receiver can share a nonce + partial signature

Sender can provide partial signature and aggregate

NS1R Payjoin

• nonce sharing again happens with fallback proposal
• receiver can aggregate partial signature

both of

Restriction of key reuse is a privacy problem

A CISA-needs-no-reused-pubkeys adversary could dust and then figure out what
keys are related by seeing which inputs get spent together.

The mitigation in Bitcoin Core that spends same keys together would no longer
work.

in DahLIAS you can re-use public keys (though it's not recommended for privacy
reasons)

Do you lose counterparty privacy from sig + message knowledge?

No. Every input needs to sign a potentially mixed message based on input data
no matter what. That doesn't link you to the output necessarily.

Signers reveal no more than they would otherwise reveal on chain.

Is doing sigagg a fingerprint on chain that everyone has to do?

Yes, unfortunately. There's also a compatibility issue with OP_SUCCESS codes.
We'd need to change the OP_SUCCESS rules we have now. You could ONLY allow CISA
for key spends as one potential solution. But we want it for script spends too.

Could script aggregation be like CHECKSIG_ADD

One more discrete log problem

adversary gets as many discrete log queries as they want. Slightly different
from discrete log problem.

The weird part is that it's not "instantiable," you cannot provide an algorithm
that does that unless you already assume the challenger already breaks the
discrete log problem. Unless you use algebraic dlog.