None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
attack on the nonces, I mentioned an attack on the challenge c) can be prevented
by proving knowledge of the signing key (usually known as proof of possession,
PoP).
___
correct. you cannot select R if it is shipped with a POP
On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan wrote:
> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
> knowledge of the r values used to generate each R used prevents the Wagner
> attack, no?
>
> On Wed, Jul 26,
Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
knowledge of the r values used to generate each R used prevents the Wagner
attack, no?
On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick wrote:
> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
> attack
It's an interesting idea for a protocol. If I get it right, your basic idea
here is to kind of "shoehorn" in a 2FA authentication, and that the
blind-signing server has no other function than to check the 2FA?
This makes it different from most uses of blind signing, where *counting* the
number
Yes, thank you!
There I assume if someone has your private key, and can satisfy the 2FA, he
will just steal your coins, and not bother with extracting the co-signers key
that is specific to you. I can see, how this assumption is not useful generally.
BR,
moonsettler
Sent with Proton Mail
@moonsettler
Your scheme for blinding the challenge (e in your notation) works as far as
I can tell. It is better than the way I suggested as it doesn't require
modifying the aggregated pubkey (and the blinding nonce can be different
for each signature).
@AdamISZ and @Jonas
It is not
On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote:
> personally, i think *any* time a public key is transmitted, it should come
> with a "proof of secret key". it should be baked-in to low level
> protocols so that people don't accidentally create vulns. alt
While this may solve blinding, I don't see how it solves the problem that the
client can forge signatures because the client is in control of challenge e'.
This is not special to MuSig(2), but is also the reason why original blind
Schnorr signatures are insecure (as demonstrated in David Wagner's
> and I would like to understand why this problem has not been addressed more
> seriously
Because if nobody has any good solution, then status quo is preserved. If
tomorrow ECDSA would be broken, the default state of the network would be "just
do nothing", and every solution would be
I understand your point of view. However, inscription represent by far the
largest spam attack due to their ability to embed themselves in the witness
with a fee reduction.
Unlike other methods, such as using the op_return field which could also be
used to spam the chain, the associated fees
personally, i think *any* time a public key is transmitted, it should come
with a "proof of secret key". it should be baked-in to low level
protocols so that people don't accidentally create vulns. alt discussion
link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406
On
Hi All,
I believe it's fairly simple to solve the blinding (sorry for the bastard
notation!):
Signing:
X = X1 + X2
K1 = k1G
K2 = k2G
R = K1 + K2 + bX
e = hash(R||X||m)
e' = e + b
s = (k1 + e'*x1) + (k2 + e'*x2)
s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2)
sG = (K1 + K2 + bX) + eX
sG = R + eX
12 matches
Mail list logo
