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.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments