[dlc-dev] Oracle Event Timestamps

Chris Stewart chris at suredbits.com
Tue Feb 16 14:13:10 CET 2021

>Oracle attesting to whether some event occurs at all, with no built-in
oracle expiration.

This seems like a liability for me from the oracle perspective. If an event
is not bounded with a maturation time, the oracle has to provide support
for the event indefinitely (possibly forever!).

There are two concerns here in my opinion

1. Security (are oracle private keys secure indefinitely?)
2. Liveliness of the oracle (an oracle just disappearing, life happens!)

In (2) let's slightly adjust your example above to have a liquidation price
of $10,000 -> $1,000. BTC/USD hasn't breached the $1,000 threshold since
~2017 (4 years ago). For our theoretical exercise, let's assume the oracle
published an announcement committing to signing the message "BTC beneath
$1,000" and did _not_ include a maturation time.

If you and I wanted to construct a contract today based on this 2017
oracle, how do we know that the oracle will still publish that price if the
event occurs? In my opinion the heuristic of maturation time is a useful
piece of information for contract participants to use when picking an
oracle. A start_time would be another useful one.

With our theoretical DLC, now we can see that the oracle committed to
publishing signatures for this event -- if it occurs -- until maturation
time. We can also use this information to prove bad behavior from the
oracle if they do _not_ publish the signature "BTC beneath $1,000" if the
market price is below $1,000. We also can design our contract around this
maturation time (OR pick a new oracle with a suitable maturation time, OR
ask the existing oracle to publish a new announcement with a new maturation
time (if they are lively, they might accommodate!))

It seems including a maturation time encourages "good hygiene" for oracles
in that

1. Allow the ability to rotate keys (my events now have a pre-determined
maturation time, so i don't have to secure them forever!)
2. Up front commitment to a fixed interval of time they will be monitoring
the event.

In general, I think we need to remember we are designing this system around
oracles and therefore need to get them to be as rigorous as possible when
outlining the conditions of signing a specific attestation. If we force
oracles to be rigorous, users of that oracle have better understanding of
when/why an oracle publishes a certain attestation. Since we live in the
real world, all events are bounded by time intervals in my opinion.

I think it could be interesting to include a "start_time" field so we have
a well defined interval of time the oracle is monitoring for. In our
example above, two DLC users can see that the oracle originally published
the oracle announcement in 2017, which gives us a useful heuristic when
thinking about the liveliness of the oracle.


On Mon, Feb 15, 2021 at 3:59 PM Nadav Kohen via dlc-dev <
dlc-dev at mailmanlists.org> wrote:

> 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
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210216/6ca36433/attachment.htm>

More information about the dlc-dev mailing list