[dlc-dev] Oracle Event Timestamps

Lloyd Fournier lloyd.fourn at gmail.com
Thu Feb 18 01:23:34 CET 2021

Hi Nadav,

Keep in mind that I am not using TLV serialization for my oracle so what I
say below is only a suggestion.

On Wed, 17 Feb 2021 at 19:40, Nadav Kohen <nadavk25 at gmail.com> wrote:

> Hi Lloyd and Chris,
> After having long discussions with both Matt and Thibaut I think we should
> replace the `u32` timestamp in the `oracle_event` with an `event_time` TLV
> type which has two instances, `event_maturation_time` which has a single
> `u32` timestamp and `event_time_interval` which has an `earliest` and a
> `latest` (both u32).

Why not just stick to "earliest_time" and "latest_time" --
"event_maturation_time" means the same thing as "earliest_time" right? Or
are you suggesting changing it's meaning to expected time? But then it
would make sense to rename it to be "expected_time".

I generally agreed with Lloyd's characterization above but I don't think
> that it makes sense to have all three but rather an event has an expected
> time which should be used or else it has a time interval which should be
> used. Oracles should not be speculating on refund times as this is a
> client-side decision so I don't think it makes sense to have a "Latest" in
> an event with an "Expected" maturity time

Let me give an example which shows why "latest" and "expected" are
orthogonal. Consider a basketball game. The oracle sets the expected_time
to be the expected end of the game while it sets latest_time to be midnight
that night.
Here the oracle is saying that if the game is not decided by midnight then
I will never call the outcome (or preferably attest to a backout outcome).
If the game is rescheduled by a day then the oracle must create a new event
for the rescheduled event.
Here expected is used by the app to notify the user when is a good time to
check on the app. An hour before it might notify the user "your bet on X
will be resolved soon!".
Hopefully this shows why these two things are independently useful and

 Furthermore we have done quite a bit of work to avoid options in our
> messages as the notion of an option is not part of TLV serialization and
> would lead to extra work for all implementations and special complications
> for those using TLV libraries (this is a rather technical concern as we
> could always have 8 types in place of 3 options but this is just further
> motivation for my solution).

It is not by accident that all successful serialization formats have an
optional field as a core notion. It is an extremely useful idea. Having
done a lot of work so far to avoid it is just more evidence of why you
should have it IMO!

> Under this proposal, I believe all of Chris' and my worries are taken care
> of as this allows oracles to specify a `latest` but this `latest` can also
> be set to `u32.max_value` to functionally have an open-ended event.

> My only question after which I plan to PR this proposal into the spec is
> whether Lloyd has any objections? This is strictly less expressive than
> what he proposed but I think it captures pretty much everything we need
> (noting that oracles can use the string field they already have for softer
> meta-data for soft time "commitments"/recommendations).

> Best,
> Nadav
> On Tue, Feb 16, 2021 at 11:42 PM Lloyd Fournier <lloyd.fourn at gmail.com>
> wrote:
>> Hi Nadav and Chris,
>> There are three possible times you could want to know as a client that I
>> can see.
>> - Earliest -- the client should start checking for outcome after this has
>> passed
>> - Expected -- useful to display to the user when the event is expected to
>> transpire (so they can check back with the app).
>> - Latest -- Good to make refund arrangements
>> My preference would be for allowing oracle to announce all three, none or
>> any combination of these (e.g. add optional fields earliest_time,
>> expected_time, latest_time).
>> I don't agree with the motivation that Chris sees for forcing any of them
>> to be present. Clients that are doing something like a refund transaction
>> can just refuse to do bets on announcements that don't have the requisite
>> data. It is premature to be opinionated about this stuff IMO.
>> Cheers,
>> LL
>> On Wed, 17 Feb 2021 at 00:14, Chris Stewart <chris at suredbits.com> wrote:
>>> >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.
>>> -Chris
>>> 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
>>> 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/20210218/6156fbec/attachment.htm>

More information about the dlc-dev mailing list