4 ms·

First UTXO Commitment on Bitcoin Cash Testnet Explained

20 points by tomtomtom777 8y ago

Sir_Substance 8y ago
>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_some_other_entity_could_change_Bitcoin.27s_properties_to_benefit_themselves https://en.bitcoin.it/wiki/Myths#Miners.2C_developers_or_som... 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.
- yafujifide 8y ago
  I think you misunderstood that sentence. Full nodes validate new blocks, but they don't validate all historical blocks at initial sync.
  - Sir_Substance 8y ago
    Yes, they do. That's why it takes fucking forever to start a fresh one up. Citation: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Background https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial...
    - yafujifide 8y ago
      No they don't. See the link posted by the author: https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3abe1d8b3cb64cfc1472ce/src/chainparams.cpp#L108 https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a... Full nodes validate a lot of blocks at initial sync, but not all of them.
      - Sir_Substance 8y ago
        And here's my rebuttal to that misleading link: https://news.ycombinator.com/item?id=17233986 https://news.ycombinator.com/item?id=17233986
    - tomtomtom777 8y ago
      No, they don't. Please check the code. Please check the discussion: https://www.reddit.com/r/Bitcoin/comments/5yf0ex/trust_assumptions_in_assumedvalid_in_bitcoin_core/ https://www.reddit.com/r/Bitcoin/comments/5yf0ex/trust_assum... Please check the news: https://bitcoinmagazine.com/articles/bitcoin-core-0140-released-whats-new/ https://bitcoinmagazine.com/articles/bitcoin-core-0140-relea... Or just run your own node: bitcoind --help and see what it says.
- tomtomtom777 8y ago
  It is correct. Here is the default assumevalid on mainnet Bitcoin: https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3abe1d8b3cb64cfc1472ce/src/chainparams.cpp#L108 https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a... > 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/7f4db9a7c3549a36e45d70fc3c159367aa1e99a4/src/validation.cpp#L1875 https://github.com/bitcoin/bitcoin/blob/7f4db9a7c3549a36e45d...
  - Sir_Substance 8y ago
    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_Block_Download#Checkpoints https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial... 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 8y ago
      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.
    - tylersmith 8y ago
      They could elect to validate all historic blocks before the UXTO set commitment too if they chose to.
uncletammy 8y ago
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.

20 points by tomtomtom777 8y ago

>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_some_other_entity_could_change_Bitcoin.27s_properties_to_benefit_themselves https://en.bitcoin.it/wiki/Myths#Miners.2C_developers_or_som... 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.

yafujifide 8y ago
I think you misunderstood that sentence. Full nodes validate new blocks, but they don't validate all historical blocks at initial sync.
- Sir_Substance 8y ago
  Yes, they do. That's why it takes fucking forever to start a fresh one up. Citation: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Background https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial...
  - yafujifide 8y ago
    No they don't. See the link posted by the author: https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3abe1d8b3cb64cfc1472ce/src/chainparams.cpp#L108 https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a... Full nodes validate a lot of blocks at initial sync, but not all of them.
    - Sir_Substance 8y ago
      And here's my rebuttal to that misleading link: https://news.ycombinator.com/item?id=17233986 https://news.ycombinator.com/item?id=17233986
  - tomtomtom777 8y ago
    No, they don't. Please check the code. Please check the discussion: https://www.reddit.com/r/Bitcoin/comments/5yf0ex/trust_assumptions_in_assumedvalid_in_bitcoin_core/ https://www.reddit.com/r/Bitcoin/comments/5yf0ex/trust_assum... Please check the news: https://bitcoinmagazine.com/articles/bitcoin-core-0140-released-whats-new/ https://bitcoinmagazine.com/articles/bitcoin-core-0140-relea... Or just run your own node: bitcoind --help and see what it says.
tomtomtom777 8y ago
It is correct. Here is the default assumevalid on mainnet Bitcoin: https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3abe1d8b3cb64cfc1472ce/src/chainparams.cpp#L108 https://github.com/bitcoin/bitcoin/blob/11adab39e6019935aa3a... > 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/7f4db9a7c3549a36e45d70fc3c159367aa1e99a4/src/validation.cpp#L1875 https://github.com/bitcoin/bitcoin/blob/7f4db9a7c3549a36e45d...
- Sir_Substance 8y ago
  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_Block_Download#Checkpoints https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial... 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 8y ago
    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.
  - tylersmith 8y ago
    They could elect to validate all historic blocks before the UXTO set commitment too if they chose to.

uncletammy 8y ago

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.