txdb lock balance accounting fixes. #780
Closed
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
nodech
force-pushed
the
txdb-unlock-balances
branch
from
b26bbd0 to
13e0a19
Compare
pinheadmz
commented
Nov 27, 2022
nodech
force-pushed
the
txdb-unlock-balances
branch
2 times, most recently
from
c1c0741 to
137534e
Compare
nodech
changed the title
pinheadmz
commented
Nov 29, 2022
nodech
force-pushed
the
txdb-unlock-balances
branch
3 times, most recently
from
d19b487 to
77a57f8
Compare
misc: Log name instead of number for covenants.
pinheadmz
commented
Dec 5, 2022
| const GRIND_NAME_LEN = 10; | ||
| const hardFee = 1e4; | ||
|
|
||
| // TODO: Add insert w/ block only tests(no unconfirmed step). | ||
| // TODO: Add claim test. | ||
| // TODO: (Re)Move and merge wallet-test lock balance checks. | ||
| // TODO: Add double spend and double spend/erase of chained txs. | ||
| // - Test when we have spent tracking(layout.s) but not spendCoin(layoud.d) |
pinheadmz
force-pushed
the
txdb-unlock-balances
branch
from
86c5627 to
e74ac10
Compare
|
@nodech rebased on master and discovered another failed test from #781 I don't know if this issue is recoverable. I'm using these extra log statements to monitor the un/lock balance activity: https://gist.github.com/pinheadmz/9af90d54e7ac934a7aa331ccd6501f28 |
pinheadmz
commented
Dec 5, 2022
Comment on lines
+27
to
+30
| /** | ||
| * @typedef {import('./walletdb')} WalletDB | ||
| */ | ||
|
|
There was a problem hiding this comment.
CI didn't like this.
ERROR: Unable to parse a tag's type expression for source file /home/runner/work/hsd/hsd/lib/wallet/txdb.js in line 27 with tag title "typedef" and text "{import('./walletdb')} WalletDB": Invalid type expression "import('./walletdb')": Expected "!", "=", "?", "[]", "|", or end of input but "(" found.
Error: Process completed with exit code 1.
pinheadmz
commented
Dec 6, 2022
Comment on lines
+1354
to
+1357
| if (!credit) { | ||
| credit = Credit.fromTX(tx, i, height); | ||
| await this.removeCredit(b, credit, path); | ||
| continue; |
There was a problem hiding this comment.
The continue here makes sense, but we already know there is no Credit, so I don't understand the purpose of removeCredit() ? All tests pass without it
Merged
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.
The assertions were only there in the first place because of weird covenant accounting: for some covenants like REVEAL, we dig up the corresponding BID from the database and we MUST HAVE THAT DATA or we can't compute the change to the wallet's locked balance.
The new approach is: we process all inputs and all outputs of every TX, meaning that the BID in the input of the transaction is applied to our balance mere moments before we process the REVEAL in the output of the same transaction. This simplifies balance locking really well (we eliminate DB lookups and the functions are no longer
async/await).The assertion errors we've been getting almost daily from users occurs when the BID is not in the database yet because we don't recognize our own address because it's a wallet recovery and we haven't generated the address yet.
What this PR does is "not care": if we see a REVEAL before we see the BID, then we have a negative locked balance. Yep that really sucks but it can be fixed with a rescan or two... and no one's node has to crash.
There is one other drawback to this, which is why I'm pausing here and opening as draft:
TODO:
class Balancein txdb needs to allow negative values. Removeassert >= 0and switch allwriteU64towriteI64which interestingly, because it's javascript, I think means we don't need a migration ... ?!