[dlc-dev] Oracle Event Timestamps

[Antoine Riard]

> This is a very unsatisfying long-term UX and so I think
`earliest_expected` serves the purpose you discuss here of when to come
online and occasionally ping the server until `latest_expected` at which
point you probably do some kind of back-off at some point.

If your DLC does have an emergency path or a "can-happen-at-anytime" unary
outcome, your liveliness requirement is going to be pretty hard. So
`earliest_expected` purpose is only an UX improvement, I don't deny it's
not worthy, just wanted to be pretty clear on its benefits. In fact,
outcome attestation probability might be a gaussian, thus
`most_likely_expected` would be better, you're less interested with lower
quartile ?

> That said you do mention that having an `earliest_expected` can help in
setting the `funding_security_point` so I'm not really sure what your
objection is anyway?

I was referring to Chris's `start_time`, which is useful for setting your
fee-bumping policy. Reading again your latest proposal, I did interpret
`earliest_expected` as most-likely with your game example in mind. IMO
`start_time` should be different from `earliest_expected`. I think it makes
sense to have 3 timestamps values, `earliest_expected`, `average_expected`
and `lastest_expected` ? Bounds do have a security semantic, median value
only a UX one ?

Le lun. 1 mars 2021 à 14:41, Nadav Kohen <nadavk25 at gmail.com> a écrit :

> Hey Antoine,
>
> I agree that in theory it should be fine to just use `latest_expected` as
> the time the client should come online to act, and in practice this is
> always an option, but I believe this to be a pretty bad UX. You're sitting
> there watching the game and you see the event happen (say your team wins
> the game), you go to your DLC-betting app and you look at your bet on this
> game and nothing has happened. Nothing will happen until the latest time
> the game could have ended and only then are the wheels put in motion. This
> is a very unsatisfying long-term UX and so I think `earliest_expected`
> serves the purpose you discuss here of when to come online and occasionally
> ping the server until `latest_expected` at which point you probably do some
> kind of back-off at some point.
>
> I agree that `earliest_expected` is not generally required for security in
> the presence of `latest_expected`, but it does result in a better possible
> UX. That said you do mention that having an `earliest_expected` can help in
> setting the `funding_security_point` so I'm not really sure what you're
> objection is anyway?
>
> Lastly I'd like to note that in earlier discussion on this thread
> regarding unary event end times, it was decided that the default should be
> to have end-times not because of users (who always set their own end times
> with refund txs) but for the oracles themselves who will not want to be
> responsible for securing the keys forever. If, on the other hand, oracles
> due wish to have unbounded events, they can always use max_value as their
> latest timestamp.
>
> Best,
> Nadav
>
> On Sun, Feb 28, 2021 at 12:35 PM Antoine Riard via dlc-dev <
> dlc-dev at mailmanlists.org> wrote:
>
>> Hi list,
>>
>> Catching up on this proposal, I don't know if
>> `earliest_expected`/`lastest_expected` map well to the temporal bounds of
>> any kind of event structure. To get back to the NBA game, if we analyze in
>> depth, the average outcome will be the attestation of the score between the
>> 2 teams. But unary outcomes might be also announced-and-attested by the
>> oracle, like key player sickness, bad weather, game report, eviction of the
>> team at a previous round of the tournament, whatever. An event structure
>> might be really complex and envisioning how DLC participants can adapt
>> their behavior in function of bounds expressions isn't straightforward.
>>
>> The first behavior potentially affected could be client-side liveliness,
>> i.e when a client is expected to be online to discover an outcome
>> attestation. Committing to a `latest_expected` would serve the same
>> function than the actual `event_maturation_time`, indicating to the client
>> when come back and act, before the counterparty plays the refund.
>>
>> But I'm not sure if committing to an `earliest` makes sense. If your
>> event has a hardship/unary outcome or an emergency option (see #94), your
>> client should always be online to react in consequence. I guess `earliest`
>> is only worthy for such simple DLC involving mobile clients. In practice
>> such clients would likely be backed up by watchtowers, which might do the
>> broadcast job as well.
>>
>> Another behavior potentially affected could be oracle-side liveliness.
>> Such temporal bounds would be a soft commitment by the oracle to attest
>> during those bounds. I think you might even make this enforceable if the
>> range must be at least a block-wide. Make the oracle commit a hash of the
>> announcement in the chain (OTS-style ?), proving it delivered attestation
>> as expected.
>>
>> Violation of oracle liveliness might be also reacted by counterparties.
>> After `lastest_expected` is reached, an automatic fallback could be to
>> interact with your counterparties to sign an early DLC termination, that
>> way saving funds timevalue between `lastest` and refund validity.
>>
>> At least, I think we should include `start_time`, to serve as an easy
>> reference point for `funding_security_point` (i.e when you client should
>> aggressively fee-bump the funding_tx) or signaling to your watchtower when
>> it should start to process block (see BOLT13 proposal).
>>
>> It should be also mentioned that if your oracle doesn't commit to an
>> upper bound due to signing an unary event, it's the responsibility of
>> clients to decide a refund happening at some T. An event without time-bound
>> might be a bearable risk for some DLC participants, not for others.
>>
>> Cheers,
>> Antoine
>>
>> 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/20210301/4c8c6ad3/attachment.htm>