Design and implement framework for wallet cosigners

[GoogleCodeExporter]

E.g for BitGo, TrustedCoin, Trezor etc.

I have not looked deeply at this yet. But probably the steps involved are:

1) Make wallet TX completion async, returning a 
ListenableFuture<CompletionResult>. This may be needed for Trezor integration 
and other things in future when the process of signing a transaction isn't 
more-or-less immediate.

2) Teach the wallet how to handle 2-of-3 multisig coins and how to use P2SH 
outputs.

3) Allow the wallet to have pluggable SigningEngine objects (or a better name). 
SigningEngine's would identify keys they know how to sign for (i.e. because 
they are derived from a particular HD root) and the wallet could ask them to 
contribute signatures to a completion operation. The existing signing code 
should just become a regular SigningEngine.

4) Better integrate BIP70 into the wallet SendRequest API so info about tx 
destinations can be incorporated into the server-side risk analysis. Expose it 
to SigningEngine's so they can upload to the server/send to the Trezor.

5) Set up an example of how to do it, documentation, ideally write or obtain 
SigningEngine's for popular cosigners.

Original issue reported on code.google.com by mh.in.en...@gmail.com on 16 Mar 2014 at 7:05

[GoogleCodeExporter]

Generally looks good to me, but bear in mind Futures cannot be re-attached. I'm 
afraid this can lead to problems if users accidently rotate or switch off their 
display because they're busy fishing for their Trezor.

I'm not sure if bitcoinj should control the flow in this case. This works with 
the P2P protocol (PeerGroup) because it doesn't involve user interaction. The 
approach doesn't work with the payment protocol (PaymentSession) for example, 
because it has lots of interaction and the UI flow is spread out to many parts 
of wallet apps (at least Bitcoin Wallet). I'm afraid for co-signing it will be 
similar.

An alternative would be to provide an API for fetching the current signing 
status (e.g. which signature provider needs to sign), allow to provide 
additional signatures and tie all that either to transactions or to structures 
that represent incomplete transactions but will still be persisted to the 
wallet. Let the app stay in charge for retrieving the signatures from providers.

Original comment by andreas....@gmail.com on 16 Mar 2014 at 7:37

[GoogleCodeExporter]

I don't see why it'd be a problem. For rotation and other rebuilds you can just 
pass it through as non-configuration data (or use a static variable). Android 
has support for that. Same as for AsyncTasks. If the app is actually shut down 
before the future completes, no problem, it just gets thrown away ... same as 
any other in-memory object.

As part of this work, we'd need to prototype what it looks like on Android. I'm 
sure it can be done in a simple manner.

Original comment by mh.in.en...@gmail.com on 16 Mar 2014 at 8:21

[GoogleCodeExporter]

Non-configuration data (or its replacement, retained fragments) only work as 
long as you stay within the same UI component (fragment, or at least activity). 
You can't serialize/deserialize a Future. But ok, this usecase is likely 
limited to the send coins screen.

You'd want to avoid throwing away a users payment request. That's bad UX. I 
plan to move transaction completion and signing to a service for that reason, 
as its more robust to forced shutdowns.

There might be simple but effective signature providers that just delay their 
signature by an hour or so, so that the user gains time. Its very unlikely a 
Future will survive that long, even if the app used static variables (which are 
out of the question for obvious reasons anyway).

Original comment by andreas....@gmail.com on 16 Mar 2014 at 9:48

[GoogleCodeExporter]

Actually there's no reason you can't serialize a future. It's just that most 
aren't designed to support that. I guess if you wanted to be able to stop a 
wallet signing operation half way through and resume later, it could be 
supported. But for now I'd rather punt on that and assume transactions can be 
completed "quickly", at least quickly enough that it's OK to throw it away if a 
user task switches and Android kills the app to free up resources.

Original comment by mh.in.en...@gmail.com on 16 Mar 2014 at 10:07

[GoogleCodeExporter]

One of the possible controls for a third-party signer is a delay.  This is 
implemented by TrustedCoin and us (CryptoCorp).  These delays could be quite 
long - e.g. several hours.  It would be good to have an API that can persist 
pending transactions with a good UX.

Original comment by c1.devra...@niftybox.net on 4 Apr 2014 at 1:34

[GoogleCodeExporter]

We should also do something to lock the inputs of a partially signed 
transaction, so that they are not re-spent during the signing process.

Original comment by c1.devra...@niftybox.net on 4 Apr 2014 at 1:58

[GoogleCodeExporter]

I posted design notes to the mailing list under the name "married wallets":

https://groups.google.com/forum/#!topic/bitcoinj/Uxl-z40OLuQ

Original comment by mh.in.en...@gmail.com on 10 Apr 2014 at 11:32

[GoogleCodeExporter]

Kosta Korenkov has been making great progress on this and many parts of the 
design doc above are now implemented in git master. He seems to be planning to 
go all the way to the end. Perhaps we'll even have this implemented for 0.12

Original comment by mh.in.en...@gmail.com on 29 Jun 2014 at 11:31

• Changed state: Started

[GoogleCodeExporter]

A framework for this has been done, though async signing for Android is still 
awaiting implementation.

Original comment by mh.in.en...@gmail.com on 22 Sep 2014 at 2:42

• Changed state: Fixed