[dlc-dev] Oracle Event Timestamps
Antoine Riard
antoine.riard at gmail.com
Sun Feb 28 19:33:08 CET 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210228/e3eb006c/attachment.htm>
More information about the dlc-dev
mailing list