[dlc-dev] Oracle Event Timestamps

Nadav Kohen nadavk25 at gmail.com
Tue Feb 23 09:03:45 CET 2021

Hi Lloyd,

Yes this is exactly what I was thinking! Thanks for translating :) I am
personally a proponent for now of using either "expected" or in some cases
the pair "earliest_expected" and "latest_expected" because the oracle
doesn't really have control over the real world or their user's preferences
so I don't think they have anything to offer us other than expectations.

I kind of understand what you are referring to wrt having an actual latest
time but I don't think I'm seeing any practical use for such a piece of
information from either the user's or the oracle's perspective (happy to be
wrong on this and convinced otherwise). I think that any considerations
such as the one you mentioned where "delays beyond T will result in event
'cancellation' and the opening of a new event" belong in the more general
contract meta-data, in a string field which spells out the
precise semantics of the event similar to the "The Rules" field on every
market on https://www.predictit.org/ . I personally find it a little dirty
to try to have such fields in a separate dedicated field because in my mind
this falls under the purview of oracle event semantics in a way that isn't
as general as "expected_time."

I am open to counter-arguments or else if you (and others) agree with the
proposal to use expected times (in either a single timestamp or an interval
[earliest_expected, latest_expected]) then I will open a PR altering oracle
events to accommodate this.


On Sun, Feb 21, 2021 at 7:34 PM Lloyd Fournier <lloyd.fourn at gmail.com>

> On Sat, 20 Feb 2021 at 06:52, Nadav Kohen <nadavk25 at gmail.com> wrote:
>> Essentially having an "earliest" and "latest" in place of an "expected"
>> time just means that this defines an "expected time interval" in place of
>> just one time, perhaps we should rename to accommodate this. I think that
>> in your example if the game is moved back then there is a scenario where no
>> new event is needed, depending on the wording in the announcement. In fact,
>> it could be really unfair to DLC participants who will not have internet
>> access during this very short time window where they must close their
>> existing DLC and open a new one so I think that this would generally be bad
>> practice.
> Ah ok, then we are talking about different things altogether -- you are
> talking about putting a more high resolution picture on "expected_time" by
> having a range instead. I am talking about having the oracle explicitly
> communicate a tolerance for when a event loses its identity due to delay.
> For example, If Kobe is stuck in a lift and so the game is delayed by an
> hour then it's still the same event.
> If Kobe is dead due to airplane crash and the game is delayed several
> months (as actually happened) then the event is cancelled and a new event
> is created. This makes sense from a betting perspective (losing a key
> player and the passage of time changes the odds).
> Perhaps this isn't actually useful in practice so it's fine to leave this
> out but I hope that makes what I am saying clear.
> It might help to call "eariest", "earliest_expected" and "latest",
> "latest_expected" so the same confusion I had doesn't occur for others.
> LL
>> Best,
>> Nadav
>> On Wed, Feb 17, 2021 at 6:24 PM Lloyd Fournier <lloyd.fourn at gmail.com>
>> wrote:
>>> 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
>>> orthogonal.
>>>  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/20210223/092a0df3/attachment.htm>

More information about the dlc-dev mailing list