Bitcoin Forum
September 27, 2018, 11:06:27 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Blind signatures using Bitcoin-compatible ECDSA  (Read 4511 times)
oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
January 30, 2014, 04:03:04 PM
 #1

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.


Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2520
Merit: 1514



View Profile
January 30, 2014, 04:06:57 PM
 #2

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

Bitcoin will not be compromised
oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
January 30, 2014, 04:08:21 PM
 #3

Bingo. Thanks.

Anyway, are there working solutions somewhere?

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
January 30, 2014, 04:16:23 PM
 #4

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.

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
February 17, 2014, 03:07:43 PM
 #5

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.

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2730
Merit: 1094



View Profile
February 18, 2014, 12:46:06 AM
 #6

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

Crowex
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
February 18, 2014, 05:37:19 AM
 #7

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?
Crowex
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
February 18, 2014, 06:11:28 AM
 #8

I don't understand how you are calculating P using the inverse of p?
Ok, I should have thought about it! I think I see what you mean.
da2ce7
Legendary
*
Offline Offline

Activity: 1221
Merit: 1000


Live and Let Live


View Profile
February 18, 2014, 06:15:01 AM
 #9

really cool, watching.  Cheesy

One off NP-Hard.
da2ce7
Legendary
*
Offline Offline

Activity: 1221
Merit: 1000


Live and Let Live


View Profile
February 18, 2014, 06:16:12 AM
 #10

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

One off NP-Hard.
oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
February 18, 2014, 09:23:12 AM
 #11

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?

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

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
February 18, 2014, 09:36:24 AM
 #12

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.

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.

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2730
Merit: 1094



View Profile
February 18, 2014, 10:40:38 AM
 #13

Broken link, see below.

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

oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
February 18, 2014, 01:53:42 PM
 #14

http://paper.ijcsns.org/07_book/200706/20070637.pdf

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

Link seems to be broken.

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
davidpbrown
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


Vires in Numeris


View Profile WWW
February 18, 2014, 02:02:39 PM
 #15

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 )

฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2730
Merit: 1094



View Profile
February 19, 2014, 01:28:40 AM
 #16


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

oleganza
Full Member
***
Offline Offline

Activity: 200
Merit: 100


Software design and user experience.


View Profile WWW
March 12, 2014, 11:33:55 AM
 #17

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

Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo
kactech
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
October 26, 2014, 05:40:06 PM
 #18

Btw, here's a second draft, a better worded and formatted one.
http://oleganza.com/blind-ecdsa-draft-v2.pdf
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.
LuaPod
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
November 10, 2014, 01:20:34 AM
 #19

Btw, here's a second draft, a better worded and formatted one.
http://oleganza.com/blind-ecdsa-draft-v2.pdf
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.


This actually sounds remarkably similar to something I am working on:
https://bitcointalk.org/index.php?topic=852917.msg9489290#msg9489290
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1000



View Profile
November 10, 2014, 04:39:07 PM
 #20

Btw, here's a second draft, a better worded and formatted one.
http://oleganza.com/blind-ecdsa-draft-v2.pdf
Great work Oleg, superb thing, here is your 4. Core protocol in Go language, w/ playground https://gist.github.com/kac-/a25e8410beb2d1514f2c.

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

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!