pm: recipient redeems old valid winning tickets on start up

[yondonfu]

Is your feature request related to a problem? Please describe.

If O crashes prior to a redeeming a winning ticket on-chain, it will lose out on the pay out from the ticket unless O has a way to persist the ticket data such that it can try to redeem the ticket at a later point in time.

Describe the solution you'd like

Once #621 is implemented, O will always store winning ticket data in its DB at least until the ticket is successfully redeemed on-chain.

On start up, O can do the following:

• Query its DB for all winning tickets [1]
• For each winning ticket check that it is still valid (given expiration requirements) and that it has not already been redeemed on-chain. We perform the last check because it might have been the case that O submitted a tx, crashed and then the tx confirmed.
• Redeem each valid winning ticket on-chain

[1] After observing a successful on-chain tx we can either clear the winning ticket from the DB or mark the winning ticket as redeemed by storing the confirmation block number in the relevant row of the winning tickets table. If we do the former, we can just query for all rows in the table here. If we do the latter, we can query for rows that do not have a confirmation block number.

Describe alternatives you've considered

O does not necessarily need to redeem the old valid winning tickets on start up, but it is unclear if there is a better time to do so at least in the MVS setting where we are not yet implementing any smarter strategy ticket redemption timing (i.e. O could only redeem tickets when the average gas price is at some level and if that level is not met by X blocks prior to the ticket's expiration O will redeem the ticket on-chain). Since we are leaving alternative ticket redemption strategies for the future, redeeming old valid winning tickets on start up seems like the simplest solution for now.

[j0sh]

Keeping a historical list of winning tickets seems useful; I like using the confirmation block number to indicate rows that have completed processing.

Just curious: are we implementing ticket DB persistence for MVS? I was under the impression that would come in during SS or later. Cool if that can get in sooner though.

[yondonfu]

Keeping a historical list of winning tickets seems useful; I like using the confirmation block number to indicate rows that have completed processing.

Agreed.

Just curious: are we implementing ticket DB persistence for MVS?

The thought was that it would be nice to add it sooner rather than later especially once we start testing with more realistic blockchain conditions (i.e. dealing with on-chain transactions that do not confirm within pre-defined period of time). Although adding persistence is lower on the MVS priority list with the higher priority items being getting the happy ticket flow working (i.e. very quick on-chain transaction confirmation)

[eladmallel]

Update: we think it makes the most sense to exclude winning ticket disk persistence as well as this specific issue from MVS, and move it to SS instead.

Any objections?

cc @ericxtang @dob

Update on update: We're going for winning ticket persistence because we actually want to redeem tickets only upon end of stream, so that we can avoid the complexities that come with changing recipientRand mid-stream.

[dob]

Will the validation logic in the smart contract allow you to cash multiple different winning tickets with the same recipient rand?

[dob]

Also related, what constitutes the "end of the stream?" Again, I'm imaging a world of segment independence, where you don't know if the stream ended since B may switch to another O at any point if you weren't fast enough with the response, and then switch back to you at any point in the future. If we're punting these ideas beyond MVS into SS though, that's ok.

[j0sh]

what constitutes the "end of the stream?"

As a first approximation, it could be the expiration of the transcode loop that the orchestrator maintains. We still want to preserve this stateful transcode loop for a variety of reasons: load control, backpressure and related prioritization/QoS issues, transcode result caching, etc.

For the v1 protocol, the loop times out 10 minutes after the last segment (as not to submit too many claims), but we probably should make this shorter for Streamflow, perhaps even as short as 1 minute.

The overall flow would look something like this:

1. B requests, receives fresh recipientRand from O1 prior to start of stream
2. O1 starts transcode loop as the first segment comes in for the stream
3. B switches to O2
4. O1's transcode loop times out
5. O1 submits any winning ticket(s) for recipientRand.
6. If there are no winning tickets, O stores (recipientRand, senderNonce) in memory
7. B switches back to O by requesting a fresh recipientRand (happy flow)
8. If B tries to reuse recipientRand or the sender nonce, O should detect this via either the win check, or the nonce check and immediately reject the segment. We could simplify this pair of checks by disallowing recipientRand reuse entirely after the transcode loop expires, which essentially forces B to take the happy path without O storing the senderNonce and special casing reuses.

[yondonfu]

Re-opening because while O currently persists winning tickets it will not automatically redeem them at start up unless it has a ticket queue for the ticket's sender and a ticket queue is only constructed (backed by the DB) if the O has received a ticket from the sender recently.

[kyriediculous]

We could add a function on startup that tries to redeem all non-expired , non-used tickets (omit the sender from the queries)