feat: use available balance of PR to determine when to lock funds

[martinserts]

Description

We now will rely on available field in balance response instead of credits - debits.

FIxes: #14 14

Motivation and Context

PP already queries PR current balance to understand if there is enough funds to lock.
But credits - debits did included locked and unconfirmed UTXOs.
Thus it often happened, that it shows, that the balance is available, when in really it was not.

Breaking Changes

• None
• Requires data directory on base node to be deleted
• Requires hard fork
• Other - Please specify

[gemini-code-assist]

Summary of Changes

Hello @martinserts, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the fund locking mechanism within the payment processor by switching from a potentially misleading credits - debits balance calculation to a more accurate available balance field. This change addresses a critical issue where the previous calculation could incorrectly indicate sufficient funds by including locked or unconfirmed transactions, leading to failed fund locking attempts. By directly using the available balance, the system now ensures that only genuinely spendable funds are considered, thereby improving the reliability and precision of transaction processing and fund management.

Highlights

• Balance Calculation Logic Update: The method for determining available funds has been updated to use a dedicated available field, replacing the previous credits - debits calculation which could include locked or unconfirmed UTXOs.
• AccountBalance Struct Enhancement: The AccountBalance struct now includes new fields: available, locked, total, and unconfirmed, along with updated documentation for all fields to provide a more granular view of account funds.
• Improved Fund Locking Accuracy: This change ensures that only truly spendable funds are considered when locking funds for transactions, preventing issues caused by inaccurately including locked or unconfirmed UTXOs in the balance calculation.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the logic for checking account balances before locking funds. It now correctly uses the available balance provided by the API, instead of calculating a balance from total credits and debits, which could be inaccurate as it included locked and unconfirmed funds. This is a good correctness improvement. The changes are mostly in the AccountBalance model and its usage in unsigned_tx_creator.rs. I have one point of feedback regarding a breaking API change in the AccountBalance model that should be addressed.