commands: indicate in listcoins response whether coin is from self
#1483
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
Some migration tests used structs and methods that are expected to change and so will not be backward compatible. This change replaces those with structs and methods specific to the migration tests so that the tests will be unaffected by DB schema changes. At the same time, these new structs and methods simplify some of the setup by allowing to store new coins, including their confirmation and spend status, in a single DB operation.
jp1ac4
force-pushed
the
store-coin-is-from-self
branch
from
bbcfb76
to
07b2651
Compare
|
Set PR to draft as I might include changes to the |
jp1ac4
force-pushed
the
store-coin-is-from-self
branch
from
07b2651
to
3118ee4
Compare
|
I added commits to include the I also added a check constraint on the coins table so that a coin cannot be both immature and from self. This would also apply to coinbase deposits in general, but we don't currently flag those. |
jp1ac4
changed the title
listcoins response whether coin is from self
|
Following feedback from @edouardparis, I'll make the following changes:
|
I found that making changes to the transactions used in the test can affect the order in which coins are returned, probably due to the txid changing.
The new columns in the transactions table will be populated for new transactions by the poller, while existing rows will be updated in a subsequent migration. New and existing coins will all have `is_from_self` set to false due to the default column value. None of these columns will be used by the wallet at this stage.
This populates the new columns from the previous migration for existing rows and then maintains them in the poller moving forward.
jp1ac4
force-pushed
the
store-coin-is-from-self
branch
from
3118ee4
to
16726f5
Compare
|
I've now made the changes as outlined above. For extra safety, I added a max number of iterations based on the number of unconfirmed coins when updating |
Comment on lines
+428
to
+436
| let mut i = 0; | ||
| loop { | ||
| i += 1; | ||
| if i > max_iterations { | ||
| panic!( | ||
| "More than {} iterations while updating is_from_self.", | ||
| max_iterations | ||
| ); | ||
| } |
There was a problem hiding this comment.
I think you can directly do for i in 0..max_iterations with the updated == 0 as a break if it is finished early.
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 is a first step towards #1375.
Following the approach from #1391, this PR adds a new
is_from_selffield to the response of thelistcoinscommand.The underlying information is stored in a new
is_from_selfcolumn in the coins database table. This column could instead have been added to the transactions table, but for consistency with other transaction-related columns, I added it to the coins table. It's also important to note that being from self is wallet-dependent, so adding it to the transactions table would not work if multiple wallets were supported in the same DB (h/t @edouardparis).A subsequent PR will then use this field in the GUI to determine which unconfirmed coins, if any, can be included in the confirmed balance. It also needs to be added to the corresponding Liana Connect API call. Another use of this field will be to determine which unconfirmed coins to include in coin selection (#1484).
The first commit in this PR refactors some existing DB migration tests so that they will not be affected by future changes to the coins table schema.