When a transaction occurs, its characteristics are classified into the following four types:
- Standard and secure transactions
- Non-standard but secure transactions
- Standard but insecure transactions
- Non-standard and insecure transactions
The transaction check before adding it to the memory pool is hardcoded. During this process, types 2 and 4 are excluded to distinguish between standard and non-standard transactions.
By the way, type 1 is a regular transaction and poses no issues. So, what’s left is type 3, correct?
This type 3 has a dynamic nature, making it impossible to exclude via hardcoding. Therefore, AI reasoning is utilized.
However, once a transaction enters the memory pool, I realized that it’s challenging to cancel a standard but insecure transaction. Although I initially thought AI monitoring across all nodes could eliminate such transactions, I have concluded that this idea is too optimistic.
The reason is that it’s impossible to distinguish whether the cancellation of a transaction was done by AI or not. This could lead to legitimate transactions being arbitrarily canceled, potentially resulting in spam.
Therefore, it has become clear that implementing AI reasoning for anomaly detection before transactions enter the memory pool is the effective approach. In other words, the idea is to invalidate such “standard but insecure transactions” using AI reasoning or similar technology before they enter the memory pool.
However, this method is also meaningless. The reason is that hackers do not need to release the “standard but insecure transactions” into the targeted node’s memory pool.
Let’s assume that the targeted node implements AI monitoring using reasoning. If a “standard but insecure transaction” is released into that node, the monitoring would indeed block such transactions from entering the memory pool, preventing them from being incorporated into a block, and thus the transaction would not succeed.
However, blockchain is decentralized. Each node operates independently, and users can release transactions that will be incorporated into a block through any node. This means hackers can release such transactions into nodes with relaxed memory pool acceptance settings without having to release them into the node with AI monitoring.
Incidentally, the strictness of transaction acceptance is higher for “memory pool acceptance” than for “block inclusion.” In other words, once a transaction enters the memory pool and miners exist, it is “almost certain” to be included in a block. Furthermore, due to the nature of blockchain, once a transaction is included in a block, even if it is fraudulent, it is finalized.
Thus, even if a suspicious transaction is detected, the balance will be lost. At the point when the alert is triggered, such a transaction will already be present in other memory pools due to propagation from other nodes. By the time the alert appears, “you will observe that the transaction has already been included in a block,” meaning the transaction is finalized, and it’s too late.
Moreover, this phenomenon can easily bypass even the concept of a cold wallet. This is because the wallet simply bundles the scriptPubKey it manages and calculates the balance. The wallet itself does not interact with transactions or trading.
Therefore, once a transaction is constructed, hackers can freely choose which node to release it to, making the wallet concept independent of this process.
In this way, every method seems to lack the final solution, always bringing things back to square one. The only way to tackle this unresolved issue is to continue generating ideas every day and repeatedly test them.
There is only one countermeasure, and that is the following link.
