DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures

DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
2025-04-19 16:28 ` [bitcoindev] " waxwing/ AdamISZ
                   ` (2 more replies)
  
From: Jonas Nick @ 2025-04-17 16:27 UTC (permalink / raw)
  To: bitcoindev

Hi list,

Cross-Input Signature Aggregation (CISA) has been a recurring topic here, aiming
to reduce transaction sizes and verification cost [0]. Tim Ruffing, Yannick
Seurin and I recently published DahLIAS, the first interactive aggregate
signature scheme with constant-size signatures (64 bytes) compatible with
secp256k1.

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

Recall that in an aggregate signature scheme, each signer contributes their own
message, which distinguishes it from multi- and threshold signatures, where all
signers sign the same message. This makes aggregate signature schemes the
natural cryptographic primitive for cross-input signature aggregation because
each transaction input typically requires signing a different message.

Previous candidates for constant-size aggregate signatures either:
- Required cryptographic assumptions quite different from the discrete logarithm
   problem on secp256k1 currently used in Bitcoin signatures (e.g., groups with
   efficient pairings).
- Were "folklore" constructions, lacking detailed descriptions and security
   proofs.

Besides presenting DahLIAS, the paper provides a proof that a class of these
folklore constructions are indeed secure if the signer does _not_ use key
tweaking (e.g., no Taproot commitments or BIP 32 derivation). Moreover, we show
that there exists a concrete attack against a folklore aggregate signature
scheme derived from MuSig2 when key tweaking is used.

In contrast, DahLIAS is proven to be compatible with key tweaking. Moreover, it
requires two rounds of communication for signing, where the first round can be
run before the messages to be signed are known. Verification of DahLIAS
signatures is asymptotically twice as fast as half-aggregate Schnorr signatures
and as batch verification of individual Schnorr signatures.

We believe DahLIAS offers an attractive building block for a potential CISA
proposal and welcome any feedback or discussion.

Jonas Nick, Tim Ruffing, Yannick Seurin


[0] See, e.g., https://cisaresearch.org/ for a summary of various CISA
     discussions.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/be3813bf-467d-4880-9383-2a0b0223e7e5%40gmail.com.


 permalink raw reply	[|nested]
2025-04-19 16:28 `  " waxwing/ AdamISZ
                   ` 
  
From: Jonas Nick @ 2025-04-17 16:27 UTC (permalink / raw)
  To: bitcoindev

Hi list,

Cross-Input Signature Aggregation (CISA) has been a recurring topic here, aiming
to reduce transaction sizes and verification cost [0]. Tim Ruffing, Yannick
Seurin and I recently published DahLIAS, the first interactive aggregate
signature scheme with constant-size signatures (64 bytes) compatible with
secp256k1.

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

Recall that in an aggregate signature scheme, each signer contributes their own
message, which distinguishes it from multi- and threshold signatures, where all
signers sign the same message. This makes aggregate signature schemes the
natural cryptographic primitive for cross-input signature aggregation because
each transaction input typically requires signing a different message.

Previous candidates for constant-size aggregate signatures either:
- Required cryptographic assumptions quite different from the discrete logarithm
   problem on secp256k1 currently used in Bitcoin signatures (e.g., groups with
   efficient pairings).
- Were "folklore" constructions, lacking detailed descriptions and security
   proofs.

Besides presenting DahLIAS, the paper provides a proof that a class of these
folklore constructions are indeed secure if the signer does _not_ use key
tweaking (e.g., no Taproot commitments or BIP 32 derivation). Moreover, we show
that there exists a concrete attack against a folklore aggregate signature
scheme derived from MuSig2 when key tweaking is used.

In contrast, DahLIAS is proven to be compatible with key tweaking. Moreover, it
requires two rounds of communication for signing, where the first round can be
run before the messages to be signed are known. Verification of DahLIAS
signatures is asymptotically twice as fast as half-aggregate Schnorr signatures
and as batch verification of individual Schnorr signatures.

We believe DahLIAS offers an attractive building block for a potential CISA
proposal and welcome any feedback or discussion.

Jonas Nick, Tim Ruffing, Yannick Seurin


[0] See, e.g., https://cisaresearch.org/ for a summary of various CISA
     discussions.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/be3813bf-467d-4880-9383-2a0b0223e7e5%40gmail.com.


 permalink raw reply	[|nested]
2025-04-19 16:28 ` [bitcoindev] " waxwing/ AdamISZ

  
From: Jonas Nick @ 2025-04-22 15:29 UTC (permalink / raw)
  To: bitcoindev

Thanks for bringing this up. It's an interesting question and it made us realize
that we should clarify this section of the paper, as there are indeed some
subtleties here that are currently unmentioned.

 > I don't understand why this same attack cannot be applied to MuSig2 itself?

There are nuances, but I think it's fair to say that the same attack cannot be
applied to MuSig2 itself. During the attack, the adversary requests a partial
signature for public key X and message m from the honest signer. Using this, the
adversary is able to create a partial signature for public key X' = TweakPK(X,
t), where t is some tweak chosen by the adversary, and message m'. When applying
the attack to MuSig2, we have that m' = m, and when applying it to MuSig2-IAS,
we may have m != m'.

So, using the attack, the adversary is able to produce a signature sigma_1 for
MuSig2 and sigma_2 for MuSig2-IAS such that

- MuSig2.Verify(KeyAgg(X, X'), m, sigma_1) = 1, and
- MuSig2-IAS.Verify((X, m), (X', m'), sigma_2) = 1.

sigma_2 is clearly a forgery under the EUF-CMA-TK security model defined in the
DahLIAS paper because it is a signature for a message m' that the honest signer
hasn't signed. In contrast, sigma_1 only covers the message that the honest
signer actually signed. Whether sigma_1 counts as a forgery depends on the
abstract security notion that you consider for multisignature tweaking. We
didn't provide such a model in the MuSig2 paper and I am not aware of a standard
one. It would be easy to design a security model where sigma_1 constitutes a
forgery and one where it doesn't.

More importantly, could this be a problem for MuSig2 in practice? I can only
come up with contrived scenarios, but it may still be worth mentioning in the
BIP, for example.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2ede88e8-2570-442f-a073-730f7de70eca%40gmail.com.


 permalink raw reply	[|nested]
2025-04-17 16:27 [bitcoindev] DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures Jonas Nick
  2025-04-19 16:28 ` [bitcoindev] " waxwing/ AdamISZ

  2025-04-25 16:41   ` Jonas Nick
  2025-04-26 15:30 ` waxwing/ AdamISZ
  
From: waxwing/ AdamISZ @ 2025-04-25 16:08 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2894 bytes --]

I'm struggling to understand one detail in DahLIA's algorithm: the use of 
R2 as a check and not R1 (or both). Is it just that only one is needed? Is 
it just an optimization?

Thanks,
AdamISZ/waxwing

On Thursday, April 17, 2025 at 10:38:46 AM UTC-6 Jonas Nick wrote:

> Hi list,
>
> Cross-Input Signature Aggregation (CISA) has been a recurring topic here, 
> aiming
> to reduce transaction sizes and verification cost [0]. Tim Ruffing, Yannick
> Seurin and I recently published DahLIAS, the first interactive aggregate
> signature scheme with constant-size signatures (64 bytes) compatible with
> secp256k1.
>
> https://eprint.iacr.org/2025/692.pdf
>
> Recall that in an aggregate signature scheme, each signer contributes 
> their own
> message, which distinguishes it from multi- and threshold signatures, 
> where all
> signers sign the same message. This makes aggregate signature schemes the
> natural cryptographic primitive for cross-input signature aggregation 
> because
> each transaction input typically requires signing a different message.
>
> Previous candidates for constant-size aggregate signatures either:
> - Required cryptographic assumptions quite different from the discrete 
> logarithm
> problem on secp256k1 currently used in Bitcoin signatures (e.g., groups 
> with
> efficient pairings).
> - Were "folklore" constructions, lacking detailed descriptions and security
> proofs.
>
> Besides presenting DahLIAS, the paper provides a proof that a class of 
> these
> folklore constructions are indeed secure if the signer does _not_ use key
> tweaking (e.g., no Taproot commitments or BIP 32 derivation). Moreover, we 
> show
> that there exists a concrete attack against a folklore aggregate signature
> scheme derived from MuSig2 when key tweaking is used.
>
> In contrast, DahLIAS is proven to be compatible with key tweaking. 
> Moreover, it
> requires two rounds of communication for signing, where the first round 
> can be
> run before the messages to be signed are known. Verification of DahLIAS
> signatures is asymptotically twice as fast as half-aggregate Schnorr 
> signatures
> and as batch verification of individual Schnorr signatures.
>
> We believe DahLIAS offers an attractive building block for a potential CISA
> proposal and welcome any feedback or discussion.
>
> Jonas Nick, Tim Ruffing, Yannick Seurin
>
>
> [0] See, e.g., https://cisaresearch.org/ for a summary of various CISA
> discussions.
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ffbf7fe1-8250-4db7-9ae6-21f0b1984b3an%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3975 bytes --]

 permalink raw reply	[|nested]
2025-04-25 16:08 ` waxwing/ AdamISZ

  
From: Jonas Nick @ 2025-04-25 16:41 UTC (permalink / raw)
  To: bitcoindev

Yes, just one is needed and this is an optimization. The signer does not require
every individual R1 value as input, only the R2 values. This is different to
MuSig2, where both R1 and R2 can be aggregated by the coordinator.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/71efbf8d-9251-492e-a98f-11b128af4214%40gmail.com.


 permalink raw reply	[|nested]
2025-04-17 16:27 [bitcoindev] DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures Jonas Nick
  2025-04-19 16:28 ` [bitcoindev] " waxwing/ AdamISZ
  2025-04-25 16:08 ` waxwing/ AdamISZ

  2025-04-26 17:05   ` waxwing/ AdamISZ
  
From: waxwing/ AdamISZ @ 2025-04-26 15:30 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 8062 bytes --]

Some comments/questions on the general structure of the scheme:

When I started thinking about ways to change the algorithm, I started to 
appreciate it more :) Although this algo is not specific to Bitcoin I'm 
viewing it 100% through that lens here. Some thoughts:

We want this CISA algorithm to have the property that it doesn't require 
the blockchain (and its verifiers) to incur linear cost in the number of 
signers/signatures. For a 100 input transaction, we get big gains from the 
owner or owners of the inputs choosing to use this algo, but that would 
mostly be lost if either the verifying was linear in the number, or if the 
size of the signature was linear in the number. So to avoid that we want a 
(R, s) structure to be actually published, not an (R1..Rn, s) or a (R, 
s1..sn). That pretty much forces us to make a sum R for all the individual 
component's R-values, and the same for s.

However it doesn't quite force us to add literally everything. The pubkeys 
*can* be kept separate, because they are retrieved implicitly from the 
existing blockchain record, they are not published with the signature 
(taproot). (Technically the same comment applies to the message being 
signed). This allows us to use the more "pedestrian", "safe" idea; we are 
not aggregating keys (as in MuSig) so we can actually add each with its own 
challenge hash: sum( challenge_hash_i * X_i). This may worry you that there 
is a performance issue because the verifier has to iterate through that 
whole list ( the verification equation being: sG =?= R + c_1 X_1 + c_2X_2 + 
.. ), but the paper specifically claims that comparing this with just batch 
verifying the individual signatures (i.e. without CISA), this is twice as 
fast.

So one could simplistically say "OK that's the pubkey side, they're treated 
individually so we don't have to worry about that, but what about adding 
the R values?" ("worry" here means: trivial key subtraction attacks or 
sophisticated Wagner/ROS grinding). And here what is done is basically the 
same as in MuSig2, which is to say, by breaking the nonce into two 
components and including an additional challenge hash, you prevent the 
counterparty/adversary from grinding R values successfully. Note that the 
"b" coefficient used here is more explicit about hashing the full context, 
than it was in MuSig2: it's hashing each individual pubkey and message as 
well as the R2 subcomponents for each party. This is vaguely similar to 
"client side validation" ideas: it's not really "validation" as in state 
updates, but it's having the more complex/expensive part of the calculation 
being done in the coordination before anything goes on-chain, and allowing 
us to just use a single "R" value onchain that we know is safe.

(Side note: it's worth remembering that a lot (maybe a huge majority?) of 
the usage of CISA will be a single signer of multiple inputs; for these 
cases there is not the same security arguments required, only that the 
final signature is not leaking the private key!).

That side note reminds me of my first question: would it not be appropriate 
to include a proof of the zero knowledgeness property of the scheme, and 
not only the soundness? I can kind of accept the answer "it's trivial" 
based on the structure of the partial sig components (s_k = r_k1 + br_k2 + 
c_k x_k) being "identical" to baseline Schnorr?

The side note also raises this point: would it be a good idea to explicitly 
write down ways in which the usage of the scheme/structure can, and cannot, 
be optimised for the single-party case? Intuitively it's "obvious" that you 
may be able to streamline it for the case where all operations happen on 
the same device, with a single owner of all the private keys. I realize 
that this is a thorny point, because we explicitly want to account for the 
corruption of parties that are "supposed" to be the same as the honest 
signer, but aren't.

And my last question is about this multi-component-nonce technique:

Did you consider the idea of e.g. sending proofs of knowledge of R along 
with R in the coordination step? This would keep the same number of rounds, 
and I'm assuming (though not sure exactly) that it makes the security proof 
significantly simpler, but my guess is you mostly dismiss such approaches 
as being too expensive for, say, constrained devices? (I imagine something 
like: 2 parties say, X1 sends (R1, pi_R1) and same for X2, to coordinator, 
then sum directly for overall R; here pi_R1 is ofc just a schnorr sig on 
r). If we're talking about bandwidth the current "ctx" object is already 
pretty large, right, because it contains all the pubkeys and all the 
messages (though in bitcoin they could be implicit perhaps).

(I won't mention the other idea, which is going back to MuSig1 style and 
just committing to R, because that's what both MuSig2 and FROST went away 
from, preferring fewer rounds.)

By the way after writing this overly long post I realised I didn't even get 
in to the really tricky part of the algorithm, the "check our key and 
message appears once" part because of the multisig-to-aggregated-sig 
transformation and the hole previously identified in it, which to be fair 
is the most interesting bit. Oh well, another time!

Cheers,
AdamISZ/waxwing
On Thursday, April 17, 2025 at 10:38:46 AM UTC-6 Jonas Nick wrote:

> Hi list,
>
> Cross-Input Signature Aggregation (CISA) has been a recurring topic here, 
> aiming
> to reduce transaction sizes and verification cost [0]. Tim Ruffing, Yannick
> Seurin and I recently published DahLIAS, the first interactive aggregate
> signature scheme with constant-size signatures (64 bytes) compatible with
> secp256k1.
>
> https://eprint.iacr.org/2025/692.pdf
>
> Recall that in an aggregate signature scheme, each signer contributes 
> their own
> message, which distinguishes it from multi- and threshold signatures, 
> where all
> signers sign the same message. This makes aggregate signature schemes the
> natural cryptographic primitive for cross-input signature aggregation 
> because
> each transaction input typically requires signing a different message.
>
> Previous candidates for constant-size aggregate signatures either:
> - Required cryptographic assumptions quite different from the discrete 
> logarithm
> problem on secp256k1 currently used in Bitcoin signatures (e.g., groups 
> with
> efficient pairings).
> - Were "folklore" constructions, lacking detailed descriptions and security
> proofs.
>
> Besides presenting DahLIAS, the paper provides a proof that a class of 
> these
> folklore constructions are indeed secure if the signer does _not_ use key
> tweaking (e.g., no Taproot commitments or BIP 32 derivation). Moreover, we 
> show
> that there exists a concrete attack against a folklore aggregate signature
> scheme derived from MuSig2 when key tweaking is used.
>
> In contrast, DahLIAS is proven to be compatible with key tweaking. 
> Moreover, it
> requires two rounds of communication for signing, where the first round 
> can be
> run before the messages to be signed are known. Verification of DahLIAS
> signatures is asymptotically twice as fast as half-aggregate Schnorr 
> signatures
> and as batch verification of individual Schnorr signatures.
>
> We believe DahLIAS offers an attractive building block for a potential CISA
> proposal and welcome any feedback or discussion.
>
> Jonas Nick, Tim Ruffing, Yannick Seurin
>
>
> [0] See, e.g., https://cisaresearch.org/ for a summary of various CISA
> discussions.
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/039cb943-5c94-44ba-929b-abec281082a8n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 9281 bytes --]

 permalink raw reply	[|nested]
2025-04-26 15:30 ` waxwing/ AdamISZ

  2025-04-30  7:59     ` Jonas Nick
  
From: waxwing/ AdamISZ @ 2025-04-26 17:05 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 8825 bytes --]

On that last point about "proof of knowledge of R", I suddenly realised 
it's not a viable suggestion: of course it defends against key subtraction 
attacks, but does not defend at all against the ability to grind nonces 
adversarially in a Wagner type attack,  so that you could get a forgery on 
the victim's single key from a bunch of parallel signing sessions. So, 
question retracted, there.

On Saturday, April 26, 2025 at 10:14:36 AM UTC-6 waxwing/ AdamISZ wrote:

> Some comments/questions on the general structure of the scheme:
>
> When I started thinking about ways to change the algorithm, I started to 
> appreciate it more :) Although this algo is not specific to Bitcoin I'm 
> viewing it 100% through that lens here. Some thoughts:
>
> We want this CISA algorithm to have the property that it doesn't require 
> the blockchain (and its verifiers) to incur linear cost in the number of 
> signers/signatures. For a 100 input transaction, we get big gains from the 
> owner or owners of the inputs choosing to use this algo, but that would 
> mostly be lost if either the verifying was linear in the number, or if the 
> size of the signature was linear in the number. So to avoid that we want a 
> (R, s) structure to be actually published, not an (R1..Rn, s) or a (R, 
> s1..sn). That pretty much forces us to make a sum R for all the individual 
> component's R-values, and the same for s.
>
> However it doesn't quite force us to add literally everything. The pubkeys 
> *can* be kept separate, because they are retrieved implicitly from the 
> existing blockchain record, they are not published with the signature 
> (taproot). (Technically the same comment applies to the message being 
> signed). This allows us to use the more "pedestrian", "safe" idea; we are 
> not aggregating keys (as in MuSig) so we can actually add each with its own 
> challenge hash: sum( challenge_hash_i * X_i). This may worry you that there 
> is a performance issue because the verifier has to iterate through that 
> whole list ( the verification equation being: sG =?= R + c_1 X_1 + c_2X_2 + 
> .. ), but the paper specifically claims that comparing this with just batch 
> verifying the individual signatures (i.e. without CISA), this is twice as 
> fast.
>
> So one could simplistically say "OK that's the pubkey side, they're 
> treated individually so we don't have to worry about that, but what about 
> adding the R values?" ("worry" here means: trivial key subtraction attacks 
> or sophisticated Wagner/ROS grinding). And here what is done is basically 
> the same as in MuSig2, which is to say, by breaking the nonce into two 
> components and including an additional challenge hash, you prevent the 
> counterparty/adversary from grinding R values successfully. Note that the 
> "b" coefficient used here is more explicit about hashing the full context, 
> than it was in MuSig2: it's hashing each individual pubkey and message as 
> well as the R2 subcomponents for each party. This is vaguely similar to 
> "client side validation" ideas: it's not really "validation" as in state 
> updates, but it's having the more complex/expensive part of the calculation 
> being done in the coordination before anything goes on-chain, and allowing 
> us to just use a single "R" value onchain that we know is safe.
>
> (Side note: it's worth remembering that a lot (maybe a huge majority?) of 
> the usage of CISA will be a single signer of multiple inputs; for these 
> cases there is not the same security arguments required, only that the 
> final signature is not leaking the private key!).
>
> That side note reminds me of my first question: would it not be 
> appropriate to include a proof of the zero knowledgeness property of the 
> scheme, and not only the soundness? I can kind of accept the answer "it's 
> trivial" based on the structure of the partial sig components (s_k = r_k1 + 
> br_k2 + c_k x_k) being "identical" to baseline Schnorr?
>
> The side note also raises this point: would it be a good idea to 
> explicitly write down ways in which the usage of the scheme/structure can, 
> and cannot, be optimised for the single-party case? Intuitively it's 
> "obvious" that you may be able to streamline it for the case where all 
> operations happen on the same device, with a single owner of all the 
> private keys. I realize that this is a thorny point, because we explicitly 
> want to account for the corruption of parties that are "supposed" to be the 
> same as the honest signer, but aren't.
>
> And my last question is about this multi-component-nonce technique:
>
> Did you consider the idea of e.g. sending proofs of knowledge of R along 
> with R in the coordination step? This would keep the same number of rounds, 
> and I'm assuming (though not sure exactly) that it makes the security proof 
> significantly simpler, but my guess is you mostly dismiss such approaches 
> as being too expensive for, say, constrained devices? (I imagine something 
> like: 2 parties say, X1 sends (R1, pi_R1) and same for X2, to coordinator, 
> then sum directly for overall R; here pi_R1 is ofc just a schnorr sig on 
> r). If we're talking about bandwidth the current "ctx" object is already 
> pretty large, right, because it contains all the pubkeys and all the 
> messages (though in bitcoin they could be implicit perhaps).
>
> (I won't mention the other idea, which is going back to MuSig1 style and 
> just committing to R, because that's what both MuSig2 and FROST went away 
> from, preferring fewer rounds.)
>
> By the way after writing this overly long post I realised I didn't even 
> get in to the really tricky part of the algorithm, the "check our key and 
> message appears once" part because of the multisig-to-aggregated-sig 
> transformation and the hole previously identified in it, which to be fair 
> is the most interesting bit. Oh well, another time!
>
> Cheers,
> AdamISZ/waxwing
> On Thursday, April 17, 2025 at 10:38:46 AM UTC-6 Jonas Nick wrote:
>
>> Hi list, 
>>
>> Cross-Input Signature Aggregation (CISA) has been a recurring topic here, 
>> aiming 
>> to reduce transaction sizes and verification cost [0]. Tim Ruffing, 
>> Yannick 
>> Seurin and I recently published DahLIAS, the first interactive aggregate 
>> signature scheme with constant-size signatures (64 bytes) compatible with 
>> secp256k1. 
>>
>> https://eprint.iacr.org/2025/692.pdf 
>>
>> Recall that in an aggregate signature scheme, each signer contributes 
>> their own 
>> message, which distinguishes it from multi- and threshold signatures, 
>> where all 
>> signers sign the same message. This makes aggregate signature schemes the 
>> natural cryptographic primitive for cross-input signature aggregation 
>> because 
>> each transaction input typically requires signing a different message. 
>>
>> Previous candidates for constant-size aggregate signatures either: 
>> - Required cryptographic assumptions quite different from the discrete 
>> logarithm 
>> problem on secp256k1 currently used in Bitcoin signatures (e.g., groups 
>> with 
>> efficient pairings). 
>> - Were "folklore" constructions, lacking detailed descriptions and 
>> security 
>> proofs. 
>>
>> Besides presenting DahLIAS, the paper provides a proof that a class of 
>> these 
>> folklore constructions are indeed secure if the signer does _not_ use key 
>> tweaking (e.g., no Taproot commitments or BIP 32 derivation). Moreover, 
>> we show 
>> that there exists a concrete attack against a folklore aggregate 
>> signature 
>> scheme derived from MuSig2 when key tweaking is used. 
>>
>> In contrast, DahLIAS is proven to be compatible with key tweaking. 
>> Moreover, it 
>> requires two rounds of communication for signing, where the first round 
>> can be 
>> run before the messages to be signed are known. Verification of DahLIAS 
>> signatures is asymptotically twice as fast as half-aggregate Schnorr 
>> signatures 
>> and as batch verification of individual Schnorr signatures. 
>>
>> We believe DahLIAS offers an attractive building block for a potential 
>> CISA 
>> proposal and welcome any feedback or discussion. 
>>
>> Jonas Nick, Tim Ruffing, Yannick Seurin 
>>
>>
>> [0] See, e.g., https://cisaresearch.org/ for a summary of various CISA 
>> discussions. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/604ca4d2-48c6-4fa0-baa6-329a78a02201n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 10217 bytes --]

 permalink raw reply	[|nested]
2025-04-26 17:05   ` waxwing/ AdamISZ

  2025-04-30 15:54       ` waxwing/ AdamISZ
  
From: Jonas Nick @ 2025-04-30  7:59 UTC (permalink / raw)
  To: bitcoindev

Thanks for your comments.

 > That side note reminds me of my first question: would it not be appropriate
 > to include a proof of the zero knowledgeness property of the scheme, and
 > not only the soundness? I can kind of accept the answer "it's trivial"
 > based on the structure of the partial sig components (s_k = r_k1 + br_k2 +
 > c_k x_k) being "identical" to baseline Schnorr?

That partial signatures do not leak information about the secret key x_k is
implied by the security theorem for DahLIAS: If information would leak, the
adversary could use that to win the unforgeability game. However, the adversary
doesn't win the game unless the adversary solves the DL problem or finds a
collision in hash function Hnon.

 > The side note also raises this point: would it be a good idea to explicitly
 > write down ways in which the usage of the scheme/structure can, and cannot,
 > be optimised for the single-party case?

This is a very interesting point, probably out of scope for the paper. A
single-party signer, given secret keys xi, ..., xn for public keys X1, ..., Xn
can draw r at random, compute R := r*G and then set s := r + c1*x1 + ... +
cn*xn. So this would only require a single group multiplication.

 > On that last point about "proof of knowledge of R", I suddenly realised
 > it's not a viable suggestion: of course it defends against key subtraction
 > attacks, but does not defend at all against the ability to grind nonces
 > adversarially in a Wagner type attack

We believe Appendix B provides a helpful characterization of "Wagner-style"
vulnerabilities. Roughly speaking, it shows that schemes where the adversary can
ask the signer to produce a partial signature s = r + c*x or s' = r + c'*x such
that c != c' then the scheme is vulnerable. In your "proof of knowledge of R
idea", the adversary can choose to provide either R2 or R2' in a signing
request, which would result in the same "effective nonce" r being used be the
signer but different challenges c and c'.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f9e082e3-4079-40b6-aa49-5d1b9b3b1e29%40gmail.com.


 permalink raw reply	[|nested]
2025-04-30  7:59     ` Jonas Nick

  
From: waxwing/ AdamISZ @ 2025-04-30 15:54 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 4406 bytes --]


> That partial signatures do not leak information about the secret key x_k 
is 
implied by the security theorem for DahLIAS: If information would leak, the 
adversary could use that to win the unforgeability game. However, the 
adversary 
doesn't win the game unless the adversary solves the DL problem or finds a 
collision in hash function Hnon.

OK, so that's maybe a theoretical confusion on my part, I'm thinking of the 
HVZK property of the Schnorr ID scheme, which "kinda" carries over into the 
FS transformed version with a simulator (maybe? kinda?). Anyway this is a 
sidetrack and not relevant to the paper, so I'll stop on that.

> This is a very interesting point, probably out of scope for the paper. A 
single-party signer, given secret keys xi, ..., xn for public keys X1, ..., 
Xn 
can draw r at random, compute R := r*G and then set s := r + c1*x1 + ... + 
cn*xn. So this would only require a single group multiplication.

I feel bad for saying so, but I absolutely do believe it's in scope of the 
paper :) If there is a concrete, meaningful optimisation that's both 
possible and sensible (and as you say, there is such an ultra-simple 
optimisation ... I guess that's entirely correct!), then it should be 
included there and not elsewhere. Why? Because it's exactly the kind of 
thing an engineer might want to do, but it's definitely not their place to 
make a judgement as to whether it's safe or not, given that these protocols 
are such a minefield. I'd say even if there is *no* such optimisation 
possible it's worth saying so.

I guess the counterargument is that it's suitable for a BIP not the paper? 
But I'd disagree, this isn't purely a bitcoin thing.

On the third paragraph, yeah, as per earlier email, I realised that that 
just doesn't work.

On Wednesday, April 30, 2025 at 9:03:34 AM UTC-6 Jonas Nick wrote:

> Thanks for your comments.
>
> > That side note reminds me of my first question: would it not be 
> appropriate
> > to include a proof of the zero knowledgeness property of the scheme, and
> > not only the soundness? I can kind of accept the answer "it's trivial"
> > based on the structure of the partial sig components (s_k = r_k1 + br_k2 
> +
> > c_k x_k) being "identical" to baseline Schnorr?
>
> That partial signatures do not leak information about the secret key x_k is
> implied by the security theorem for DahLIAS: If information would leak, the
> adversary could use that to win the unforgeability game. However, the 
> adversary
> doesn't win the game unless the adversary solves the DL problem or finds a
> collision in hash function Hnon.
>
> > The side note also raises this point: would it be a good idea to 
> explicitly
> > write down ways in which the usage of the scheme/structure can, and 
> cannot,
> > be optimised for the single-party case?
>
> This is a very interesting point, probably out of scope for the paper. A
> single-party signer, given secret keys xi, ..., xn for public keys X1, 
> ..., Xn
> can draw r at random, compute R := r*G and then set s := r + c1*x1 + ... +
> cn*xn. So this would only require a single group multiplication.
>
> > On that last point about "proof of knowledge of R", I suddenly realised
> > it's not a viable suggestion: of course it defends against key 
> subtraction
> > attacks, but does not defend at all against the ability to grind nonces
> > adversarially in a Wagner type attack
>
> We believe Appendix B provides a helpful characterization of "Wagner-style"
> vulnerabilities. Roughly speaking, it shows that schemes where the 
> adversary can
> ask the signer to produce a partial signature s = r + c*x or s' = r + c'*x 
> such
> that c != c' then the scheme is vulnerable. In your "proof of knowledge of 
> R
> idea", the adversary can choose to provide either R2 or R2' in a signing
> request, which would result in the same "effective nonce" r being used be 
> the
> signer but different challenges c and c'.
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a9f133ff-1d8e-45a3-8186-79fb52bbd467n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5189 bytes --]

 permalink raw reply	[|nested]