9

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.

Improve this question
0

1 Answer 1

Reset to default
6

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.

Improve this answer
5
  • 7
    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, 2017 at 20:28
  • 1
    @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, 2017 at 4:51
  • 4
    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, 2017 at 5:59
  • @PieterWuille I still don't think that fully answers sanket's question. If you trust a UTXO set that comes from the same source as your bitcoin software, its no different than simply trusting that software. As you pointed out, the developers already have the power to put a malicious binary out there that follows the wrong chain. If you are fully auditing the software yourself, that should include fully auditing the UTXO set. I don't see any difference in security profile.
    – B T
    May 25, 2019 at 2:04
  • This is a related discussion, and I'd appreciate your input: reddit.com/r/BitcoinDiscussion/comments/bskw25/…
    – B T
    May 25, 2019 at 2:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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