I am currently in the process of reverse engineering chias transaction history. Unfortunately, the documentation still half-baked despite all the recent improvements to it.
The history brings quite a few uncertainties which for now are documentaed in detail in:
I am working with the chia team to do clarifications while I am slowly progressing forward by trial and error as well as testing.
example for an offer creation and approval (3 transactions):
you get an INCOMING_TRADE transaction with no removal coins but an addition which represents the offer creation. This Transaction is not confirmed on the blockchain
You get an INCOMING transaction with the same data. This transaction confirms the offer on the blockchain, but you need to match it against the INCOMING_TRADE transaction in order to identify it as an offer
You get an OUTGOING_TRADE transaction upon offer completion. This offer needs to be validated against 1. and 2.
If someone has detailed information about these processes, it would be greatly appreciated.
Ive Gotten a little further, but it’s not beautiful:
The Transaction History in the chia space are heuristic. They are not deterministic:
Transaction history is not deterministic due to heuristics we use to counter privacy features of the blockchain. the wallet does a best effort. we are trying to improve this going forward. for accurate records you should keep a local record of TXs made. If the balance is not the same (within a mojos because of dust filtering) please let us know. GitHub Issue
This means that I can throw the get_transactions rpc of the wallet to the bin.
As a workaround, I can build my transaction history from the following information:
I accept an offer: This is easy because I accepted it
Someone accepts my offer: this is feasible since I created the offer once, and can check it periodically
I send out a transaction: straight forward
I receive a transaction: here we go. There is the issue. I have not been involved. I do not know that a transaction was or will be executed. How can I circumvent this and log incoming transactions in a deterministic way?
I think you are touching on a real issue, and digging deeper from my perspective. The coin set model facilitates spend-ability to key holder while maintaining security from the world-at-large through an under-recognized need for a sophisticated wallet imo. This software package must able to detect all spendable coins to that key set, or potentially leave money on the table (quite literally) when a customer abandons the wallet. The more derivations of the original key set, the more sophisticated the wallet software needs to be and the more processing it needs to do. Same principle with the more types of spendable coin specifications; NFTs, CATs, Datalayer, etc and more coin identification schemes; hinting, etc. Someone has to build and maintain chia wallet software compatible with all of these specifications as they evolve; Cat1->CAT2 etc. There is expense involved in that and there is uncertainty to folks outside of CNI wondering what’s next. Also, once there is an adequately sophisticated independent wallet I see risk because it doesn’t necessarily have to be open source like the CNI wallet is. Therefore, a 3rd party wallet might devise a proprietary coin spec(or two) to keep unwitting customers locked into staying on their product so that customers coins are only spendable based on their proprietary algorthm.
Anyway, the true challenge imo, is what you have pointed out specifically for 3rd party payments to you on the blockchain. How good of a job is your version of the wallet doing at seeing all spendable coins as yours? You raise good points and I wonder if my wallet detects everything.
Honestly, I think there might be a 3rd Party service opportunity where upon abandoning a wallet users give their private keys to a service and that service has the most sophisticated and fastest processor wallet to scour the blockchain. Upon finding anything there could be a 50-50 split or something like that.
