Integrating Dispute Resolution

[ariard]

So I’m re-reading the code of the architectural components of the Civkit (civkit-api, civkit-chat, civkit-frontend).

In my understanding, the flow is the following (from reading server.ts):

• a maker order is generated on the server
• a taker is sending a taker order to the server
• a taker invoice is generated on the server
• the taker pay through lightning the invoice
• order is market as completed

Now, there is the handling of dispute resolution in the Civkit chat client /api/chat/raise-dispute/:chat_id.

Somehow, and the original idea in the Civkit design was to dissociate the 3 components:

• the payment system
• the market place / order book
• the dispute arbitrators

So we could have a small client + server, where maker and taker are connecting to and write their dispute messages.

[ariard]

For dispute resolution, re-reading the 6.2 and 6.3 Advanced Escrow which are describing ideas on how to implement escrow.

The simplest solution would be to have an on-chain 2-of-3 CHECKMULTISIG.

The more advanced solution on lightning would be to do a pay-to-contract, where the HTLC public key is tweaked.

However, it makes the moderator necessarily involved in every trade as the secret tweak would have to be released everytime.

I’ll think more if there is a workable trick to have a over-LN: “either A+B or A+Moderator or B+Moderator” semantic.

Key tweaking can be done opaquely without modifying LN implems, at least for the ones supporting VLS-like interfaces.