Topic: Blind signatures using Bitcoin-compatible ECDSA (Read 4685 times)

Hi everybody,

Was wondering if it could be possible in some way to verify with certainty that a particular "blinder" participated in a particular blinding process?

Some kind of partially blinded signatures I guess.  Don't know if it could work with bitcoin though.

Thanx for your help.

Thanks, I will try to integrate secp256k1 into this if I get a chance.

This actually sounds remarkably similar to something I am working on:
https://bitcointalksearch.org/topic/m.9489290

Great work Oleg, superb thing, here is your 4. Core protocol in Go language, w/ playground https://gist.github.com/kac-/a25e8410beb2d1514f2c.

BTW:Has anybody tried to code it? It doesn't work for me.

Btw, here's a second draft, a better worded and formatted one.
http://oleganza.com/blind-ecdsa-draft-v2.pdf

Yes, this was it. Weird because I tested the prior link yesterday and it worked.

Perhaps is the same as http://dspace.nitrkl.ac.in/dspace/bitstream/2080/625/1/IJCSNS-V7-I6.pdf (via http://dspace.nitrkl.ac.in/dspace/handle/2080/625 )

Link seems to be broken.

Broken link, see below.

This is the one I was thinking about. Not exactly in your scheme but related, so might be useful.

Sorry, I use the same notation for brevity. By convention, all integers are lowercase symbols and points are uppercase. Also, point is always the last in the sequence of multipliers, like so: a*b*c*G which is equivalent to (a*b*c)*G. Hope this helps reading.

Calculate p^-1 and then multiply G by it.

@oleganza, I recommend cross-posting to the bitcoin development mailing list for more commentary.

really cool, watching. 

Ok, I should have thought about it! I think I see what you mean.

I'm finding your paper a bit difficult to understand because you use the same notation for scalar multiplication and point multiplication and likewise for addition.
I don't understand how you are calculating P using the inverse of p?

I have read some literature on this, let me see if I can find it.

I think I got it right this time:

http://oleganza.com/blind-ecdsa-draft-v1.pdf

If this works, then we all can enjoy private multi-party locks on our bitcoin stashes.

Ok, take two. What I need is some custom computation by third party that does not leak their private key, which can be transformed into a standard signature (r, s = (k^-1)*(h + f(d)*r) verifiable by a transformed public key f(d)*G. In other words, they may use non-standard signing scheme, but it should be transformable into a standard ECDSA signature used in Bitcoin.

Bingo. Thanks.

Anyway, are there working solutions somewhere?

They'll recognize r when they see it in the network.

I was searching how to make blind signatures based on standard ECDSA and couldn't find anything useful. I found a 10-year old paper with a proposal, but it proposes a formula incompatible with the standard ECDSA signature that is used in Bitcoin: http://mshwang.ccs.asia.edu.tw/www/myjournal/P191.pdf

My goal is to lock funds in a usual multisig transaction where private keys belong to N friends. When they sign my transaction, they should not be able to see what is being spent or where it goes from and to. Splitting the key using SSSS ("Shamir's Secret Sharing Scheme") is not the perfect option as the recovered secret must be applied on a single machine that may not be trusted (think regular Win PC). When multisig transaction is being signed by every participant, no machine is able to spend the funds arbitrarily.

My question to experts is whether the following algorithm that uses a simple multiplication factor is workable:

TL;DR:

1. You send money to x*pubkey instead of pubkey. (x is your secret integer - "blinding factor")
2. You ask third party to sign (hash/x) instead of hash of tx itself.
3. You use x*signature to redeem funds.

More specifically:

Part 1. Sending the funds:

1. Trusted party gives you their public key D (D = d*G, d — private key, G — standard generator point).
2. You choose secret random integer x ("blinding factor")
3. Compute public key D2 = x*D
4. Send money to D2 (it could be one of the keys in multisig script).
5. Store in your encrypted wallet info about x, D and the transaction to spend it later.

Part 2. Redeeming funds:

1. Compute the hash h = signatureHash(tx).
2. Compute h2 = (h / x) mod n (n — order of our curve secp256k)
3. Send to the third party h2 to be signed with their private key d.
4. Third party sends back to you a usual ECDSA signature (r,s) where s = (k^-1)(h2 + d*r)
5. You multiply s by x and get s2 = x*s = (k^-1)(x*h2 + x*d*r)
6. This new signature (r,s2) is equivalent to a signature of h signed with a private key x*d.
7. Neither you, nor third party knows x*d (only you know x, only they know d), but you know x*d*G = x*D = D2 — a public key derived from their public key.
8. So the signature (r,s2) is a valid signature of message h verifiable by public key D2=x*D.
9. You publish your transaction with signature (r,s2) and the third party cannot know that it was signed by them.

Is there a fault somewhere? What do you think?

Thanks.

EDIT: This scheme fails. As gmaxwell pointed out below, r is not blinded and will be recognized by the signing party.