Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pm: Store winning tickets on-disk with corresponding recipientRand value #621

Closed
yondonfu opened this issue Dec 11, 2018 · 0 comments · Fixed by #655
Closed

pm: Store winning tickets on-disk with corresponding recipientRand value #621

yondonfu opened this issue Dec 11, 2018 · 0 comments · Fixed by #655
Assignees

Comments

@yondonfu
Copy link
Member

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

While in MVS, O will submit an on-chain transaction to redeem a winning ticket immediately after receiving the ticket, it is possible that O will require the ticket data even after submitting the transaction

  • The original transaction might not have been successfully broadcasted due to issues with O's Ethereum connection
  • O might crash prior to the original transaction being successfully broadcasted

Beyond MVS, O might not submit an on-chain transaction to redeem a winning ticket immediately after receiving a ticket and instead choose to hold on to winning tickets to be redeemed later on.

Thus, O would benefit from being able to store winning tickets on-disk.

Describe the solution you'd like

O has a winningTickets DB table. Each table row contains all the data necessary to redeem a winning ticket on-chain: the fields of a ticket, B's signature and recipientRand (which should correspond to ticket.recipientRandHash).

When O receives a winning ticket, it stores the winning ticket data in its DB. After a winning ticket redemption transaction confirms on-chain, O can clear the relevant entry for the winning ticket in the DB.

Describe alternatives you've considered

  • For MVS, we could skip DB persistence since O will always redeem winning tickets immediately, but this would leave O vulnerable to loss of funds in cases where the transaction does not confirm on-chain for some reason
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants