Nostr Web Client

🔖 Title: Blinded 2-party Musig2

🏷️ Categories: bitcoin-dev

nostr:naddr1qqjrvdp58p3xyetp95urgefk956xywpj95unvceh95urscm9xscnwc34xa3r2qg5waehxw309aex2mrp0yhxgctdw4eju6t0qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqguwaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6q3q2llycjh8gg2lhy4aph9c5au8ch5s0km5axrlxrc6e24dnsaqyu0sxpqqqp65wlg6d5k

⚠️ Heads up! We've now started linking to replaceable long-form events (NIP-23), which allow for dynamic display of thread details like summaries, authors, and more. If you're unable to see this, your client may not support this feature yet.

Reply to this note

Please Login to reply.

Discussion

moonsettler [ARCHIVE] 2y ago

📅 Original date posted:2023-07-26

🗒️ Summary of this message: The author proposes a solution to the blinding issue in a signature protocol and seeks feedback on its correctness.

📝 Original message:

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

Verification:

Rv = sG - eX

ev = hash(R||X||m)

e ?= ev

https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb

Been trying to get a review on this for a while, please let me know if I got it wrong!

BR,

moonsettler

------- Original Message -------

On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev wrote:

> > 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

> signature verification and then check c == c'? If true, then the server has the

> preimage for the c received from the client, including m.

> _______________________________________________

> bitcoin-dev mailing list

> bitcoin-dev at lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

e9a17810... 2y ago

📅 Original date posted:2023-07-26

🗒️ Summary of this message: The scheme for blinding the challenge works well and doesn't require modifying the aggregated pubkey. The receiver of a statecoin would verify the signatures and transactions.

📝 Original message:

@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 the server that would need to verify that the

challenge is 'well formed', but the receiver of a statecoin. The concept of

having a blinded statechain server is that each signature generated for a

shared public key must be verified by the receiver of the corresponding

coin. So a receiver would retrieve the number of co-signings performed by

the server (K) and then verify each of the K signatures, and K transactions

that they have received from the sender. They can additionally verify that

each of the K R values has been correctly formed with a proof of secret

value for creating R2 (along with the R1 from the server).

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230726/28eeeab3/attachment-0001.html>