A solution to realize small and micro payments of digital currency

There are two problems with the Bitcoin main chain (including BTC, BCH, and BSV) for small and micro payments. The first is that the miner fee is too expensive and the lower limit of the payment amount is too high. Needless to say BTC. An ideal small and micro payment should be to support ultra-small amounts and ultra-low miner fees, such as 1 Satoshi amount and 1 Satoshi / transaction. But now the Bitcoin network has a dust-proof attack setting. The minimum payment amount is 546 Satoshi, the miner fee is at least 1 Satoshi / byte, and one transaction is at least 225 Satoshi.

The second problem of small and micro payments is that there will be too many historical transactions on the network. The payment of micro and micro is bound to be huge, and it will certainly far exceed the number of payments on the current main chain. Blockchain networks need to save all historical transactions, each transaction is at least 225 bytes, huge transactions will cause huge hardware requirements for the network. This may hurt decentralization.

For confirmation time, small and micro payments are not sensitive, just accept zero confirmation.

The BTC + Lightning Network needs further development before it can solve small and micro payments. This article does not comment on this.

• 2019: "Year of the Blockchain" in Washington, Silicon Valley and Beijing
• SIBC Lands in Qiantang New District, Hangzhou, Builds Asian Blockchain Project Bridgehead
• Filecoin test network is about to go live, these changes need attention

Can you build such a scheme:

1. Instead of issuing new coins, construct a new transaction format in existing Bitcoin (whether BTC, BCH or BSV), which is used to complete small and micro payments.

2. The micro-payment history can be clipped. We additionally construct a special transaction that is updated using a soft fork.

Now suppose that under all agreement rules, two transaction formats, P2PKH and P2SH, are included (just for example, there are many other transaction formats, and assumptions are made here for convenience of description). Now a new transaction format P2MP (Pay to Micro Payment) is to be added.

P2MP is specially used for micro payment. It uses the new address format. The default transaction amount is less than or equal to 10000sat and greater than 0sat. The miner fee defaults to a fixed 0.01sat per byte (the existing one percent).

Construct a new block (let's call it micropayment block) and anchor it to the existing block (let's call it main block). P2MP transactions are specifically collected with new blocks.

The micro payment block uses the design of the extended block. For the design of the extended block, please refer to the Chinese translation of the extended block Github document.

Transfers within the micro payment block should be very easy to implement. The difficulty lies in how to realize payment from the main block to the micro payment block, and how to pay from the micro payment block to the main block.

At the end of the main block, design a special collection of all transactions from the main block payment to the micro payment block, we call it the coinbase at the end of the main block (this corresponds to the mining reward coinbase transaction at the head of the block ). The input of the tail coinbase transaction is the input of all transactions entering the micro payment block; the output of the tail coinbase transaction is a special lock script. The public key part of this script is left blank, and the signature part is designed to meet specific conditions Is true. This output is similar to a UTXO that anyone can spend.

Coinbase tail transaction output of the main block:

scriptPubKey: leave blank

scriptSig: Special condition is True The input of the tail coinbase transaction in the latest height of each main block must include the output of the tail coinbase transaction in the previous block.

The latest height of the output of the coinbase at the tail of the main block = the amount of coinbase transaction output at the tail of the previous block + the amount of entering the micro payment block-the amount of leaving the micro payment block-the miner fee for the micro payment block transaction

For the first transaction in the micro payment block, the input is left blank. This is the same as the mining coinbase transaction in the main block, and the output is the output corresponding to all transactions entered into the micro payment block from the main block.

The coinbase transaction at the tail of the main block and the coinbase transaction at the head of the micro payment block form a bridge, transferring the coins in the main block to the micro payment block.

To pay from the micro payment block to the main block, follow the above process and vice versa.

Micropayment blocks can be discarded. When verifying a block, the existence of a micropayment block will not affect the verification of the main block, but to verify a micropayment block, the corresponding main block must be obtained to complete the verification. Under this design, even if a main block is abandoned, even if the micro payment block is abandoned, the legitimacy will not be affected, so that the complete node can abandon the micro payment block.

Disposable micro-payment blocks, so that historical transaction data formed by micro-payments does not create cost pressure on the main network.

The transaction in the micro payment block can be set for a time. For example, after 100,000 blocks, the node can discard the micro payment block.

The micro payment block can even be designed as an account system. The account system does not generate a large amount of fine UTXO, and each payment is to modify the balance, instead of deleting the original UTXO like UTXO and generating a new UTXO. The account system can even be implanted with a virtual machine, such as Ethereum and EOS, allowing the Bitcoin network to truly use smart contracts.

From the perspective of technical implementation, the code of the extended block has been written, and it is written by the basic bitcoin core 0.13. It was written in 2017. It should not be too difficult to modify this code into a micropayment extension block.

In terms of current technological developments, is it possible for BTC, BCH and BSV to implement similar solutions? On the technology development path, BTC mainly develops the lightning network to solve the micro payment scenario. BSV does not support major modifications on the main chain. BCH will not set limits on the technical route, but this concept is still not mentioned.

Maybe I think too much.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!