Great work on your implementation!

We noticed a potential issue with signature validation: in your `parse_validator_set` function, you load the weight using `int total_weight = cs~load_uint(64);`, which represents the weight of all validators—not just the masterchain validators. The 2/3 threshold should be based solely on the main validators’ weight. This discrepancy could lead to cases where a block with valid signatures is rejected because the signing weight is less than 2/3 of the total validators’ weight, even though it exceeds 2/3 of the main validators’ weight.

it's impossible to check block signatures on tvm they are signature of a message that is 544 bits the fuction you used will hash the message before verifying (intended for check external messages that are normally hashed in 256bit) so they are two options either you did not test it or you just put it there in case it goes unseen by judges, when i found out about it I dropped the context .

2. Consider an adversarial scenario where a malicious group of current validators publishes a starting key block with an arbitrary next validator set (e.g., reappointing themselves). Since they are the ones signing the block, your contract wouldn't be able to detect this manipulation unless it had stored the next_validators set from the previous transitioning key block. Without this safeguard, the contract state could be corrupted, affecting functionality.

This is why PoS blockchains include a transition period, ensuring the next validator set is known before the current set’s term ends, preventing such attacks.

Looking forward to your thoughts!

Both objections accepted.

Hey! A great work!

Would like to highlight some points.

In `check_validator_signatures` there is no check if given pubkey is used more than once. So having only one valid signature it is possible to achieve any given required weight by repeating it multiple times in `check_block` message. Notice, that in ton-blockchain code you referenced there actualy IS a protection from this issue present -- they track used indices in `seen` variable.

It is possible to make `check_transaction` message with such specific coins amount that gas will be exhausted during lite-client's `check_block`. In this case `transaction-checker` won't receive neither response nor bounce from lite-client, and `g_transactions` will store this pending query record forever and grow storage size over time.

Hey, good work with the bridge. Two areas need extra attention:

1. Not storing the previous validator set makes it impossible to verify transactions in the first key block in an epoch (which is signed by the previous epoch’s validators).

2. No handling for transition periods between validator sets. Without storing the next validator set, the current set could manipulate the next set.

What do you think?

In PoS blockchains, an epoch refers to the time span during which a set of validators is responsible for signing blocks. In the TON blockchain, this is represented by utime_since and utime_until. Each epoch typically has two key blocks:

Starting key block: This is the first key block of an epoch, where the validator set transitions to next_validators. However, this block is still signed by the previous epoch’s validators.

Transitioning key block: This block is generated before the epoch ends. The validator set remains unchanged, but the next_validators set is defined for the upcoming epoch.

1. Can your code verify transactions in a starting key block? Since the validator set has already changed in the contract and "transactions in a new keyblock are still signed with the previous validator set", verification would require access to the previous validator set (or not checking the signatures at all and checking the seqno, since the block is already verified).

Implemented basic functionality with a few security issues: no max_main_validators logic, no signature deduplication, no global_id checks(minor), prev_key_block is substituted with set hash check (ok). Proper tx checker.

More info on issues: https://contest.com/docs/TrustlessBridgeChallengeAssessment