A Debit transaction is shown again as Credit for the same account even though the recipient is a different account and has received the NXS

[Aeonwise]

This was reported by a community member that on the explorer he is shown a Ghost Credit transaction which is not valid.

The Debit transaction has been Credited successfully to the recipients account.

Account is a normal account: 8CuDNLdtbWUdjEoJS4uzXKsLmZNq2bCwrbrPPw8hBT7iMCwH79y

This is the Ghost Credit transaction and in this the account type is mentioned as "TRUST" even though it is a normal account

{
"txid": "01cf557d25ccb22a02d7e45037886a629471a71ee7f1b2ddff1a645f4e31c5e77727eab0579495320a7d90d5da0baf0860c657ccadd4738081a8a46c34a04ecb",
"type": "tritium user",
"version": 4,
"sequence": 2643,
"timestamp": 1681132850,
"blockhash": "6987fe6acd0af4b7f710bb652f9fd0da171a1a33e4ff34749b18bf3b46018e0ba292e50946b46e19bba637aa209300b6bfca2cb11d9f797ed17281ab8614360838c1df5875ef9e1486e129b8905248389c9ecad3163678460581e951be87ddca763c9b10fa67c9ef30feefa6aff2b17de60cabc02d6eafefb37daef7ffa5683e",
"confirmations": 2898,
"contracts": [
{
"id": 0,
"OP": "CREDIT",
"for": "DEBIT",
"txid": "01c4b4d0a8f404c54ae77d70ed5aee99a7421b450736a96915a075ca1ed369052ef32fc17a3abb143bb582223a86fc9d70b89268adcbf1f6a3bdc3bd12385246",
"contract": 0,
"from": {
"address": "8CuDNLdtbWUdjEoJS4uzXKsLmZNq2bCwrbrPPw8hBT7iMCwH79y",
"name": "Hodling",
"local": true,
"mine": false,
"type": "TRUST"
},
"to": {
"address": "8GHHCNoV3jbGLXaEBqpNnxnqUNzyMiXHHUukbHC1M2tRL1Bta2f",
"name": "trust",
"local": true,
"mine": false,
"type": "TRUST"
},
"amount": 8713,
"token": "0",
"ticker": "NXS"
}
]
},

This is the Debit Transaction for the credit, here the account type is "ACCOUNT"

{
"txid": "01c4b4d0a8f404c54ae77d70ed5aee99a7421b450736a96915a075ca1ed369052ef32fc17a3abb143bb582223a86fc9d70b89268adcbf1f6a3bdc3bd12385246",
"type": "tritium user",
"version": 4,
"sequence": 2642,
"timestamp": 1681132837,
"blockhash": "4ebbd4beb98e352a37341f81505db130cbbb805b2a1799e3ee572b971cda80bc174433171d10f94c816ceedf8ddb57df6953357ea263284160e175926369342f1049fa87978231615c7f187406931087cfa8a8b068e0ef30a472b323ebce955b8026d81e7fcce0d805dd3c428330923f07449a4eb0d5dd5247bd2bffb57f05f0",
"confirmations": 2899,
"contracts": [
{
"id": 0,
"OP": "DEBIT",
"from": {
"address": "8CuDNLdtbWUdjEoJS4uzXKsLmZNq2bCwrbrPPw8hBT7iMCwH79y",
"name": "Hodling",
"local": true,
"mine": false,
"type": "ACCOUNT"
},
"to": {
"address": "8GHHCNoV3jbGLXaEBqpNnxnqUNzyMiXHHUukbHC1M2tRL1Bta2f",
"name": "trust",
"local": true,
"mine": false,
"type": "TRUST"
},
"amount": 8713,
"token": "0",
"ticker": "NXS",
"claimed": 8713,
"reference": 0
}
]
},

[Aeonwise]

Also found that the receiving Trust account for the Debit, shows both the Credit & Debit transactions.

Trust Account: 8GHHCNoV3jbGLXaEBqpNnxnqUNzyMiXHHUukbHC1M2tRL1Bta2f

[NamecoinGithub]

Did you Verify that the person who the Nexus was sent to Confirmed getting the NXS also?

Because although I am not sure I agree with the architecture of it, Nexus requires the Receiver to login within 1 day or 3 days I cannot remember which to "CLAIM" the transaction otherwise it gets sent back to the user/sender just as you describe!

I think a lot of people might lose Money or Products due to lack of knowledge of this fact, and it's probably impossible to instruct every user that both Sender AND Receiver have to be logged in for a Transaction to Finalize, probably leaves lots of Room for Future Scams for not Aware People IMO

[NamecoinGithub]

Thanks, changing the Title makes much more sense about what is possibly going on!

After thinking about it, it is still probably related to the Built in Loop of returning the Coins back to the sender after 1 Day of non-claimed NXS by a logged in receiver

This is likely related to the new Profiles feature exposing the Loop Return Keys, but that still doesn't explain why there would be 2 times as many coins without producing them.........

Can you try having Both Parties test sending part of the remaining balance to another 3rd party address to check if BOTH Shown balances are still spendable with their Private Keys......

I wonder if Sealing this part of the Code off with making all Transactions Irreversible without the need of the user loop of logging in to "Claim" the NXS.........this would possibly break Tritium and how it operates so IDK what Colin will say, but at the same time finding this bug revealed possible Code Structure errors that need fixed.........

It's probably dependent more on if Both those Balances are spendable on what course of action to take

As most people might not report such "Bugs" and crash Exchanges ect...........so Sealing off the code would be more desired than running into future Possiblities using NXS Profiles features and OP Return Transaction Code to return NXS coins after 1 day of not being "Claimed"

I assume your testing the New Release with the Profiles feature anyway.........

AFAIK

[NamecoinGithub]

Ok, so Both of those Addresses are the same Owner, so this person is sending this transaction to themself not to another person

It doesn't look like there are 2 credits and 1 debit it looks like they cancelled each other out, there is no extra coins...........

[VidereLicet]

There was a bug in the old wallet that didn't credit back some of these expired contracts, since the new wallet has this fixed a lot of users have gotten back coins that were not ever claimed by the senders. Current expiration is 7 days, but we will see if there's a way to help users become aware of this architecture.