[dlc-dev] Oracle Event Timestamps

[Nadav Kohen]

Hi list,

On the current specification, oracle events (
https://github.com/discreetlogcontracts/dlcspecs/blob/master/Oracle.md#oracle-events)
have a timestamp called `event_maturity_epoch` which is described as "the
earliest time (UTC) at which it plans on releasing a signature over the
event outcome, in epoch seconds."

There have been arguments made in the past that, at least in some cases,
these should be used in computing CET nLockTime values so as to enable such
things as the "I am compromised" refund execution (
https://github.com/discreetlogcontracts/dlcspecs/issues/94).

I would like to bring to everyone's attention and open for discussion the
issue that there seem to generally be two kinds of oracles with respect to
event timestamps:

   1. Oracle attesting to what happens at some fixed time T (in the future).
   2. Oracle attesting to whether some event occurs at all, with no
   built-in oracle expiration.

Note that while the second case seems to suggest that using such an oracle
would lead to an unbounded amount of time that funds could be locked, this
is not the case as users of the oracle will be introducing their own
time-locked execution path in either the form of a refund transaction or
else by using a Disjoint Union DLC where at least one of the other oracle
events used is of the first kind.

To make this concrete with an example, imagine having a BTC/USD price
oracle which has an event for the price at time T (in the future), and
another oracle which attests to whether a given price threshold is broken
at any point, say $10,000, at which point this oracle would publish a
signature for the message "BTC beneath $10,000" with no other possible
messages that could be signed (a unary outcome DLC oracle event). With
these oracles, a DLC could be opened where if the second oracle broadcasts
its signature, then one party (the party going short) would lose all funds
in a liquidation execution, or else if the price threshold $10,000 is not
breached before time T then the DLC executes using the first oracle's price
signature (using digit decomposition as usual).

In this example, the CET based on the second oracle should be constructed
using an nLockTime less than or equal to the current block height/time,
while the first oracle's CETs can use any nLockTime less than or equal to
T, the oracle event's maturation. However, given the structure of the
current oracle_event message, it is not clear to DLC software how to
interpret timestamps on oracle events of the second kind (events not linked
to a specific time).

A decision, and possibly a change, needs to be made to the specification to
clear up this matter. The following are the options I could think of (there
may be others):

   1. Leave the field as is and simply ask oracles of the second kind to
   either use 0 or else the time at which the event was created.
   2. Add a new (boolean?) field which flags which kind of oracle event
   this is which will allow client software to interpret the timestamps
   correctly.
   3. Add a second timestamp for event creation and have oracles of the
   second kind use 0 for event maturity to signal what kind of oracle they are.

Furthermore, the specification should perhaps be more opinionated around
the use of these timestamps and provide recommendations as to how the
values found in the oracle_event should affect the values used as timeouts
in the dlc_offer message, as this is currently unclear in the specification.

Looking forward to seeing people's thoughts!

Best,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210215/04be2edc/attachment.htm>