[dlc-dev] Oracle Event Timestamps
Chris Stewart
chris at suredbits.com
Wed Apr 7 01:58:26 CEST 2021
Ok, so I am having a hard time understanding if clients should or should
not use earliest_expected & latest_expected to derive odds for a bet
Here is what i see these fields being useful on the client side
1. Querying the actual oracle itself for outcomes
2. Constructing refund transactions for the DLC
3. Understanding when an oracle is no longer monitoring if an event occurs
(example: bitcoin price < $100)
If this is accurate, I think I am ok with this proposal as it does give
useful bounds for the client side when picking oracles. If I am building a
DLC that is predicated on extreme price movements (BTC < $100), I can
examine the oracles "latest_expected" fields to see how much longer the
oracle will be monitoring the event. This gives us a bounded time range
that an event can occur, which gives us the ability to calculate
probabilities within a well defined time interval specified by the oracle
itself rather than the clients.
I think we have to encourage users to construct refunds against
latest_expected to make sure this is true? If not, an oracle can publish a
signature after "latest_expected" which would throw off your modeling for
probabilities of an event occuring. Clients can of course choose to make
their refunds occur _before_ the "latest_expected" field on the oracle
announcement, but that is their local choice not a choice by the oracle.
One concern that isn't really covered by this if i understand correctly is
how long an announcement has existed. Maybe application tooling can provide
this like our oracle explorer. But strictly speaking from the protocol,
this doesn't give us the ability to tell if an oracle has been monitoring
for 1 year or 5 years.
Perhaps you can make the argument you should set `earliest_expected` to the
timestamp of the announcement creation in this case when making an oracle
announcement for extreme events (BTC < $100). That seems ok to me.
I would recommend we add a WARNING section (or maybe put it in the
rationale) so that people don't confuse what the timestamps are used for.
-Chris
On Wed, Mar 3, 2021 at 12:36 AM Nadav Kohen <nadavk25 at gmail.com> wrote:
> Hey Chris,
>
> I mentioned this at the meeting but I personally view the second kind of
> "maturation time" as a semantic concern (as opposed to a programmatic one)
> similar to "I am signing the BTC/USD ticker" vs. "I am signing the BTC/EUR
> ticker" and that timestamp should live in the same field as that
> information (currently the event_id). Furthermore, just as a note, in those
> scenarios the expected time will be the maturation time.
>
> Best,
> Nadav
>
> On Tue, Mar 2, 2021 at 6:47 PM Chris Stewart <chris at suredbits.com> wrote:
>
>> So catching up on this thread
>>
>> >I am suggesting that "event_maturation_time" should mean "expected_time"
>> and I think I'm okay with renaming it so this is good feedback.
>>
>> > In response to your example however, I disagree with the usage of the
>> timestamps presented, I think that all timestamps are expectations rather
>> than pure bounds
>>
>> I think I have a fundamental disagreement on this with certain types of
>> events. There are most definitely pure events. The simplest example is
>> market data.
>>
>> If I say I'm going to attest to the latest market price on BitMEX @
>> 2021-03-01T:00:00:00 UTC, it should be a pure boundary. Let us assume for
>> the sake of the example the _real_ price on BitMEX is $50,000 at that
>> instant. One second later there is a massive liquidation on BitMEX @
>> 2021-03-01T:00:00:01 UTC that causes the price to cascade down to $40,000.
>> I think we would all agree that the oracle should be attesting to the
>> $50,000 price ? This is a pure boundary in my mind. I would consider if the
>> oracle attested to the $40,000 price they are being dishonest (more likely,
>> incompotent).
>>
>> It seems we have a semantic overload for "event_maturation_time". Here
>> are the two different meanings I see
>>
>> 1. The "expected" time the oracle _reveals_ their attestation
>> 2. The moment the oracle is going to sample data (market data in my
>> example above) to build their attestation.
>>
>> I am referring to (2) when i talk about "event_maturation_time", whereas
>> it seems like everyone else in this thread is talking about (1)?
>>
>> I do concede, as Lloyd points out in his basketball example, that certain
>> types of events do not fall into this grouping, however there is another
>> segment of events (financial prices, in particular) that have well defined
>> times to sample the data set to look at the outcome.
>>
>> I'm not sure how to best accommodate both.
>>
>> On Tue, Feb 23, 2021 at 2:03 AM 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/20210406/64413221/attachment.htm>
More information about the dlc-dev
mailing list