new paper: Securing Bitcoin wallets via threshold signatures

gmaxwell

staff

Activity: 4242

Merit: 8672

Quote from: Mike Hearn on March 09, 2015, 07:39:15 PM

The source is here:

https://github.com/citp/TwoFactorBtcWallet/

They've eliminated the trusted setup requirement.

Hm. I cannot find the distributed setup in that source code. Can you point me to it?

Mike Hearn

legendary

Activity: 1526

Merit: 1134

The source is here:

https://github.com/citp/TwoFactorBtcWallet/

They've eliminated the trusted setup requirement.

elm

legendary

Activity: 1050

Merit: 1000

any news?

ysangkok

newbie

Activity: 10

Merit: 3

AFAIK, the source release never happened. Why not? What happened?

Crowex

member

Activity: 111

Merit: 10

I pointed out in my thread where this was first posted that the degree of the dealer distributed polynomial should be t if you want the threshold to be t. They edited it but I'm going to have to wait until the next edit.

EDIT I've got a few versions of this pdf, the one with degree (t-1)/2 definitely didn't give a threshold of t but maybe the latest version is ok but it doesn't coincide with the original paper.

waxwing

sr. member

Activity: 469

Merit: 253

I do too, but it does rather temper the sense that it's a replacement for existing P2SH applications. (Escrow being the most obvious case, but also think about voting pools and probably many others).

instagibbs

member

Activity: 114

Merit: 12

Quote from: waxwing on April 01, 2014, 12:19:17 PM

Gives you an idea though of how messy it's going to be in distributed scenarios.

I think it will make most sense inter-machine for one user(security by spreading out "keys"), or a group of mutually known people.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: gmaxwell on March 31, 2014, 03:43:25 PM

They note in the paper that it's possible to do the dealing step in a distributed manner where no one party learns the key (indeed, the proposed protocol does something like that internally for sharing shares of the ECDSA nonce) but they don't go into detail about it. I think any practical implementation would want to do this simply due to the difficulty in obtaining a single device whose security you can be confident of...

All the details are in the Ibrahim et al paper (ref 11). This new paper just seems to be mostly a commentary on those algorithms ("by the way this works with Bitcoin and this is why it's cool").

I agree with all your points about advantages/disadvantages. It will be a bit clunky with the synchronicity. Note for example that the no-trusted-dealer secret sharing steps will require private communication channels between each of the participants; I guess the most natural way to implement might be to use encryption to pgp keys (some kind of ssl via a central server would defeat the purpose, after all). Gives you an idea though of how messy it's going to be in distributed scenarios.

gmaxwell

staff

Activity: 4242

Merit: 8672

Quote from: trout on March 31, 2014, 09:46:44 AM

In the suggested approach there's an owner of the full private key, who then can share this private key
so that "m of n" transactions can be made, but he still can use the whole private
key to spend the balance himself.

They note in the paper that it's possible to do the dealing step in a distributed manner where no one party learns the key (indeed, the proposed protocol does something like that internally for sharing shares of the ECDSA nonce) but they don't go into detail about it. I think any practical implementation would want to do this simply due to the difficulty in obtaining a single device whos security you can be confident of...

The differences I'd make between this and multisig is that it requires a synchronous protocol to both establish keys initially (assuming a distributed dealer) and to sign. E.g. it might be harder to make a signature using N offline wallets as you'd have to shuttle data back and forth to the offline wallets multiple times. It's also harder to 'show' that an address is multisig— e.g. for the purpose of making your policy public, though I'm not sure how much this matters since you can 'fake' multisig too. It also requires a more complex signer software. On the plus side it's much more efficient in the blockchain, esp with high N, and the transactions are indistinguishable from non-multisig which is good for privacy.

trout

sr. member

Activity: 333

Merit: 252

Very interesting paper!

Just to check my understanding on one point. In the suggested approach
there's an owner of the full private key, who then can share this private key
so that "m of n" transactions can be made, but he still can use the whole private
key to spend the balance himself. Is this correct?

That's a major difference with respect to the multisig approach.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

They told me they plan to release the code after working on it some more.

voisine

member

Activity: 115

Merit: 19

I would love to see the implementation they used to create their example transaction. Apparently built on top of bitcoinj. I don't see any references to it though. Also, are there any plans to turn this into a BIP?

roslinpl

legendary

Activity: 2212

Merit: 1199

at first yes it does looks very interesting.

Evolution of BTC safety is very important - even perhaps most important to make millions of new users join us!

iddo

sr. member

Activity: 360

Merit: 251

https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin
Alternatively, the direct PDF link is: http://www.cs.princeton.edu/~stevenag/bitcoin_threshold_signatures.pdf

Looks interesting at first glance...

Topic: new paper: Securing Bitcoin wallets via threshold signatures (Read 2430 times)