Bitcoin multisig scheme that prevents theft by middle-man operator

Question

Background

I'm considering building a service that allows participants in my industry to strike OTC deals with each other using my centralized matchmaking service.

The deals always involve two players, both of whom deposit Bitcoin collateral at the start of the deal. Let's call our two players PlayerA and PlayerB. As the Operator, I track how their deal progresses and internally move Bitcoin back and forth between the two players as the deal unfolds. This reconciliation takes place at the close of each day and it's internal to my system. It's not posted to the Bitcoin blockchain.

If one or both parties want out of the deal, the deal is considered "settled" and one party will have a realized loss and the other a gain. It's a zero sum game.

Problem

"Not your keys, not your coin."

Players have asked to interact with one another in such a manner that settlements are made peer-to-peer without me as Operator having access to the private keys that control their collateral deposits. This would prevent me from absconding with their funds.

I suspect I'm not smart enough to come up with the correct solution, or even if said solution is possible, but I want to at least try.

What I've Sketched Out So Far

Consider this example:

Beginning Transactions: PlayerA spends 1 BTC such that the resulting UXTO can be redeemed by:

• PlayerA only: sixty day timelock, or
• PlayerA AND Operator at any time

The idea behind the sixty day wait is that if Operator bails on the project, never to be heard from again, PlayerA can ultimately redeem his funds.

Let's assume PlayerB does the same.

PlayerA and PlayerB find each other via the app and construct a deal. Each day the collateral is rebalanced according to how the deal is progressing. Let's say after four days of keeping the deal alive, PlayerB is ahead by .50 BTC and wants to settle up. The system then submits a transaction to PlayerA's node with the outputs:

• PlayerA: .50 BTC (PlayerA's remaining collateral)
• PlayerB: .50 BTC (PlayerB's winnings)

PlayerA signs the transaction. The Operator signs it too and posts it on the blockchain. PlayerB gets his .50 BTC and PlayerA gets his remaining .50 BTC collateral. The deal is now closed.

What I Can't Figure Out

I don't understand how to prevent PlayerA from walking away from the transaction. He knows he's down .50 BTC and he knows I can't force him to sign the closing transaction. His incentive is to walk away.

I could of course arrange things so that I as Operator can unilaterally move the funds to PlayerB but that would give me complete control of PlayerA's funds -- exactly what we're trying to avoid, as I'd have the ability to steal the collateral.

Is there some clever way of using multisigs and time locks to incentivize PlayerA to realize his loss and sign the closing transaction? The logic would have to be constructed in such a way that if he refuses to sign after some predetermined period, he forfeits all of his collateral. And that collateral would be forfeited to PlayerB, not to me as the Operator.

With my limited knowledge of the Bitcoin programming language, I'm unsure how to pull it off. Any clever ideas? Not looking for code, just high-level overview of the Bitcoin primitives and tools that are available to me to accomplish my goal.

Answer 1

I can think about some possibilities.

You can use an DLCs (Discrete Log Contracts) with your platform as oracle. Each output can be redeemable by any part at any time, if you sign an attestation saying that it's indeed true of a given statement. You not even need to know which UTXO each participant holds, and let then verify this p2p. The only trust here is that you won't create a fraudulent attestation. I can even imagine a protocol for blinding the transactions, giving more privacy to your users, but this is more evolved and hard to do correctly.

Another way is asking for a signature for each participant every time an order is matched, so you'll have an up-to-date sig from each one, and can build a tx with the current state at any time. This is similar to how Lightning works, and need to be implemented carefully.