udb: Track ticket commitments for balance purposes #1330
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matheusd
force-pushed
the
track-sstx-commitments
branch
from
802e84f
to
5c01194
Compare
jrick
reviewed
Nov 28, 2018
matheusd
force-pushed
the
track-sstx-commitments
branch
from
5c01194
to
97d3999
Compare
matheusd
force-pushed
the
track-sstx-commitments
branch
from
97d3999
to
8646ce0
Compare
|
Updated to use two buckets to reduce churning during rescans: one to track commitments and one as index of unspent commitments. |
jrick
reviewed
Jun 11, 2019
jrick
reviewed
Jun 11, 2019
jrick
reviewed
Jun 11, 2019
jrick
reviewed
Jun 11, 2019
jrick
reviewed
Jun 11, 2019
jrick
reviewed
Jun 11, 2019
matheusd
force-pushed
the
track-sstx-commitments
branch
from
8646ce0
to
a612e8a
Compare
|
Gofmt all files and fixed the commenting nits. I'll squash, rebase and (if needed) regenerate the v11 test database once this is considered ready for merging. |
jrick
approved these changes
Jun 13, 2019
This adds the testdata routines needed to generate a udb v11 database for use with the v12 upgrade tests. This is supposed to be run on the commit immediately before the v12 upgrade is introduced.
matheusd
force-pushed
the
track-sstx-commitments
branch
from
a612e8a
to
9e3755b
Compare
This commit changes the handling of ticket commitments so that the wallet can correctly account for its share in tickets instead of always considering it has access to the full funds. It aims to fix balance issues by decoding the commitment addresses in tickets processed by the wallet and individually tracking those only if the address belong to the wallet. This introduces database changes and therefore upgrades the wallet udb to version 12.
matheusd
force-pushed
the
track-sstx-commitments
branch
from
9e3755b
to
5a7d096
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This will perform a database migration into v12. Therefore, if you want to go back to old versions, be sure to backup the wallet dirs.
Close #883
This adds a ticket commitment bucket to the database to separately track wallet-owned commitments, such that the locked balance can be correctly calculated in situations where the wallet does not have voting authority over the ticket. This addresses:
This is a big change in how balances for tickets are tracked in wallets, so while I tried testing all relevant cases (reorgs, dropping out of tickets due to changing sdiff, etc) I expect some iteration and careful review will be needed.
At least the first commit (the v11 testdata generator) needs to be separately merged due to having to be run before the upgrade is merged, so let me know whether I should create a separate PR only for that commit or if you'll merge this without squashing.
Outstanding issues for discussion:
minConfparameter for ticket commitments when calculating the balance?- I'm not 100% sold on using a single bucket for tracking the commitments (due to this causing churning on the database during a rescan). Maybe I should use the same strategy as the credits/unspent tracking and use one bucket for always storing the commitment and a second one for storing the unredeemed commitments)?(Modified to use two buckets, one for storing the commitment info, one as index of unspent commitments)