Scheme for locked funds with non responsive peers

[sqrrm]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Problem

Users are leaving funds locked up in the 2of2 and not responding to mediators. This forces the responsive party to spend the delayed payout tx, sending the funds to the donation address and taking the case to the refund agent. This adds a burden on the refund agent and the donation address holder, adds annoyance for the user and is costly for the DAO.

Current delayed payout

During trade initiation the buyer and seller send coins to a 2of2 multisig address, this is the deposit tx. They also sign a transaction that spends the output from the deposit tx to the donation address, the so called delayed payout tx. This transaction can only be spent after a certain block height.

Optional delayed spending scheme

Inspiration - lightning network

In the lightning network the setup is similar to Bisq's deposit tx, two parties, Alice and Bob, prepare spendable transactions from a 2of2 address. During normal operations these transactions are not broadcast, but they are used as a backup to motivate the counterparty to adhere to the rules of their lightning channel. If Bob disappears, Alice can spend one of these prepared transactions to cancel the channel and get her money back. Bob then has a time window to get his share before Alice can spend it all for herself.

Bisq case

For Bisq a similar scheme could be used in conjunction with the donation address.

1. Setup deposit txD
2. Prepare 3 time locked transactions that spend from the deposit tx
   1. Delayed txP, payout transaction that can spend txD:0 to the donation address after X blocks (how it works now)
   2. Delayed txA can spend txD:0 to 2of2 addressA after X+Y blocks
      1. Relative time lock txAA, can spend txA:0 to Alice with a relative time lock Z
      2. Payout to donation address txAP, spends txA:0 to donation address without time lock
   3. Delayed txB can spend txD:0 to 2of2 addressB after X+Y blocks
      1. Relative time lock txBB, can spend txB:0 to Bob with a relative time lock Z
      2. Payout to donation address txBP, spends txB:0 to donation address without time lock

This setup helps releasing funds to the users without going through the donation address in the cases where one party has disappeared. When both parties are active either one can broadcast txP to take the case to refund agent.

If Bob is not responsive, Alice can wait X+Y blocks to broadcast txA. If Bob is indeed gone, after another Z blocks she can then broadcast txAA to recover the funds. If Bob happens to be around, he can broadcast txAP before txAA can be spent to send the funds to donation address and continue with a refund case.

If Alice is not responsive Bob can do the same as Alice in the the previous case to recover the funds through the txB path.

Considerations

This adds an extra step in the non happy payout path. Not ideal when fees are increasing as they are. It also requires both parties to monitor for the personalized payout txs txA and txB respectively and spend to donation address if they don't want to lose the funds. This shouldn't be a big problem as txP could be broadcast earlier if they intended to take the case to refund agent. It's only a problem when one side is maliciously non responsive to try to steal the funds. A case which is handled and would not be possible to exploit.

[chimp1984]

I fear that does not work because there will be a race of both traders and none has a guarantee that the other is not publishing as well.

So if Alice was honest and want to avoid a refund agent case then she would wait until block X+Y to publish the tx where she receives all funds. Assume Bob is dishonest and try to get also the funds without having fulfilled the trade contract. He can also wait for block X+Y and publish the tx to him. Then there are 2 competing transactions and a 50% chance or each to win. Bob has better odds as he has less to lose (only the sec. deposit). So it is rational for Alice to not enter that game where she has worse odds and open a refund agent case instead and not risk to lose all the funds.

Also: The motivation to reduce refund agent cases are more on Bisq's/DAO side. For a user it is quite comfortable (in case the amount is not high and refund agent pays directly from his pocked without DAO reimbursement). Users are delegating the burden to the DAO (it was designed so to avoid too much friction for users).

[sqrrm]

There is no race. If Bob publishes txB, then Alice publishes txBP, which spends txB to the donation address, to take the case to the refund agent. If there is sign of life before X+Y time has passed, either party would publish txP to avoid the extra transaction.

For now, it works for the users as long as the refund agent is around and handling cases. For the cases where there is no refund agent and the counterparty disappeared, it would be much more comfortable to get the funds back immediately rather than having to rely on DAO voting.

[chimp1984]

Ah ok, read it again and yes, it seems it works.

Have you thought about the process how the txs are created and who is the last signer? The seller is the one who has more to lose so we use the seller as the one who has more control over the tx creation.

[sqrrm]

Didn't think closely on the practical part. I'm not sure we want to implement this as it adds more complexity and users need to know about it. It might be better to spend our time on reducing the number of transactions created rather than adding more.

But my instinct is that the current protocol with an extra step for the six new transactions can be part of and appended to the delayed payout tx signing. The initial risk doesn't change, seller is on the hook. Protocol won't continue without the full tree of transactions completed.

It might be good to let only Alice have the fully signed txA and only Bob have txB. That way blame can be attributed, although I'm not sure there is much value in attributing blame. The end result is a refund case which would've been the case if txP were broadcast anyway.

[RefundAgent]

This proposal would reduce the load on the arbitration system and thus the cost for the DAO. 15 of the last 20 cases for the Refund Agent have been due to disappearing traders. I see anything that can be automatic in software to be beneficial, and even more so if Bisq grows substantially.

[chimp1984]

The number of transactions would only increase in the event that it will be used, otherwise they are just signed not broadcast txs...
I just wonder if the scheme can fit in to the existing protocol without need for new roundtrips. Any new message added increases a bit risk and slows a bit down the process, so better if we can avoid that.
Maybe you can try to start sketch out which peer is the preparing part and the finishing part and which holds the fully signed tx and when and if its needed to share it back to the other peer.
With the delayed payout tx and deposit tx this is an important part to avoid blackmail risks and avoid that there can be cases where no delayed payout tx is shared. We need to ensure that here as well as otherwise it opens up ways to abuse it. We need to be able to verify the txs which are a chain of txs, so it comes with some complexity needed to be sketched out more in details.

Once we see that its feasible to add to the current protocol we should think about how we implement it from a UX perspective. As its an exceptional case I would prefer to not confuse users with it as long its not needed... But thats another field we should get a bit deeper.

[sqrrm]

It's one extra transaction if Alice tries to take the funds with txA and Bob has to publish txAP. The extra fees is not really a problem, but it would be a problem if one of these transactions don't get confirmed. In particular, if txAP don't confirm soon enough, then Alice can broadcast txAA and then spend that output with a high fee, CPFP.

Let _u, _a, _b, _ab indicate unsigned, partially signed by alice/bob and signed transactions.

I suspect one more roundtrip, or half a roundtrip more will be needed, quick logic on it:

1. Create deposittx
2. Alice as seller creates txP_a, txB_a, txA_u as all info needed could be provided in an earlier message. Sends to Bob.
3. Bob signs txP_ab, txA_b, txB_ab. Creates txBB_b, txBP_b, sends txP_ab, txA_b, txBB_b, txBP_b to Alice. (I think this is the last step in the current protocol, both parties have txP_ab)
4. Alice signs txBB_ba, txBP_ba, txA_ba. Creates txAA_a, txAP_a. Sends txBB_ba, txBP_ba, txAA_a, txAP_a to Bob. (Alice now has txP_ab, txA_ba, txBB_ba, 'txBP_ba`)
5. Bob signs txAA_ab, txAP_ab and sends them to Alice. (Bob has txP_ab, txB_ab, txBB_ba, txBP_ba, txAA_ab, txAP_ab)
6. Alice receives last message and has txP_ab, txA_ba, txBB_ba, txBP_ba, txAA_ab, txAP_ab

This is one round more. It could be shortened by one step by letting both parties have access to fully signed txA and txB. Need to think more in detail if there are any other issues with who can spend what, but I don't think so. The fact that txP_ab is known early in the sequence is all the security they need. One party could probably have a benefit of stopping the protocol earlier, such as Bob in step 5, not sending the fully signed txAA_ab and txAP_ab to Alice, but she wouldn't publish the deposit tx in that case.

Alice could stop after step 3 when she has txP_ab and then publish the deposit tx. That's the current protocol. In that case Bob could choose not to send the fiat.

[pazza83]

Hi @sqrrm thanks for the proposal. I am doing some housekeeping on the proposals. Please can you take steps to move this forward or alternatively close the proposal.

Many thanks.

Ref: https://bisq.wiki/Proposals

[sqrrm]

This would be part of the #279 protocol, closing.