A full node has a local database of current IOTA balances (which gets initialized from the latest Snapshot and then updated by confirmed transactions). When the full node performs its validation of a transaction bundle, it will verify that the balances of the spending transactions do not exceed the amounts stored in its database. This is done sequentially so ...
Short answer: it is not.
Long answer: Signatures are not supposed to protect anything else than the iota values and (obsolete)tag fields. Therefore, as long as your transaction is not confirmed, anybody could replay/reattach it with a different content in the message field of the receiving transaction and the luckiest transaction would win.
Therefore, you ...
You can generate your address with the option checksum: true . It will give you a 90 characters address where last 9 chars are the checksum.
Before attaching this address to the tangle you can use the function
Utils.isValidChecksum(<90 chars address>)
to check that your address is valid.
It seems like what you want to avoid is the risk that your funds will "end up somewhere which isn't in my control."
send only a small amount of IOTA or even a zero value transaction of the address
check if you see the transaction in your wallet
send the rest of your IOTA
Although this would work, it shouldn't really be an issue, if you generated the address with a tool that works like the official IOTA light wallet or any of the official IOTA libraries from iotaledger ...
If I'm not remembering wrong, when a discrepancy is detected the node runs again the MCMC algorithm and chooses two other tips.
The inconsistent tips will remain on the tangle.
The growth of the tangle will (hopefully) confirm only one of the two tips, the other will be on an orphaned branch and will never be confirmed.
It's not included in the bundle hash, but it is included in the transaction hash. If you look into how MAM does it, the message fragment contains the message, signature, and sibling hashes( for merkle root calculation ), all encoded into the message field.
The message is not 'validated' because any tx with positive value needs no signature, but the tx hash ...
The problem here is, we can't prove, if the timestamp is correct or not.
Setting the timestamp back to 01.01.1900:
Case 1: The node is honest and rejects the transaction, because the timestamp is not correctly dated -> everything is good
Case 2: The node is NOT honest and distributes the transaction further.
Now other nodes have no way of knowing, if the ...
This blog explains exactly the main concern here reported:
Section: "Doublespending in IOTA"
Basically, the increasing number of hosts also increase the difficulty to perform such attack, due to you need to get "an “omnipresence in the tangle with “bad” nodes, formed as a sub ...
By verifying a transaction that is invalid, a transaction itself becomes invalid and will never be verified by other honest transactions (i.e. the transaction is on an "invalid path" that others do not recognize so its X Iotas are worthless).
What happens next?
Nothing. The transaction that happens to verify an invalid one will never be confirmed.
There are two ways I can think of to verify a (the orange) transaction.
1. With the Coordinator
If you don't know how IOTA transactions are confirmed by the coordinator, check out
How exactly are transactions verified and confirmed in IOTA
You get all information about the old Tangle through thetangle.org (or any other provider) ...
The C# port is not up to date as it (still) uses the old CURL hashing function (used until beginning of August 2017).