Use RSK smart contract as 3rd party for the delayed payout tx (Burningman problem)

[chimp1984]

This is just a very rough idea and I am not sure if its feasible and don't know enough about RSK but maybe someone with more knowledge can comment.

The funds from the delayed payout tx will go the peg-in address of RSK. From there it is converted to RBTC and sent to a smart contract RBTCaddress.
Here we have full smart contract capability like in Ethereum.

How to get the funds out?

1. Peg-out:
   For burning the RBTC as BSQ we can go back with a pegout to send it as input to a BSQ/BTC atomic swap. Not sure if that is possible as they might support only sending to a PKH script. Also the MS tx would be invalid if the BSQ input would have been spent before it gets confirmed, so that might be a problematic appraoch.

2. Atomic cross chain swap:
   Another approach might be to make an atomic cross chain swap RBTC to BSQ. But the BSQ model does not support multisig, so that will also not work ;-(. Beside that there would be the issue with lack of liquidity in such a makret.

3. Smart contract + oracle + DAO -> send to receiver as RBTC.
   Another approach is to leave the BTC as RBTC in the smart contract and use that to make the payout to the winning party in arbitration. So no converting and burning of BSQ and reimbursement but using teh RSK smart contract as notary (3rd party). I think that might be a superior model as a blockchain as 3rd party cannot be subject to regulation and is the model of all DeFi projects on Ethereum.

How to form that smart contract to avoid potential abuse from a malicious arbitrator is then the problem to solve. Pure multisig is not great for that but I think we could use the DAO as oracle which generates blockchain data by voting which serves as input to unlock the payout. So it can be 2of3 Multisig contract + the condition that DAO has voted ok for doing the payout.

I think RSK has some BTC bridges for oracle use case, but I am not familiar with it.
If so that RSK to BTC bridge can trigger an event once a certain event on the BTC blockchain happens.

By using RSK we would delegate some trust the the pegging model of RSK (which seems to be more decentralized and safe than Liquid).
If the BTC bridge is needed then there will another element of trust but that might be acceptable. Ultimately the DAO would have the key for enabling a payout and therefor is the root trust element.

Discreet log contracts might be a useful model here as well. So the oracle will not know anything about the action it triggers on clients. There could be multiple oracles which all just publish the DAO voting data which will be verified by the smart contract (if possible). Then the only problem a malicious oracle could cause is to omit the data publishing, but as there are multiple that would not do any harm.

For sure much details to figure out and that naive approach will likely has some problems und open challenges...

Maybe the same model is possible using Liquid. The smart contract capabilities are lower there but with covenants there might be a way to secure the payout tx so that a malicious Burningman or arbitrator cannot steal the funds.

[chimp1984]

After more thought I think it will not solve any problem as the oracle would become the weak point. Also more powerful smart contract do not help in our context as we have external information (arbitrator decides who should get the funds, can be backed by DAO voting) and the smart contract is not aware of that information. So an Oracle to translate that is needed but turning it into the problematic trusted element.