Is it possible to add a receive address in an OP_RETURN transaction?

[nextblast]

Hi! I've known Btc for a while now, but just recently I find myself want to dig in some "technic" aspects of this amazing system.
Recently I heard of a website http://coinsecrets.org/, which is extremely interesting.

In the website I saw many tx with OP_RETURN script.
In Blockchain.info, those transactions shows output address "Unable to decode output address".

I would like to know if it's possible to add an output public address, while still using OP_RETURN script.
Is it due to the protocol that they cannot add an output address, or they just don't want have output address added.

I guess it might be due to the protocol, but its just a guess. Anyone knows? Thanks!

[amaclin]

You can add any data (no more than 40 bytes afaik) to OP_RETURN output script.
Of course, you can put an address there.
Or encrypted private key
Or a short message (encrypted or not) to somebody.

You (to be correct: your partner) should have a "decode tool" which parses data in OP_RETURN output and understands its meaning.

[nextblast]

You can add any data (no more than 40 bytes afaik) to OP_RETURN output script.
Of course, you can put an address there.
Or encrypted private key
Or a short message (encrypted or not) to somebody.

You (to be correct: your partner) should have a "decode tool" which parses data in OP_RETURN output and understands its meaning.

Thanks for your answer amaclin!
I'm still kind of confused. Pardon me for not being enough clear.

If I want to fully utilize the 40 bytes of OP_RETURN, not to store the output/recipient's public address there.
And at the mean time, still have that output address (or my partner's address) as normal output address in ordinary transactions, is that possible?

To illustrate:
Me ----- Tx ----> Bob
Where, Tx includes:
i. My address (or, the "from" address, sure it's there).
ii.  tx fee of 0.0001btc (sure it's there too).
iii. The payload of the tx -- any amount of btc sent by me which not be received by bob, right?
iv. Bob's address (or, the "to" address, ? Possible ? ).
v. 40 bytes of other information in OP_RETURN, not related to Bob's address.

i,ii,iii,iv parts should be in any ordinary tx body.
I'm wondering if I have the OP_RETURN part, is iv. part (the "to address") can still be there

Thanks~

[amaclin]

i. My address (or, the "from" address, sure it's there).
ii.  tx fee of 0.0001btc (sure it's there too).

Seems to me that you do not understand correctly what are transactions itself, their inputs, outputs...
In fact, there can be many "from" addresses in transaction.
And usually there are more than one "to" address. One is Bobs, the second is change to yourself.

Sorry, it is difficult for me to explain bitcoin basics here. English is not my native language.

iv. Bob's address (or, the "to" address, ? Possible ? ).
v. 40 bytes of other information in OP_RETURN, not related to Bob's address.
I'm wondering if I have the OP_RETURN part, is iv. part (the "to address") can still be there

In two words:
Yes, you can add 40 bytes to your transaction. These bytes will be visible for everybody. What can one do with them - it is up to you.

[nextblast]

i. My address (or, the "from" address, sure it's there).
ii.  tx fee of 0.0001btc (sure it's there too).

Seems to me that you do not understand correctly what are transactions itself, their inputs, outputs...
In fact, there can be many "from" addresses in transaction.
And usually there are more than one "to" address. One is Bobs, the second is change to yourself.

Sorry, it is difficult for me to explain bitcoin basics here. English is not my native language.

iv. Bob's address (or, the "to" address, ? Possible ? ).
v. 40 bytes of other information in OP_RETURN, not related to Bob's address.
I'm wondering if I have the OP_RETURN part, is iv. part (the "to address") can still be there

In two words:
Yes, you can add 40 bytes to your transaction. These bytes will be visible for everybody. What can one do with them - it is up to you.

I understand that a tx can be like a m:n relation, and by default the "change" will be sent to a new address automatically generated in my QT wallet.

I heard normally if I attach a msg in a tx, it will not go to the blockchain. But by using OP_RETURN, it can be stored in blockchain.
Like this http://bitcoin.stackexchange.com/questions/19893/how-to-send-bitcoin-with-a-message-attached

So, If Alice were to send a message "love" to Bob.
The "from addr" is Alice's pub key, and the "to addr" is Bob's pub key, and OP_RETURN contains "love".

Is that ok, or you have to contain both Bob's pub key and the "love" message in the script, and left the "to addr"  unfilled.
Or in the worst scenario, even if "to addr" is filled with Bob's pub key, it still says "Unable to decode output address" on the blockchain...

I think your answer is yes. That answers my doubt   
Thanks again, amaclin!
I appreciate it you take your time to answer...

BTW, English is not my native language too. It's fascinating to communicate accross the borders here.

[amaclin]

Or in the worst scenario, even if "to addr" is filled with Bob's pub key, it still says "Unable to decode output address" on the blockchain...

No.
From the Bobs view:

(appearing bubble message from bitcoin client)
Wow! someone send me coins!
OK, I received 1 btc. But who sent it? I do not know. May be Alice? Only she knows my address.
I want to do some investigation... Hmm...
Strange transaction... It has several inputs and three outputs...
First output is to me (I am Bob, I know my address).
Second output is some small value... It is Alices change! But I am not sure yet that it is Alice
And third output is very strange... bc.i site can not parse it... Let me do it manually...
Wow! It is OP_RETURN script with some data attached.
May be it is plain text? Hmmm... No.
May be it is BASE64? Yes!
Decoding... Decoding... Got the message! The message is "Wonder who I am?"

[nextblast]

Or in the worst scenario, even if "to addr" is filled with Bob's pub key, it still says "Unable to decode output address" on the blockchain...

No.
From the Bobs view:

(appearing bubble message from bitcoin client)
Wow! someone send me coins!
OK, I received 1 btc. But who sent it? I do not know. May be Alice? Only she knows my address.
I want to do some investigation... Hmm...
Strange transaction... It has several inputs and three outputs...
First output is to me (I am Bob, I know my address).
Second output is some small value... It is Alices change! But I am not sure yet that it is Alice
And third output is very strange... bc.i site can not parse it... Let me do it manually...
Wow! It is OP_RETURN script with some data attached.
May be it is plain text? Hmmm... No.
May be it is BASE64? Yes!
Decoding... Decoding... Got the message! The message is "Wonder who I am?"

LOL  

[bitcats]

From the Bobs view:

(appearing bubble message from bitcoin client)
Wow! someone send me coins!
OK, I received 1 btc. But who sent it? I do not know. May be Alice? Only she knows my address.
I want to do some investigation... Hmm...
Strange transaction... It has several inputs and three outputs...
First output is to me (I am Bob, I know my address).
Second output is some small value... It is Alices change! But I am not sure yet that it is Alice
And third output is very strange... bc.i site can not parse it... Let me do it manually...
Wow! It is OP_RETURN script with some data attached.
May be it is plain text? Hmmm... No.
May be it is BASE64? Yes!
Decoding... Decoding... Got the message! The message is "Wonder who I am?"

LOL²  

[dabura667]

i,ii,iii,iv parts should be in any ordinary tx body.
I'm wondering if I have the OP_RETURN part, is iv. part (the "to address") can still be there

Thanks~

I think you and amaclin are misunderstanding each other.

You mean that you want the output to send bitcoin to an address while at the same time storing 40 bytes of data?

In that case, no. That would be non-standard.

In order to place 40 bytes on a transaction, you are placing "OP_RETURN: 40 bytes of data here" in the place where you would normally put "To: Alice's address"... this is why blockchain.info says "Can't Decode."

Because blockchain.info expects the output to have a bitcoin address in it, but instead there's a "OP_RETURN: data data data" written there, so blockchain.info says "Can't decode"

[amaclin]

I think you and amaclin are misunderstanding each other.

May be. My English is not so perfect, as my bitcoin knowledge  

You mean that you want the output to send bitcoin to an address while at the same time storing 40 bytes of data?
In that case, no. That would be non-standard.

I think that OP does not want to include 40 bytes in the output script to Bob, but in transaction to Bob. Or to Alice?

It is possible to create non-standard output script
for example instead of
OP_DUP OP_HASH160 <Bobs address hash> OP_EQUALVERIFY OP_CHECKSIG
Alice can create the script:
<push bytes "Hello, Bob, I love you!"> OP_DROP OP_DUP OP_HASH160 <Bobs address hash> OP_EQUALVERIFY OP_CHECKSIG

Eligius pool will mine this transaction.
Bob will be able to spend coins [with advanced client software] [to Charley]
bc.info will show this output as non-standard (unknown "to" address in Alice history and unknown "from" address in Bobs page)

[nextblast]

i,ii,iii,iv parts should be in any ordinary tx body.
I'm wondering if I have the OP_RETURN part, is iv. part (the "to address") can still be there

Thanks~

I think you and amaclin are misunderstanding each other.

You mean that you want the output to send bitcoin to an address while at the same time storing 40 bytes of data?

In that case, no. That would be non-standard.

In order to place 40 bytes on a transaction, you are placing "OP_RETURN: 40 bytes of data here" in the place where you would normally put "To: Alice's address"... this is why blockchain.info says "Can't Decode."

Because blockchain.info expects the output to have a bitcoin address in it, but instead there's a "OP_RETURN: data data data" written there, so blockchain.info says "Can't decode"

Ha!  

that's exactly what I am asking and suspecting, thanks dabura667 !
Last night I also googled a related info:
http://bitcoin.stackexchange.com/questions/19703/does-proof-of-existence-lose-bitcoins

The transaction encoding the document hash looks exactly like any other normal pay-to-address transaction. The only difference is the address which is a representation of the document hash instead of a hashed public key, and therefore there is no private key associated with it (that's why it is unspendable).

Maybe by specifically adding an extra "To addr" can achieve that both Alice and Bob's address appear in the blockchain?

(From: Alice) ---TX--->(To addr1: Bob; To addr2: OP_return Can't decode)

[hhanh00]

What the article means to say is that the address is a convenient display of the public key hash.
In a transaction with OP_RETURN, there is no way to redeem the coins and there is no public key at all.
That's why blockchain info display "cannot decode address".
They know how to decode two standard scripts: Pay2Pub and Pay2PubHash. The later is used more than 99% of the time.

Amaclin suggests to combine a standard p2ph output that can be decoded by bc.i and an OP_RETURN were you would store your extra info but you can't use a single outpout because it wouldn't be a standard script anymore.

Of course, it is a matter of agreement and you could push for a new type of standard script.