Trustlines to self are impossible but because of the old bug there ar…
…e two such trustliens 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
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Refactor (non-breaking change that only restructures code)
- [ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
- [ ] Documentation Updates
- [ ] Release
@cryptobrad can you please rebase your PR to 1.9 it is giving us merge conflicts while adding this to the next beta. Thanks 🙏
I have finished the rebase. Will this be merged?
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!
- Take current ledger; iterate all trustline (RippleState) objects, and list any trustlines where the two sides of the trustline are equal to each other, i.e. if A and B are the same.
We know of these:
- 2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1
- 326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A
Test Plan:
- Bring up a network that starts from current network state. (Copy database files from existing Mainnet server. No need for [full] history.) Use
--ledger <ledger hash>(and maybe--load?) - Accelerate amendment activation (change timeout from 2 weeks to a short period of time, e.g. 1 hour).
[feature]won't do the right thing as it won't activate the amendment in the normal way. Maybeamendment_majority? - Verify that the amendment worked correctly.
- Take current ledger; iterate all trustline (RippleState) objects, and list any trustlines where the two sides of the trustline are equal to each other, i.e. if A and B are the same.
We know of these:
* [2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1](https://xrpl.org/websocket-api-tool.html?server=wss%3A%2F%2Fs1.ripple.com%2F&req=%7B%22command%22%3A%22ledger_entry%22%2C%22index%22%3A%222F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1%22%2C%22ledger_index%22%3A%22validated%22%7D) * [326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A](https://xrpl.org/websocket-api-tool.html?server=wss%3A%2F%2Fs1.ripple.com%2F&req=%7B%22command%22%3A%22ledger_entry%22%2C%22index%22%3A%22326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A%22%2C%22ledger_index%22%3A%22validated%22%7D)Test Plan:
* Bring up a network that starts from current network state. (Copy database files from existing Mainnet server. No need for [full] history.) Use `--ledger <ledger hash>` (and maybe `--load`?) * Accelerate amendment activation (change timeout from 2 weeks to a short period of time, e.g. 1 hour). `[feature]` won't do the right thing as it won't activate the amendment in the normal way. Maybe `amendment_majority`? * Verify that the amendment worked correctly.
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
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.
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.
@sgramkumar At your convenience, please write up the results of your testing here.
This was tested with mainnet db dump, and accelerated amendment activation (fixTrustLinesToSelf) on 1.10.0-rc3
After the amendment was activated, the following 2 trustlines were removed
- 2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1
- 326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A
"result" : {
"error" : "entryNotFound",
"ledger_hash" : "A7C9310D455DF826C01B41659C646D17CA796556D7E4BF392AF6A7A7F4872AAD",
"ledger_index" : 78112941,
"request" : {
"api_version" : 1,
"command" : "ledger_entry",
"index" : "2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1",
"ledger_index" : "validated",
"method" : "ledger_entry"
},
"status" : "error",
"validated" : true
}
(and for the other hash too)