Staking transactions are not enforced to be to / from the staking contract

[danimoh]

verify of Transaction currently checks that the Staking sender / recipient type must be set, if the the sender / recipient address is the staking contract, but does not enforce that the sender / recipient must be the staking contract, if the sender / recipient sender type is Staking.
Verification of the sender / recipient data, and potentially later processing of the data, are solely based on the sender / recipient type though.
Thus, it might be possible to, for example, send a transaction that is interpreted as a staking transaction, via the Staking sender / recipient type, which is not in fact to / from the staking contract.

core-rs-albatross/primitives/transaction/src/lib.rs

Lines 337 to 349 in bf6bab5

	if self.recipient == Policy::STAKING_CONTRACT_ADDRESS
	&& self.recipient_type != AccountType::Staking
	{
	return Err(TransactionError::InvalidForRecipient);
	}
	// Should not be necessary as the sender would have to sign the transaction
	// and the private key for the staking contract is unknown
	if self.sender == Policy::STAKING_CONTRACT_ADDRESS
	&& self.sender_type != AccountType::Staking
	{
	return Err(TransactionError::InvalidForSender);
	}

PS: I did not confirm the issue on-chain, just filing this issue based on reading the code.

[styppo]

There is a check here that the target account has the correct type when applying the transaction, so a transaction with an invalid sender/recipient type would not be accepted. We could however add an additional check to the intrinsic transaction verification to reject such transactions early, i.e. before attempting to apply them.

[sisou]

With the existing check, the transaction can still enter the mempool I guess? But then not get accepted into block, so filling up the mempool?