5

Please help me understand and distinguish the trust assumptions in the following three cases shown below. Specifically, please elaborate the attacks possible (even though completely theoretical) and trust sacrificed to get the functionality.

Case 1: Bitcoin Core before 0.14 without assumed-valid and where each node does complete signature verification.

Case 2: Bitcoin Core 0.14 with the assumed-valid blocks with signature validation skipped for blocks prior to release. This means that the block signatures are correct because bitcoin-core devs signed on it.

Case 3: (Hypothetical) : Bitcoin Core 0.14 with UTXO set which has the snapshot of UTXO database. This would be done in a similar way as assumed-valid. This would skip the complete IBD and be really useful for quickstart-pruned node.

I would like to know answers to the following 2 questions:

Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.

Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2. It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

4

Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.

None. If there happens to be a fork that makes the assume valid block to no longer be in the longest chain, then you will continue to validate all signatures in the longest chain. If someone were to give you a "fake" blockchain which does not include the assume valid block, you would be doing the same validation process as without the assume valid block. Assume valid does not change the security assumptions as the assume valid block does not need to be in the blockchain unlike was done with checkpoints.

Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2. It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

No, Case 3 has completely different security assumptions from assume valid. You are trusting that the Core developers are providing you the correct UTXO set and by doing so, you are trusting that you will be using the correct blockchain on startup. With assume valid, you are not trusting or assuming that you are using the correct blockchain, you are still validating almost everything. With assume valid, even if the assume valid block is wrong, you can and will still be using the correct blockchain and just doing the same amount of signature validation to be on the correct blockchain as software without assume valid.

  • 4
    About Q1 there is a small difference, if developers (and everyone reviewing the code changes) were to conspire with miners to build a more-work chain with invalid signatures (and go undetected for weeks), and then include it as assumevalid. However, those same people already have that power by just changing the code - which would be much less obvious. – Pieter Wuille Sep 25 '17 at 20:28
  • @PieterWuille, Why can't the same logic be applied to assumed UTXO set? or even in general any form of validation performed by software. If I am trusting the software devs that they don't perform any sort of obfuscation in code, I might as well trust the output of validation. Why is signature-validation such a special form of validation? – sanket1729 Sep 26 '17 at 4:51
  • 2
    If you trust a UTXO set someone gives you, that someone can control what chain you accept, without needing hashpower (though it would be blatantly obvious). -assumevalid's value cannot do that, it can only skip validation if that is effectively the best chain you learn about. – Pieter Wuille Sep 26 '17 at 5:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.