Can an encrypted message for the receiver be created along with a transaction?

[wingding]

I mean an encrypted message that only the receiver of the transaction can read. I know it cannot be done in the current protocol, but can it theoretically be done with a modification of the protocol? I do not mean that such a message should be part of the block chain, it is only necessary for the receiver to catch it.

[1715051780]

1715051780

[1715051780]

1715051780

[1715051780]

1715051780

[1715051780]

1715051780

[achow101]

Of course it is possible. If you change the protocol to include a message that allows you to send arbitrary data to someone and encrypt that with their public key, it is possible to do so. In fact, I think BitMessage already does that.

[CIYAM]

It can be done with the current protocol by using OP_RETURN but the problem is that the length of said message is 80 bytes (so only a very small message which would be best encrypted using an XOR style cypher).

You could also just put the hash of the message in the OP_RETURN part and store the message in some other places (such as cloud storage services). In that way the actual message can be as long as you like.

Note that in either case you'd need a modified wallet to display the message for you.

[wingding]

Let me refine my question: Is it possible to encrypt a message using a btc address, so that only the owner of this address can decrypt it?

Since I suppose the answer is NO, i would in that case ask: Why do bitcoin use a hash of the public key, and not the public key itself for address? The latter would easily allow anyone to encrypt a message only readable for the address owner.

[CIYAM]

It is because a BTC address is the hash of a public key that it isn't much help for creating an encryption key. The usual approach for encrypting messages with EC is to use ECDH to encrypt a message for two key pairs (you need one private and one public key from each pair to create a "shared secret" which you'd use for encrypting/decrypting).

By not announcing the public key until one "moves funds" Bitcoin has built in protection against possible future brute force attacks (which may become feasible with QC or some other tech) that might be able to determine the private key from the public key. Assuming said attack still might take some time (more than one hour say) then it wouldn't matter that the public key was disclosed assuming that the funds were being moved (and the address is not re-used) because after the tx has been confirmed a few times there is no danger.

With address re-use (which is not recommended for the above reason) you would be able to find the public key of a Bitcoin address that has had its funds moved. So if you are looking for a way to find a key pair (in terms of the public keys) you can use a known and already spent Bitcoin address from each party (but still there won't be room to put this message in a Bitcoin tx).

[piotr_n]

Why do bitcoin use a hash of the public key, and not the public key itself for address?

For security and convenience.
Security - because private key is considered more secure when its corresponding public key has not been revealed.
Convenience - because 160 bit address is shorter than 256 bit address.

Mind that early output scripts were in fact public keys, not the hashes.
And the spend script would only contain the signature, not the public key.
Like this one: https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
Later Satoshi changed it, so now output scripts carry the hash of the key while the spend (input) scripts carry the key.
Although, the protocol is backward compatible and the old method also works, had you wanted to use it.
Not sure about the miners willing to include such txs into blocks, though, as they'd probably be considered non-standard.