An update on progress on the development of the blinded two-party Schnorr
scheme for statechains.
As stated previously, we believe that one-more-signature and Wagner attacks
are mitigated by the client committing the values of the blinding nonce
used (labeled f) and the value of R2 used in a signi
Hi Tom,
Thanks for the explanation. There's one remaining thing that isn't clear:
do you actually require parallel signing requests under the same key. It
seems to me that the protocol is very sequential in that you are passing a
utxo from one point to another in sequence. If so then the Schnorr b
HI Lloyd,
Yes, the blind signatures are for bitcoin transactions (these are
timelocked 'backup txs' if the server disappears). This is not standard
'Schnorr blind signature' (like
https://suredbits.com/schnorr-applications-blind-signatures/) but a 2-of-2
MuSig where two keys are required to genera
Hi Tom,
These questions might be wrongheaded since I'm not familiar enough with the
statechain protocol. Here goes:
Why do you need to use schnorr blind signatures for this? Are the blind
signatures being used to produce on-chain tx signatures or are they just
for credentials for transferring own
@moonsettler
When anyone receives a coin (either as payment or as part of a swap) they
need to perform a verification of all previous signatures and
corresponding backup txs. If anything is missing, then the verification
will fail. So anyone 'breaking the chain' by signing something
incorrectly si
Very nice! Is there an authentication mechanism to avoid 'breaking the chain'
with an unverifiable new state by a previous owner? Can the current owner prove
the knowledge of a non-identifying secret he learned as recipient to the server
that is related to the statechain tip?
BR,
moonsettler
-
A follow up to this, I have updated the blinded statechain protocol
description to include the mitigation to the Wagner attack by requiring the
server to send R1 values only after commitments made to the server of the
R2 values used by the user, and that all the previous computed c values are
verif
No, proof of knowledge of the r values used to generate each R does not prevent
Wagner's attack. I wrote
> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>c[0] + ... + c[K-1] = c[K].
You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and
define R2[i] = r
A reasonable attack scenario might be: attacker gains control of client machine
and its privkey, wants to extract money. It first operates passively, waiting
for user to do 2FA on a normal transaction, only modifying the nonce used in
order to achieve its goal. Then, after that 1 transaction goe
Hello all,
1. No proof of knowledge of each R does *NOT* prevent wagner's attack.
2. In my mind, A generic blind signing service is sufficient for doing
blinded MuSig, Muig2, FROST or whatever without the blind signing service
knowing. You don't need a specialized MuSig2 blind singing service to
e
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).
___
bitcoin-d
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, 20
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 o
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 secur
@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 necessarily
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 discussio
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
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 Tue
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
Ver
Thanks for the replies. As I understand it, the v=2 nonces signing protocol
of musig2 prevents the Wagner attack. Also, that the challenge value c must
be blinded from the server to prevent the server from being able to
determine the signature from the on-chain state.
In addition, in order to upda
posk is "proof of secret key". so you cannot use wagner to select R
On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> @ZmnSCPxj:
>
> yes, Wagner is the attack you were thinking of.
>
> And yeah, to avoid it, you should have the 3rd round o
@ZmnSCPxj:
yes, Wagner is the attack you were thinking of.
And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R
commitments.
@Tom:
As per above it seems you were more considering MuSig1 here, not MuSig2. At
least in this version. So you need the initial commitments to R.
Hi ZmnSCPxj,
Yes, you are correct - the full scheme (
https://eprint.iacr.org/2020/1261.pdf) should have two or more nonces (and
also compute b). I don't think this changes the approach to blinding
however.
On Mon, Jul 24, 2023 at 11:50 AM ZmnSCPxj wrote:
> Good morning Tom,
>
> Would this allo
Hi Jonas,
Seems you are right: for every tx, compute c from the on-chain data, and
the server can match the c to the m (tx). So there would need to be a
method for blinding the value of c.
On Mon, Jul 24, 2023 at 4:39 PM Jonas Nick wrote:
> > Party 1 never learns the final value of (R,s1+s2) o
Hi Eric,
Yes, this was my thinking. The current statechain protocol requires that
the sender of a coin sign the statechain with their public key, which is
then verified by the receiver. The receiver also verifies that this
(sender) public key aggregated with the current server public key
correspon
Not sure what "posk" is or how it relates to the attack.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> Party 1 never learns the final value of (R,s1+s2) or m.
Actually, it seems like a blinding step is missing. Assume the server (party 1)
received some c during the signature protocol. Can't the server scan the
blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as in
signatur
You can't choose R if you provide posk
On Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Tom,
>
> I'm not convinced that this works. As far as I know blind musig is still
> an open
> research problem. What the scheme you propose appea
as long as all parties provide a proof of secret key along with their
public key, that should not be possible
or you can do it as a two-step process where all parties provide a
commitment to the public key and nobody reveals a public key until that
commitment is received
or if you want to be para
Hi Tom,
I'm not convinced that this works. As far as I know blind musig is still an open
research problem. What the scheme you propose appears to try to prevent is that
the server signs K times, but the client ends up with K+1 Schnorr signatures for
the aggregate of the server's and the clients k
Good morning Tom,
Would this allow party 2 to itself be composed of N >= 2 parties?
MuSig2 (as opposed to MuSig1) requires that signatories provide multiple `R`
points, not just one each, which are finally aggregated by first combining them
using the MuSig() public key compose function.
This pr
We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
it can hold a private key that is required to generate an aggregate
signature on an aggregate public key, but that it does not learn either: 1)
The aggre
33 matches
Mail list logo
