
First UTXO Commitment on Bitcoin Cash Testnet Explained - tomtomtom777
https://www.yours.org/content/first-utxo-commitment-on-testnet-db7bf45bf83d
======
uncletammy
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
> 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.

------
Sir_Substance
>Why do full nodes need this? They don’t actually validate these blocks.

This is straight up not correct:

[https://bitcoin.org/en/developer-
guide#p2p-network](https://bitcoin.org/en/developer-guide#p2p-network)

[https://en.bitcoin.it/wiki/Full_node#Economic_strength](https://en.bitcoin.it/wiki/Full_node#Economic_strength)

[https://en.bitcoin.it/wiki/Myths#Miners.2C_developers_or_som...](https://en.bitcoin.it/wiki/Myths#Miners.2C_developers_or_some_other_entity_could_change_Bitcoin.27s_properties_to_benefit_themselves)

The mining process makes it expensive to lie to the network, but if no one is
checking for lies it could still be lied to. Full nodes check that mining
nodes aren't including invalid transactions. The requirement to submit a valid
hash with your mined block means that the network can't be spammed into
oblivion. Check the hash first (cheap), and if the hash passes, check
/everything/ in the block to make sure it's all valid (expensive). If the
block contains only valid transactions accept it, federate it to your peers,
and thus give the miner lots of money. If the block contains any invalid
transactions, reject it, thereby levying on the miner an opportunity cost for
doing the wrong thing.

Removing the second step of validation would mean that you could attack the
network with considerably less than 51% hash power. You could buy 1% of the
hashpower and submit fraudulent blocks 1% of the time on average. Note that
submitting fraudulent blocks is not the same kind of attack as a 51% attack.

Anyway, you see this "full nodes don't validate the blockchain" nonsense a lot
from altcoins that think they've found a neat-o way to get faster/cheaper
transactions. They usually have, but they invariably have to lose the
trustless nature of the system to do it, at which point you'd be better of
using a regulated bank. It's a big red flag that the developer of a coin
doesn't actually understand the technology they are using.

~~~
tomtomtom777
It is correct. Here is the default assumevalid on mainnet Bitcoin:

[https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a...](https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3abe1d8b3cb64cfc1472ce/src/chainparams.cpp#L108)

> Anyway, you see this "full nodes don't validate the blockchain" nonsense a
> lot from altcoins that think they've found a neat-o way to get
> faster/cheaper transactions.

I am not saying "full nodes don't validate the blockchain". I am explaining
that full nodes (on both Bitcoin as well as Bitcoin Cash) don't validate
historical blocks. This would take way too much time, and as I explain in the
article doesn't really reduce trust in the software.

Here is the mechanism by which the Bitcoin Core implementation uses
"assumevalid":

[https://github.com/bitcoin/bitcoin/blob/7f4db9a7c3549a36e45d...](https://github.com/bitcoin/bitcoin/blob/7f4db9a7c3549a36e45d70fc3c159367aa1e99a4/src/validation.cpp#L1875)

~~~
Sir_Substance
Checkpoint blocks are an interesting topic, but there's a mile between
checkpoint blocks and "full nodes don't validate transactions so why bother
keeping that block data around?".

They're also not about trust, they're about protecting against DoS attacks:

[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial...](https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_\(ch_5\):_Initial_Block_Download#Checkpoints)

Even with checkpoint blocks, a full node can elect to validate it's entire
history if it chooses to, which again is a far cry from "block history data is
worthless because full nodes don't validate it", a flagrantly untrue
statement.

~~~
tomtomtom777
Bitcoin Core, since 0.14 doesn't use checkpoints. It uses "assumevalid" which
assumes the signatures of transactions are valid.

> "block history data is worthless because full nodes don't validate it"

Please don't misquote people.

