Transaction Resolver and Unique Id

[topcoderasdf]

When populating unique_id, if it is not a blockchain address, I think we should use <plugin>::<id>, instead of current <id> format just to be safe. While it is very unlikely to happen, there could be a case where two different transactions from two different exchanges end up sharing an identical internal id.

[eprbell]

This already came up when designing the unique id logic. There are 2 problems with this proposal:

• I'm not aware of any programmatic way to distinguish transaction hashes of all block chains (not just btc or eth) from internal ids (if you know of one please share)
• we cannot add the plugin ID (or any other string) in front of the unique ID, because that would break the transaction resolver: the unique ID needs to belong to a global name space and cannot be qualified. Consider the example of a transfer from, say, coinbase to cbpro, which may use a coinbase internal ID: if you add the plugin ID, then the ids of source and destination wouldn't match and the transaction resolver wouldn't be able to merge the two transaction halves. While it's technically conceivable that internal IDs of unrelated exchanges could conflict, it's also highly unlikely, so unless we find a way that doesn't break things, it's probably OK to leave the logic as is.

[topcoderasdf]

For the first point, I don't quite understand why we need to programmatically distinguish transaction hashes from internal ids. Current design already takes either internal ids or hashes.

For the second point, I actually would like to know whether Coinbase Pro api and Coinbase api assign same internal id for off-chain transfers between Coinbase and Coinbase Pro. My guess is that they don't as every transaction will get a unique internal id. I can't verify it right now as I have just deposited money into my Coinbase Pro account I will need to wait a few days for my pending deposits to be transferrable. So I think it would be nice if someone can actually check if current dali-rp2 is able to resolve off-chain transfer between Coinbase and Coinbase Pro without transaction hints.

If Coinbase and Coinbase Pro actually do assign same internal id, I think we can still create a mapping table that instructs transaction resolver to treat coinbase_pro and coinbase as basically the same plugin during the resolving process. I don't think there will be that many exceptions similar to Coinbase and Coinbase Pro like off-chain transfer. The vast majority will be on-chain transfers and for those we don't add <plugin>.

This is not an urgent problem, but I am mentioning this just for peace of mind

[eprbell]

The vast majority will be on-chain transfers and for those we don't add <plugin>.

This means you need a way to distinguish on-chain transfers from other kinds of transfers (which was my first point).

If Coinbase and Coinbase Pro actually do assign same internal id, I think we can still create a mapping table that instructs transaction resolver to treat coinbase_pro and coinbase as basically the same plugin during the resolving process. I don't think there will be that many exceptions similar to Coinbase and Coinbase Pro like off-chain transfer.

Regarding the second point, the CB-CBPro scenario was just an example: the issue is that adding a prefix to the unique id breaks the transaction resolver. Adding a mapping table goes against the design principle that data loaders are self-contained and independent of each-other.

I appreciate the discussion though: if we find a way to do this that doesn't violate data loader independence and doesn't break the transaction resolver we can consider/expolre it.