Now, after having filled my target address B and amount of BTC in the "send" field of my client software, I am able to compose a message (=free text, like an SMS) and the client will encrypt this message with the public key of B (i.e. with the destination address) in the way that normally emails are encrypted with PGP public key mechanisms.
Bitcoin addresses are not public keys-- they are hashes of public keys (RIPE-MD-160 hash of the SHA256 hash of the public key, with a version number and checksum, to be annoyingly specific).
I agree that associating a message with a bitcoin transaction would be spiffy.
Oh, well I'm not an expert, just know some basics of priv/pub encr like PGP (GPG) at the level of Phil Zimmermann's
Intro to Crypto.
So does this mean that my idea cannot work because only the hashes (or hashes' hashes) of the public keys (=Bitcoin addresses) and not the public keys themselves are actually publicly known in the Bitcoin world??
If so, I would be a little surprised because I always thought that whenever the bitcoin nodes ("miners") want to verify the validity of a BTC transaction's signature, they need to know the corresponding public key (and not only its hash's hash) to perform this check. But then the public key (and not only its hash's hash) is available to the clients, too, and the "SMS-service" could work as described above, couldn't it?
If really only the hashes' hashes are publicly known in today's Bitcoin universe, then the public key could be uploaded by the transmitting client to the SMS server to a public data base (=lookup table: "public key A's hash's hash" --> "public key A itself") and the mechanism could then work as described in my original post, couldn't it?