new paper: Securing Bitcoin wallets via threshold signatures

[iddo]

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

[1714608895]

1714608895

[1714608895]

1714608895

[1714608895]

1714608895

[roslinpl]

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!

[voisine]

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?

[Mike Hearn]

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

[trout]

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.

[gmaxwell]

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.

[waxwing]

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.

[instagibbs]

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]

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

[Crowex]

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.

 

[ysangkok]

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

[elm]

any news?

[Mike Hearn]

The source is here:

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

They've eliminated the trusted setup requirement.

[gmaxwell]

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?