Bitcoin Cash is about to be upgraded again. What will be upgraded?

Chapter 0 Introduction

The BCH upgrade plan, which is scheduled to be held every six months, is being implemented for the next hard fork upgrade on May 15. I want to understand what the developers are doing. I watched their video conference. Come on, supporters, come and learn, opponents, come and make fun of it. After the fun, everyone can do what they should do.

Chapter 1: Saving Segregated Witness Coins on BCH

The next BCH upgrade is intended to save BCH coins that users mistakenly sent to BTC's segregated witness address.

Because the addresses of BCH and BTC are universal, the addresses of BCH are legal on BTC, and the addresses of BTC are also legal on BCH. The addresses of these two coins can receive coins from each other. The private keys corresponding to the addresses can control the coins received, regardless of whether they are BTC or BCH.

The above paragraph is really confusing. For example, if there is a small mailbox for receiving letters downstairs at your doorstep, many communities will have it. Originally, this kind of mailbox was used to receive letters. But some communities use this kind of mailbox to receive express parcels and milk. The mailbox is like the address of BTC and BCH, they are the same. Letters are similar to BTC, and packages are similar to BCH. The key of the mailbox is like a private key. The mailbox can receive both BTC and BCH. If you want to spend the BTC or BCH you received, just use the key to control it.

But BTC deployed Segregated Witness in 2017, and the Segregated Witness address is different from other BTC/BCH addresses. If BCH is sent to a Segregated Witness address, you cannot use the private key in this Segregated Witness address to spend it.

This segregated witness address is like an "unlocked mailbox", where anyone can take letters and packages from the mailbox. But the BTC network also defines a new rule to prevent the coins in the segregated witness from being "taken away by anyone". This is hard to understand, so let me give you another analogy. It's like installing a "surveillance camera" next to the "unlocked mailbox". If you take coins from the mailbox that don't belong to you, the entire network will not recognize that you have taken them away. The entire network still believes that the letter is in the mailbox until it is spent by the corresponding private key.

There is no such "surveillance camera" on the BCH network. If you send BCH to such an "unlocked mailbox", others can steal your coins. But this theft is not easy. Because if you want to steal such coins, it is a "non-standard transaction" on the BCH network. All nodes will not help you broadcast such non-standard transactions, and mining pools generally will not accept such non-standard transactions.

But if the mining pool wants to steal the BCH on this segregated witness address, it can be done. Now if BCH is mistakenly sent to the segregated witness address of BTC, you need to find a mining pool to help you retrieve it.

On BCH, on April 26, 2018, the BCH block with a height of 527464 contained a large amount of BCH spent from the Segwit address. You can check this block and see that there are many input addresses starting with 3, but the output has only one address starting with 1, and there is no change address. This is the BCH spent from the Segwit address. This is an anonymous mining pool that stole the BCH coins on someone else's Segwit address.

Bitcoin abc plans to deploy an improved protocol called BIP62 in the next hard fork version, which will allow users to use their private keys to spend the coins they mistakenly sent to the isolated witness. As for the principle, I don't know.

I personally think that since BCH was not designed with Segregated Witness in mind, users can also proactively ask mining pools to help spend the BCH coins that they mistakenly sent to the Segregated Witness address. Users and mining pools can just discuss the handling fee. Developers don’t need to design a patch specifically for this kind of problem that can be solved by the free market. Let the free market do what it can do. What if there is a problem with the designed patch?

I find it strange that developers are so nosy. What are you worrying about? Can you stop worrying about other things besides the consensus layer?

Chapter 2 BCH is expected to deploy Schnorr signatures first

If you are a small miner, for example, you receive 0.01 BTC a day, and you receive it for 30 days, a total of 0.3 BTC. If you want to deposit it to an exchange and sell it, you may have to pay a mining fee of 0.1 BTC.

Now many exchanges have set a minimum deposit amount for Bitcoin, for example, they do not accept deposits of 0.001 BTC. Otherwise, if the exchange receives a large amount of 0.001 BTC and wants to send out 1 BTC, you may have to pay a 0.5 BTC mining fee.

Now we issue coins, BTC and BCH are the same, one input has a signature. One signature is about 80 bytes, accounting for the majority of transaction data. Mining fees are calculated based on data size. If there are 10 inputs in a transaction, then 800 bytes of signature data will be spent. Therefore, for transactions with multiple inputs, the signature data will occupy a large amount of fees. This is why small miners have to bear heavy mining fees.

Schnorr signature is a way to make a transaction, no matter how many inputs there are, have only one signature. This can greatly reduce the size of multi-input transactions. If this technology is used, small miners will not need to bear a lot of mining fees.

Schnorr signature technology is useful, but it seems to be quite risky. The benefits are still good on BTC, but on BCH and BSV, there is no need to save on mining fees, and the benefits are not great.

I don’t know what consequences Schnorr signature will cause. If I were the chief designer of BCH, I would choose to design Schnorr signature and merge it into the main code repository, but not activate it on the main network. Let the market copy it and test it on other coins first, such as BTC.

Chapter 3 BCH plans to relax the 25 quantity limit of zero-confirmation chain transactions

If you receive a coin but it has not been confirmed, you can send it to another address immediately. After the next address receives the coin, it still has zero confirmation, and you can send it down again. This way you can send it 25 times in total. If you send more than that, mainstream wallets and nodes will reject it. This kind of zero-confirmation transaction, and the transaction sent down is a zero-confirmation chain transaction.

The 25 chained zero-confirmation transactions are not a constraint of the consensus layer. As long as the mining pool is willing to accept it, you can actually construct 250 chained transactions.

The 25 limit is mainly for security reasons. If this limit is not imposed, it is possible to construct an almost zero-cost attack on the entire network memory pool. The attack principle is as follows.

I use a 1BCH UTXO to send a transaction of (100 million satoshis - 300 satoshis) with no change address. The 300 satoshis are just to make up the 1 satoshi/byte mining fee. I record this transaction as tx1. I don't broadcast it either, so it must be zero confirmation. I continue to use this output of (100 million satoshis - 300 satoshis) as input to transfer another transaction of (100 million satoshis - 300 satoshis - 300 satoshis). Then continue to transfer another transaction of (100 million satoshis - 300 satoshis - 300 satoshis - 300 satoshis)... and so on, until the 100 million satoshis UTXO is consumed and only 600 satoshis are left.

Next, I construct a final transaction, which I record as txn.

At the same time, use transaction ductility to construct a completely legal tx1' transaction for tx1. Also broadcast tx1'.

As long as a mining pool packages tx1', all transactions from tx1 to txn above will become illegal transactions.

If tx1' is packaged, the attacker has successfully attacked the memory pool of all nodes in the entire network, and only used the handling fee of one transaction, so the cost of the attack is almost zero.

This attack can be used by a mining pool to attack other mining pools. It makes other mining pools in the entire network waste time to verify tx1 to txn, while it secretly packages tx1'. It feels so good.

But the limit of 25 is not in the consensus layer. If the mining pool wants to avoid being attacked, it can limit it by itself. So I think this limit of 25 zero-confirmation transaction chains is completely unnecessary.

The underlying protocol should remove as many restrictions as possible that can be handled by the free market. I say that developers just like to worry about things and don't have enough confidence in the free market. It's totally unnecessary. What are they worrying about?

Chapter 4 Conclusion

BCH keeps changing, and I don’t know when it will end.

Author: Huang Shiliang

Welcome to follow WeChat official account: Lightning HSL

Welcome to reward BTM: bm1qefc720au672awrgazgw5c3kx7etr5kejju02p7