Facilitate delegation of taker role

[Giszmo]

For lightweight clients it would be desirable to out-source the JM taker stuff to a server.

The scripts currently require a private key for a UTXO, which is obviously not desirable, especially considering hardware wallets that are designed to not share these.

To my understanding, the private key is used to sign a NACL key pair for later use in the JM communication.

A desired first, simple interface would be a create-unsigned-tx.py that takes a signed NACL key, a UTXO set and a list of recipient-amount-pairs, maybe with timeout, max-fee, ... , so it can be called from a secondary component as a low-trust black box.

[AdamISZ]

In broad outline, you can make the modifications like this I think:

In create-unsigned-tx.py, you can change the input values (obv changing from command line input to whatever mechanism) so that the client passes to it a btc signature parameter instead of passing a privkey on the command line. That btc sig parameter can be put in the UnsignedTXWallet object.

You will need to modify the taker.py CoinJoinTx class: remove this and replace it with a call to the UnsignedTXWallet class to grab the signature and include in the call to send_auth().

As we mentioned on IRC, this leaves the question of whether you'll have an extra round trip to the client: after client asks for TX, you send him the newly created nacl pubkey, and he sends back the signature. Or, you have some kind of caching mechanism, so that the client has already stored a list of ready-to-use nacl pubkeys that you delivered. Then he can send the signature with the proposal at the start.

Edit: additional point, your server side joinmarket could run with a single nacl pubkey. I don't really see a problem with that.

[AdamISZ]

As a more general comment, and this is for other readers not you @Giszmo as we already discussed it, it's of course no accident that this is messy. It's far preferable if the clients/peer level wallets do the whole thing; that's why we set up the MITM prevention as described in encryption_protocol.txt in the first place. Having a server in between that learns the mapping is undesirable.

But it's also very clear why you want to do it this way, at least at the start. The really interesting question to me is whether there is any mechanism to allow a client wallet to defer joinmarket code to a server, and still hide the mapping. If we're not talking coinshuffle, it might be something similar (more than one encryption layer). I haven't thought about it much yet.

[AdamISZ]

@dcousens @Giszmo I added this message protocol spec (early draft of course): https://github.com/chris-belcher/joinmarket/wiki/Joinmarket-Messaging-Protocol .. based on a first try from way back. Pinging you here as it may be of use.

[dcousens]

@AdamISZ that is awesome, thanks. I hadn't seen that yet.
I'd figured most of that out by now, but, seeing it written up gives me something to test against more clearly.

Thank you!

[Giszmo]

Thank you all for the feedback so far. I guess the proxying is highly valuable for general adoption and just to bring up another way of how proxying could look like in my use case: I'm looking now into how to get the python scripts onto Android with P4A considering to wrap JM in a separate app that a wallet could talk to. We really don't want this communication to run through our servers but we neither want to bundle yet another ton of potentially wallet-stealing code with our app and I bet others are in a similar situation. JM should not be a wallet and still be able to provide JM to wallets.

[AdamISZ]

JM should not be a wallet and still be able to provide JM to wallets.

I totally understand that point of view, and I started from that position too. The first big issue is the mixing depths structure. If a wallet doesn't use that (and of course, none currently do) then we have a problem, as the design of JM is based on that - in the case of a maker bot, or a tumbler bot (multiple coinjoin runs).

So either an existing wallet changes its internal design to reflect mixing depths, or an entirely new fully functional wallet is written with JoinMarket in mind. I was worried when we started that introducing a wallet would create problems, but there is not much that can be done about it.

I think that JM sendpayment should not (need to) be a wallet. You'll notice that there's already the option of using the BitcoinCoreWallet in that case.

[dcousens]

@AdamISZ is there a write up anywhere of the mixing depths structure?

[chris-belcher]

As long as your wallet is only a taker you shouldn't need to use mixing depths.

An explanation of the concept https://github.com/chris-belcher/joinmarket/wiki/Using-the-JoinMarket-internal-wallet#structure

[AdamISZ]

oh yes, my mistake. not just sendpayment, tumbler also, so any taker indeed.

[Giszmo]

https://github.com/Giszmo/joinmarket/tree/joinmarketProxy is my attempt so far to strip the nacl key signing out of taker. create-unsigned-tx-proxy.py starts a server that can be fed according to create-unsigned-tx-proxy.py. I will flesh it out some more before turning it into a pull request but comments are welcome.

[raedah]

The code should be converted from using Flask, to using SimpleHTTPServer as ob-watcher.py does.

[AdamISZ]

Although the discussion diverged, the original issue has now been addressed in 0.2.* (although a new, related issue arises - the PoDLE commitment required)and so is no longer an issue (plus this is old!). So, closing.