Oracle key revocation and DLC cancellation

[ariard]

From #93

If the private key is compromised (from incompetence -- this is different if the oracle is malicious), all DLCs need to be re-negotiated. Since the odds of winning/losing bets have changed since the initial bet as placed, this will likely not be a easy/fair process. This re-negotiation risk is mitigated if there are unique key pairs on a per event basis.

In case of oracle site compromise, it would be great to have a DLC cancellation mechanism where at reception of a oracle's revocation certificate a signature/secret is joint to bypass the timelock on the refund transaction. Thus broadcasting and confirming before any contract_maturity_bound expiration and preventing the oracle attacker to collude with a DLC counterparty.

I think this is an interesting topic to explore to protect DLC users from oracles failures.

[nkohen]

We could have an "I have been hacked" message?

[benthecarman]

We could have an "I have been hacked" message?

We could have that or alternatively a way to prove to your counter-party that the oracle is likely compromised, ie staked funds have been spent or revealing the private key of the oracle.

Edit: I guess if you have the private key of the oracle you could sign the "I've been hacked" message yourself.

[ariard]

We could have an "I have been hacked" message?

I was thinking about an emergency key part of oracle information, and you build a refund transaction with no-timelock counter-signed with the oracle emergency scalar. The revocation message is just the scalar with maybe a signature to the current blockhash to timestamp it. We just want to keep the same non-observable property but beyond it's more a matter of oracle key management and publication space of the revocation message.

[benthecarman]

I was thinking about an emergency key part of oracle information, and you build a refund transaction with no-timelock counter-signed with the oracle emergency scalar.

I like this idea

[Tibo-lg]

I was thinking about an emergency key part of oracle information

+1 on that, came here to propose something similar :)

[Christewart]

We could have an "I have been hacked" message?

I was thinking about an emergency key part of oracle information, and you build a refund transaction with no-timelock counter-signed with the oracle emergency scalar. The revocation message is just the scalar with maybe a signature to the current blockhash to timestamp it. We just want to keep the same non-observable property but beyond it's more a matter of oracle key management and publication space of the revocation message.

Hmm, does this introduce more perverse incentives for the oracle? If the oracle is simultaneously attesting to an event and participating in the event, and they happen to be on the wrong side of the bet, can they claim they were hacked and execute all of the revocation claims?

I'm not sure how much water this argument holds, but it is something that needs to be thought about.

[benthecarman]

If the oracle is simultaneously attesting to an event and participating in the event, and they happen to be on the wrong side of the bet, can they claim they were hacked and execute all of the revocation claims?

If they were going to do that why not just sign the outcome that gives them the win?

[Tibo-lg]

Hmm, does this introduce more perverse incentives for the oracle? If the oracle is simultaneously attesting to an event and participating in the event, and they happen to be on the wrong side of the bet, can they claim they were hacked and execute all of the revocation claims?

Interesting, hadn't thought of that. I guess at the end of the day you need to trust the oracle in some way anyway. I think that's yet another argument for using multiple oracles.

If they were going to do that why not just sign the outcome that gives them the win?

Good point, but I guess the point is that the oracle could claim to have been hacked instead of outright cheating.

[benthecarman]

Good point, but I guess the point is that the oracle could claim to have been hacked instead of outright cheating.

They could claim they were hacked and the hacker signed the wrong message.

[Christewart]

One thing here is that there should probably be hefty fees on the "I have been hacked" CET as there will be race conditions as the compromised private key can now be used to sign anything.

[ariard]

A quick note, we could also extend this mechanism with a block delta measuring script branch to cancel CETs in case of unexpected hashrate spikes/drop, thus falsifying any contract maturity expectation.

You may define lower/upper bounds playing with nLocktime block time/block height.

Pseudo-Script:

IF 
             <now + 1 month> CHECKLOCKTIMEVERIFY DROP
             <chain_tip + 4032> CHECKLOCKTIMEVERIFY DROP
ELSE
             <now + 1 month> CHECKLOCKTIMEVERIFY DROP
             <chain_tip + 4000> CHECKLOCKTIMEVERIFY DROP
ENDIF

EDIT: I think this for being valid needs to be played off-chain, where participants agree to prune out of a commitment transaction this kind of script if they're are not executed, otherwise, as those conditions will become true at some point they may alter contract equilibrium. Take it as a loosely-defined idea but theoretically functional and call me up at some point to fully expose it.

[LLFourn]

IF 
             <now + 1 month> CHECKLOCKTIMEVERIFY DROP
             <chain_tip + 4032> CHECKLOCKTIMEVERIFY DROP
ELSE
             <now + 1 month> CHECKLOCKTIMEVERIFY DROP
             <chain_tip + 4000> CHECKLOCKTIMEVERIFY DROP
ENDIF
``

https://medium.com/blockstream/dont-mix-your-timelocks-d9939b665094 👀

[ariard]

https://medium.com/blockstream/dont-mix-your-timelocks-d9939b665094 eyes

Good point the either-block-height-or-epoch flag is committed once for all. That said you may use a CSV as one and a CLTV for the other ?

[LLFourn]

Yes it's about mixing timestamp and block height. It's orthogonal to relative or absolute.