[dlc-dev] Oracle Event Timestamps

[Nadav Kohen]

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/66ff864f/attachment.htm>