-
Notifications
You must be signed in to change notification settings - Fork 18
Description
two blocks from the same source chain (e.g. (0->1) and (0->3) can be spending the same output_ref.
Only on the next intra-block (0->0), it will decide which block is winning, the other block will mark the tx as being conflicted.
So the block will still contain the tx, but there will be a field conflictedTxs = [<tx_id]
That's currently what EB needs to know to handle those conflicting blocks.
FYI since Danube we currently have 16 blocks with a conflicted tx
Which means when you fetch transactions for a given address, you could receive 2 txs that are spending the same output, and few moment later, once an intra block validate one of the transaction, calling back the transactions will return only 1 of the transactions.
The idea to only call the EB endpoints for fetching address related data only when there is a new latest tx hash is not sufficient anymore, since data might change. We cannot keep them cached.
we might need to check for duplicate input to trigger some refetch