-
Notifications
You must be signed in to change notification settings - Fork 1.5k
fixTrustLinesToSelf
: Introduce amendment to handle trustlines to self
#4105
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
Conversation
@cryptobrad can you please rebase your PR to 1.9 it is giving us merge conflicts while adding this to the next beta. Thanks 🙏 |
Trustlines must be between two different accounts but two trustlines exist where an account extends trust to itself. They were created in the early days, likely because of bugs that have been fixed. The new fixTrustLinesToSelf amendment will remove those trustlines when it activates.
I have finished the rebase. Will this be merged? |
removeTrustLineToSelf( | ||
sb, | ||
uint256{ | ||
"326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A"sv})) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the first call to removeTrustLineToSelf
fails, the second call to removeTrustLineToSelf
will not be executed. This is due to short-circuit evaluation.
I am not sure if this is intended but just want to point it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did on purpose so if deletion fails amendment activation fails and does a roll back, but deletion would not fail.
// two on 19-02-2022. This code was here to allow those trust lines to be | ||
// deleted. The fixTrustLinesToSelf fix amendment will remove them when it | ||
// enables so this code will no longer be needed. | ||
if (!view().rules().enabled(fixTrustLinesToSelf) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would drop !view().rules().enabled(fixTrustLinesToSelf)
because I don't know if all trust lines to self have been deleted. I feel that this is less defensive as it could be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Can't drop that because there are currently two trustlines to self. Without the check, servers with and without this PR would behave differently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code says that if fixTrustLinesToSelf
is disabled and account_ == uDstAccountID
, we can delete a trustline. Once fixTrustLinesToSelf
is enabled, no other self-issued trustlines will be deleted because the first operand of the &&
operator will be false.
This is fine as long as we know that there are only two self-issued trustlines on the ledger.
Because this PR was originally merged with only 1 approval (and we generally require 2 from core ledger engineers), I asked @drlongle to review. @a-noni-mousse @nbougalis could you respond to the thoughts above? We see that there are two trust lines hard-coded to be deleted. Can someone share how they verified that these trust lines are actually to self? Also, can you share how you confirmed that there are no other trust lines to self? |
@a-noni-mousse @nbougalis if either of you would like to make the changes suggested by drlongle above, please open a new PR with your changes. Thank you! |
We know of these:
Test Plan:
|
I wrote code to parse the SHA Map with objects and find all the trustline where high and low accounts are same and only two you show exist in the recent ledger and no more can be created, but did not put it into this pr because it's not appropriate. let me know what u need |
For transparency and reproducibility, we would appreciate if you could share that code. If it's not much code, you can paste it here. If it's larger, you can put it in a public GitHub gist or repository. |
@sgramkumar At your convenience, please write up the results of your testing here. |
This was tested with mainnet db dump, and accelerated amendment activation (
(and for the other hash too) |
fixTrustLinesToSelf
: Introduce amendment to handle trustlines to self
Trust lines to self are impossible but because of the old bug there are two such trust lines which exist:
2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1 and 326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A. The fixTrustLinesToSelf fix amendment will remove them when it activates. I do not know how to test this change.
High Level Overview of Change
Context of Change
Type of Change
Trust lines must be between two different accounts but two trust lines exist where an account extends trust to itself. They were created in the early days, likely because of bugs that have been fixed. The
fixTrustLinesToSelf
amendment will remove those trust lines when it activates.