@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
11 matches
Mail list logo
