One of the most challenging parts of a crypto-platform is how it resolves double-spending, i.e., when two or more transactions are spending the same “money” — or, being more specific, spending the same output.
Blockchain architecture resolves double-spendings just choosing the transaction in the longest chain as the winner. The remaining transactions in the double-spending are voided.
Hathor resolves double-spendings in a way similar to Bitcoin but adapted to a DAG architecture. Hathor chooses the transaction that has the highest accumulated weight as the winner. The remaining transactions are called conflict-voided (and both their sub-dag of verifications and their sub-tree of funds are voided as well and called ancestor-voided).
The accumulated weight of a transaction A is a measure of how much proof-of-work has been done by other transactions that verify A both directly and indirectly (i.e., its descendants in the DAG of verifications). The higher the accumulated weight, the harder it becomes to void the transaction.
Looking into the tree of funds on the left, both transactions 41b0 and d99a spend the same output of the block 6e44, i.e., they are a double-spending.
As 41b0’s accumulated weight is higher than d99a’s, the transaction d99a is conflict-voided. All transactions in its descendant tree are marked as ancestor-voided (9be1, 1b3c, 6c51, and a362).
But, why would transaction 2ec9 be marked as ancestor-voided? Looking into the DAG of verifications below, we notice that 2ec9 verifies 426a. Back to the tree of funds, 426a spends an output of 3fbf, which is voided due to a double-spending with 5be4.
In other words, a transaction is valid if, and only if, all its ancestors in both the DAG of verifications and the tree of funds are valid. Otherwise, it is voided.
Thanks for reading and let me know if you have any questions or have a suggestion for the next article.
For further information about Hathor Network, see https://hathor.network/.
