Hi waxwing,
Thanks again for your comments.
> My initial reaction would be, since it's not worsening the scaling of the
> verifier, does it matter?
I think saving time in signing does matter (3 group exponentiations requiring
O(1) group operations in total vs. O(n/log n) group operations); for
Hi Tim, answers inline:
> Your observation is right: If each participant has a distinct b_i as
you've sketched, then the duplicate checks can be omitted. And I tend
to agree that this is more natural scheme. In fact, this is where we
started, and we had a security proof of this (though without
First of all, again great to see that you look so carefully at the
paper.
Your observation is right: If each participant has a distinct b_i as
you've sketched, then the duplicate checks can be omitted. And I tend
to agree that this is more natural scheme. In fact, this is where we
started, and we
On the very important argument laid out in Appendix B:
(for readers, this part of the paper deals with this problem: if the scheme
can allow a scenario where the output "effective nonce" of an honest signer
is the same for two different contexts and thus have two difference
signature hashes (in
> 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 pro
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 c
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
t
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
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 Gr
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 Si
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 nuan
Hi Jonas and list.
So I'm reading the paper and it's very interesting. I have other questions
but this one seems more important so I'll just stick with this one:
Appendix A2 explains an attack on Musig2-IAS, in which you can forge a
partial signature on a tweaked key of the honest signer. I don
12 matches
Mail list logo
