RE: HOWTO Verify Messages Between JavaScript and Java with a Graphene KeyPair

there are many cases actually, for example if the data is not encrypted (ie. http versus https), or if packets are sent via email. and while it may be less likely to happen on an encrypted site, why risk leaving such a large potential attack vector open?

As such, the graphene blockchain takes it to a whole other level than even what I've described. If you'd like a better understanding of how STEEM validates transactions, @xeroc does a great job in explaining it in his post, "Steem transaction signing in a nutshell":

We notice that our operation is now part of the transaction (as part of the operations array) and that we now have a field for our signatures and an expiration. The expiration allows for transactions to expire if they are not included into a block by that time. Usually that date is about 30 seconds in the future.

Let's discuss the ref_block_* parameters a little: The ref_block_num indicates a particular block in the past by referring to the block number which has this number as the last two bytes. The ref_block_prefix on the other hand is obtain from the block id of that particular reference block.

The purpose of these two parameters is to prevent replay attacks in the case of a fork. Once two chains have forked, the two parameters identify two different blocks. Applying a signed transaction of one chain at another chain will invalidate the signature.