Bitcoin ABC develops node software and infrastructure for the eCash project. This a mirror of the official Bitcoin-ABC repository. Please see README.md
A UTXO-based blockchain structure with a native token method, which I call "dye coins."
The transaction output class needs to add a new field called "color".
The block header needs to add a new field called "color".
The validation of ordinary transactions needs to add additional validation logic.
The validation of Coinbase transactions needs to add additional validation logic.
The validation of blocks needs to add new validation logic.
Specific logic is as follows:
After the transaction output has the color tag field, there are only two results, 0 (all 0) indicates not marked, non-0 indicates marked.
To verify that a normal transaction (non-coinbase) is valid, additional validation logic needs to be added. Specifically, it means that the input and output of all transactions must be traversed to ensure that the output values of all colors are less than or equal to the input values of the corresponding colors.
Miners need to verify that all or some of the normal transactions in the transaction pool that need to be packaged meet 2, and calculate the difference between all the corresponding colors in all these transactions as utxo (can be single or multiple) added to the Coinbase output.
A coinbase transaction is a special transaction that essentially has no input and only output. In addition to the utxo generated by the block miner fee, the coinbase transaction itself has a certain number of native token rewards.
The structure of a coinbase transaction that does not participate in color marking is as follows:
Assuming that the current block reward is 50 white coins, and the transaction output generated by the miner fee contains 10 red coins, 10 green coins, and 10 white coins.
When constructing a coinbase transaction, 3 red coin outputs (3 red coin outputs total 10) can be output, 2 green coin outputs (2 green coin outputs total 10) and 1 white coin output (output quantity is equal to 60)
The structure of a coinbase transaction that participates in color marking is as follows:
Assuming that the current block reward is 50 white coins, and the transaction output generated by the miner fee contains 10 red coins, 10 green coins, and 10 white coins.
When constructing a coinbase transaction, 3 red coin outputs (3 red coin outputs total 10) can be output, 2 green coin outputs (2 green coin outputs total 10), and the remaining 60 white coins will be dyed yellow as a single output (or multiple outputs). However, 60 white coins cannot be dyed yellow, 30 blue, and white coins can only be dyed the same color and a color that has not appeared before (how to determine if the color exists will be mentioned later), otherwise the transaction will fail.
Next, the miner will pack all the transactions to generate the Merkle tree, and assign the color value of the dye in the coinbase transaction to the color field in the block header, and then start Proof of Work to generate the block.
After the miner generates the block, it will broadcast the block to the entire network.
Other miners will verify the validity of the block. This includes verifying the validity of each transaction, especially the coinbase transaction. It must be ensured that the only color that can be dyed in the coinbase transaction is one color (not that there is only one color of output), and that this color has never appeared before (it can be obtained by traversing all the block headers or caching all the colors locally). Otherwise, the transaction will fail. If there is no dyeing (meaning that the output of the coinbase transaction does not produce a new color utxo, and the number of utxo tokens of other colors does not increase), the traversal process can be skipped.
Verify whether the color value in the block header (0 if no dyeing) is equal to the new color value in the coinbase transaction. If equal, the block is valid, the block is added to the blockchain, and the next block is mined. If not equal, the block is invalid and the block is rejected.
[Note] There is no inflation problem here, because inflation can be achieved simply by adding one more color utxo, for example, green and red are marked as US dollars.
Implementation: The block header and transaction data structures themselves have a built-in version number field. Version number increases can be used to implement upgrades, which are also part of the protocol.
A UTXO-based blockchain structure with a native token method, which I call "dye coins."
Specific logic is as follows:
Implementation: The block header and transaction data structures themselves have a built-in version number field. Version number increases can be used to implement upgrades, which are also part of the protocol.