@stejbac Since #373 has been closed, I would like to open this issue to discuss your idea from this comment.
If I understood your comment correctly, you think there are 3 operations on Lightning transactions;
pausing a lightning transaction
canceling a Tx (could be the build-in timeout)
forcing through a Tx. That means someone else than the sender of the transaction can make a paused transaction get completed even if the sender does not want this to happen.
The ideas of how to do 1 and 3 are outlined in #373, but not fully sketched out yet. But in the following I would like to assume these operations 1 to 3 as given, and we can use them as primitives to build a protocol.
The buyer and the seller could simply make Lightning transaction for the deposits and the trade amount. All 3 transaction would be set up to be paused automatically (primitive 1). The fiat money could be then be transferred. In the happy case, then seller then released the BTC. In case of arbitration the arbitrator has the options to do a cancellation (primitive 2) or a forced through transaction (primitive 3) for each of the 3 transactions separately.
The point I am trying to make here is that we don't need to send the funds to the arbitrator or the DAO. In fact, I think sending money to the DAO may be viewed as taking the money into custody. So the arbitrator, in this model, can only decide which of the trader gets the money, but neither the DAO or any other third-party gets in possession of the funds. In my opinion it may make things easier for the DAO as its not dealing with reimbursements and hopefully also easier for the protocol. Because the DAO is not part of the equation anymore.
Anyway, up to here it's not avalanche resistance, so not fulfilling the security property no. 5.
It would need some more thoughts on fixing security property 5, I have several ideas for that, but they need to be thought through first. But I am putting this out, because I think it makes the protocol simpler by restricting the 3 transactions to go to the buyer or seller only and not have any flow of money to another party.
@stejbac Since #373 has been closed, I would like to open this issue to discuss your idea from this comment.
If I understood your comment correctly, you think there are 3 operations on Lightning transactions;
The ideas of how to do 1 and 3 are outlined in #373, but not fully sketched out yet. But in the following I would like to assume these operations 1 to 3 as given, and we can use them as primitives to build a protocol.
The buyer and the seller could simply make Lightning transaction for the deposits and the trade amount. All 3 transaction would be set up to be paused automatically (primitive 1). The fiat money could be then be transferred. In the happy case, then seller then released the BTC. In case of arbitration the arbitrator has the options to do a cancellation (primitive 2) or a forced through transaction (primitive 3) for each of the 3 transactions separately.
The point I am trying to make here is that we don't need to send the funds to the arbitrator or the DAO. In fact, I think sending money to the DAO may be viewed as taking the money into custody. So the arbitrator, in this model, can only decide which of the trader gets the money, but neither the DAO or any other third-party gets in possession of the funds. In my opinion it may make things easier for the DAO as its not dealing with reimbursements and hopefully also easier for the protocol. Because the DAO is not part of the equation anymore.
Anyway, up to here it's not avalanche resistance, so not fulfilling the security property no. 5.
It would need some more thoughts on fixing security property 5, I have several ideas for that, but they need to be thought through first. But I am putting this out, because I think it makes the protocol simpler by restricting the 3 transactions to go to the buyer or seller only and not have any flow of money to another party.
What do you think?