[dlc-dev] Oracle Event Timestamps

Nadav Kohen nadavk25 at gmail.com
Thu Feb 25 02:03:12 CET 2021 

I think my idea was to have a type difference on the time field for events
which happen at a given time and events that could happen at any time over
a given interval. It seemed cleaner to type it as opposed to, say, setting
them equal or making one optional in the case that it happens at a specific
time but I guess setting them equal wouldn't be that bad. Open to people's
opinions on this.

Nadav

On Wed, Feb 24, 2021 at 6:29 PM Lloyd Fournier <lloyd.fourn at gmail.com>
wrote:

> I agree it's best not to add speculative fields. I still don't really get
> why you describe it like "a single timestamp or an interval" instead of
> just two separate fields where one of them is optional. To me you are
> basically suggesting always having `latest_expected` and having
> `earliest_expected` as optional. Or are you saying that the single
> timestamp is not the same as "latest_expected"?
>
> LL
>
> On Tue, 23 Feb 2021 at 19:03, Nadav Kohen <nadavk25 at gmail.com> wrote:
>
>> 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.
>>
>> Best,
>> Nadav
>>
>> On Sun, Feb 21, 2021 at 7:34 PM Lloyd Fournier <lloyd.fourn at gmail.com>
>> wrote:
>>
>>>
>>>
>>> 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/20210224/bf8340fe/attachment.htm>

More information about the dlc-dev mailing list