4 ms·

Another fantastic proposal by one of the Bitcoin Cash devs. It seems BTC is experiencing a serious brain drain as a result of the block size war. Sadly this i

Another fantastic proposal by one of the Bitcoin Cash devs. It seems BTC is experiencing a serious brain drain as a result of the block size war. Sadly this innovation won't work near as well on the BTC chain unless usage continues to plummet. As we've seen in the past, the slightest short term increase in transaction demand results in fees so high that most outputs in the utxo set become unrecoverable (the fee becomes greater than the value of the output). This leaves the BTC utxo set unmanageable and unpredictable. Although the utxo set on BCH grows at a much greater rate, the 32mb block size makes it so that outputs can be inexpensively consolidated, regardless of short term transaction demand. That being said, Lightning Network could potentially allow this innovation on BTC if it's able to successfully move transactions off chain. With the trouble they've been having with regards to routing and payment channel requirements, I wouldn't be HODLing my breath.

tomtomtom777 8y ago
> This leaves the BTC utxo set unmanageable and unpredictable. Although this is true, I don't think this eliminates the possibility of such UTXO commitment. It is iteratively updated every block and doesn't care about predictability. The code as written could be easily merged into BTC as well. The only small difference would be in backtracking: When we have full node that uses fast syncing we could implement that they retrieve older blocks until they are satisfied (either by assumevalid or some accumulated work), and verify from that point. They can simply apply the commitment backwards. On Bitcoin Cash, this would require block propagation that includes the TxOuts being spent by the block. This is a bit more difficult on Bitcoin to the difference in sighashing: these TxOuts aren't directly committed transactions that spend them.

tomtomtom777 8y ago

> This leaves the BTC utxo set unmanageable and unpredictable. Although this is true, I don't think this eliminates the possibility of such UTXO commitment. It is iteratively updated every block and doesn't care about predictability. The code as written could be easily merged into BTC as well. The only small difference would be in backtracking: When we have full node that uses fast syncing we could implement that they retrieve older blocks until they are satisfied (either by assumevalid or some accumulated work), and verify from that point. They can simply apply the commitment backwards. On Bitcoin Cash, this would require block propagation that includes the TxOuts being spent by the block. This is a bit more difficult on Bitcoin to the difference in sighashing: these TxOuts aren't directly committed transactions that spend them.