Yes, I agree that the verification should be in the smart contract itself. But again, the script interacts on-chain, Since it has a native network connection without interacting off-chain.

Thanks for issue!
## lite-client
I agree with the vulnerability that has arisen on the side of the smart-contract. But this is not available on the script side, since data about the validator and its weight are taken from real network configs, since Pytoniq is a Native ADNL with a direct connection to the LiteServer. In addition, it can be noted that the signatures are correctly verified by a real validator:
- node_id_short is calculated for each validator from the official list.
- A signature is accepted only if it matches an existing validator.
And validator weight take from real config. In this case, all checks (new_key_block and check_block) are fully valid.Therefore, the risk of tampering with validator weights is reduced to 0. If something wasn't clear, you can take another look Python script 208-259.
The website says that the text is too big, and I can't double reply)

Hey, thanks for issue!
1. The blocks are checked on the side of the LiteClient. At the Checker, they undergo another inspection before making further checks on transaction_proof.
2. Yes, that's true. We didn't have time to finish this check on smart-contract side. But there is a block_header_proof checking on the script side.
3. I've already answered this question, check out the issue above. I've already answered this question, check out the issue above. In short, we don't need to fully look at the information about the validator in the smart contract, because we have full native verification on the script side and signature forgery is impossible, since the script interacts directly with real network configurations.

Thanks for issue!
Yes, I already answered the question about block_header_proof. In script we use this struct `b'pn\x0b\xc5' + mc_block(or block_id_ext)[0].root_hash + mc_block[(or block_id_ext)0].file_hash` We wanted to add this check, but we didn't have enough time to include it in the script.
To bypass the double-counting verification, we use the verification of each validator in turn. But I agree that this is not the best solution. Again, it all comes down to time :(

Yes, this is an important point, but reread the code and script again. Only after the signatures have been verified by the current validators can the set of validators be updated.

1) Yes, it makes sense, but it's not necessary, as any block not in mс will fall.
2) We check it: `throw_unless(error::invalid_seqno, block_seqno > known_block_seqno)`.
3) Each validator is checked in turn after the other, this prevents the risk of identical validators being used. But I agree that this should be added to the verification.
4) I agree here, I don't understand how I didn't see it before. On the script side, we've done epoch-based processing.In any case, we check the last_seqno, and this does not give the moment of forgery.

Yes, I tested with hardcode data, as there was no time to add normal processing. Everything is working as it should. As for verifying the transaction, just look at the code again. Anyone can send a verification request, the lite-client address is used as the relationship between the contracts.

Thanks for issue! We didn't use any LLM generators. check_merkle_proof is a mistake on my part, which I haven't had time to fix. Yes, we could add more checks, let's say a full check, and not only_weight check, but alas - everything rested on time :(
1) In extract_validators_from_block, we can checked block_slice, if block_slice is failed / invalid, then block_hash is failed.
2) No, we сan checked Signatures and seqno. But yes, load only block_seqno params. If we know trust seqno -> signatures, then send_response.
3) If weight is true, then validators_slice match to signatures_dict. Also we can checked pubkey from validator.
I agree that this code needs to be updated, but errors are not considered problematic, I do not see it possible to compare all the necessary parameters for hacking.