Just took a look at that paper. It’s full of errors and misrepresentations. Feel free to pass along the following if you like:
The public key is like the bank account number . . . In a transaction, the blockchain address usually appears as the payee account number.
A public key is not like a bank account number. It is a signature verification system. It’s slightly closer to say that the address is like a bank account number, since this is the value that a transaction recipient gives to the transaction creator to be used for the transfer of value, but even that is terribly misleading. First of all, addresses shouldn’t typically be re-used unless necessary. In this way, the address is more like an invoice number. Secondly, neither the address nor the public key are typically stored in the transaction output. The transaction output is typically encumbered with a set of requirements (defined by a “script”) that must be met for that output to be used as an input to another transaction. While this set of requirements CAN include a public key, it typically doesn’t. Instead it typically will contain a hash of the public key. An address is just a representation of the entire script, frequently containing additional data such as a checksum and a version number used to indicate to wallet software how to build the appropriate output script. Many output scripts are simple puzzles that have NO public key associated with them at all, and multiple different scripts can all use the same public key in entirely different ways that would not lead to them all belonging to a single “account balance”.
The so-called account balance is actually the sum of all UTXOs belonging to the user address
Since most people interact with the blockchain system with a wallet, and therefore think of their “wallet balance” as their “account balance”, and since wallets can generate multiple addresses, it would be more accurate to say that the “so-called account balance is actually the sum of all UTXO for which the wallet (or user) can satisfy the requirements defined in the script (which may include having access to associated private keys.
This feature determines that the total input UTXO value must be equal to the output UTXO value. In most cases, as shown in Fig. 2, the number of input UTXOs is one or more,
There are no input UTXOs. That doesn’t even make sense. A UTXO is an spent transaction OUTPUT. Transactions have inputs, and they have outputs. The outputs may be spent or unspent. If they are unspent, they are called an unspent transaction output (or a UTXO). If they are included in an input, then they are spent. They are no longer unspent, and therefore they are no longer a UTXO.
Every transaction can generate more UTXOs. Therefore, as transactions happen, the UTXO set will become larger and larger, and more memory space should be occupied.
Transactions have outputs, and those outputs are generally initially unspent, therefore it’s true that transactions generate UTXOs. However, transactions also consume UTXO in their inputs. A transaction may have more outputs than inputs, the same number of outputs as inputs, or less outputs than inputs. Common use patterns will determine if a particular blockchain based cryptocurrency will have an increasing number of UTXOs, a relatively static number of UTXOs, or a decreasing number of UTXOs.
The structure of bitcoin blockchain system is shown in Fig. 3
Fig 3 is mistaken in multiple areas. It implies that the merle tree is stored in the block body (it is not). It indicates that the current block hash value is stored in the block header (it is not). It fails to indicate that the difficulty target is stored in the block header. It indicates that the block reward is stored in the block header (it is not).
The block body mainly contains the transaction tree status information supported by hash algorithm . . . The Merkle tree in the block body will sign each transaction digitally, which can ensure that every transaction is unforgeable
No. The block body consists ONLY of the actual transactions that were used to assemble the block. The Merkle tree isn’t stored in the block, and it doesn’t sign anything.
The continuous growth of blockchain database will also reduce the speed of transaction verification by nodes, which will hinder the development of the system.
No. The number of blocks in the blockchain has negligible effect on the speed of transaction verification. Once a transaction has been verified, and its outputs are added to the UTXO set in the mempool, there is no need to ever look at the historical blocks for transaction verification.
Beyond the first 4 paragraphs, everything else in section 2 looks like they were just trying to fill up space to meet some page count requirement for a school project. They have a paragraph about Interplanetary File System, another about Section-Blockchain, yet another about blockchain as an electricity trading system, and a paragraph that just lists work performed by Guo, Mbinkeu, Mei, Wang, El-Hindi, and Gennaro. None of this appears to have any relevance to this paper at all, and leaving all of it out would not make the paper any more difficult to understand.
According to the blockchain running principal mentioned above in Section 1, we can divide blockchain transactions into two types as shown in Fig. 4: Single input multiple output (SIMO) and multiple input multiple output (MIMO)
They completely left out the remaining 2 types: Single input single output (SISO) and Multiple input single output (MISO).
They then include a bunch of transactions where they attempt to calculate a speed at which the UTXO set will grow, but since they are including an output for the transaction fee, and they are leaving out SISO and MISO, their calculations are effectively useless.
Furthermore, this paper appears to go back and forth multiple times between complaining about the need for Full Nodes to store the entire blockchain, and the need for transaction verification to store the entire UTXO set. It doesn’t seem to distinguish between these very well and can leave a reader that is unfamiliar with these concepts lost as to which of these “storage pressures” the proposed solution is supposed to help with. Especially when the paper says things like this:
Compared with the original blockchain system, new method slows down the expansion speed of blockchain transaction databases. The proposed method alleviated thee storage pressure of full nodes to a certain extent
Their “Evaluation” section (section 4) is nothing more than a simulation using their already invalid formula for calculating UTXO growth rather than evaluating real transactions in a real blockchain, or even experimentally creating actual transactions in a test blockchain. They also don’t compare any of their calculations of what they predict will happen to the quantity of UTXO to any current real-life blockchain to see if their predictions match reality.
All in all, I’d rate this paper below average for effort, and a failure for accuracy and usefulness.
Or could it be that in China they actually do create an extra unnecessary UTXO for the fee?
I mean the transaction will be still valid if they did so thinking it is a must???
How would you do that? You'd need to know, when you are creating the transaction, which mining pool will eventually succeed in confirming the transaction. You'd be limiting your transaction to being considered zero fee by all standard full nodes, so they wouldn't relay it, and all other mining pools would also consider your transaction to be zero fee, so they wouldn't confirm it. You'd be waiting more than double the amount of time for your first confirmation, and if you chose your pool poorly you may be waiting MUCH longer than that.
