Method of supporting a "return address"?

[BitterTea]

There could be a field in the transaction header, an index to a specific input, that when optionally set indicated to the receiver which address funds should be returned to if necessary.

When sending, it could be in an "advanced options" dialog.

What do you think?

[1715030747]

1715030747

[1715030747]

1715030747

[1715030747]

1715030747

[1715030747]

1715030747

[1715030747]

1715030747

[1715030747]

1715030747

[error]

While we're at it, let's just attach arbitrary data to the transaction.

[BitterTea]

While we're at it, let's just attach arbitrary data to the transaction.

You already can, and Gavin has proposed testing a new transaction type (<bytes> OP_DROP OP_DROP ...) that would also do just that. This is a single, optional, what... variable sized integer? I don't see a problem, and it could be very useful. Services like MyBitcoin could use it to ensure people don't send money back to the wrong address. I just got bit by something similar on testnet. I generated a bunch of coins, then sent them to BitcoinJ's PingService example, which accepts coins and returns them to the first input's address. I think it sent them back to one of the generated addresses, and now I don't see it in my wallet.

[Mike Hearn]

Treat BitCoinJ as experimental ... don't put coins into it you can't afford to lose.

It's not guaranteed that any of the inputs are owned by the user in shared wallet services.

[BitterTea]

Oh yeah, this was on testnet.

[Gavin Andresen]

I was actually thinking a return address would be a good use for the arbitrary-message-to-receiver OP_DROP transaction type.

Maybe make a convention that bytes be a JSON dictionary, so it could be:

{'return_address':'n2cGZYsiii1uAiDPM6ipPBqqXa4Z9bXh2t'} OP_DROP ...etc...

... which would be inefficient (58 bytes to encode the 20-byte return address) but wonderfully extensible.

And again:  I'd like to see experimentation on testnet.

[Mike Hearn]

If there's going to be arbitrary data in transactions like that (is it really needed to open this pandoras box?) it'd be better to just use the bitcoin packing format with tag:data pairs, or protobufs, rather than JSON. No need to make it inefficient if it's unnecessary.