|
Title: Method of supporting a "return address"? Post by: BitterTea on May 04, 2011, 03:03:26 PM 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? Title: Re: Method of supporting a "return address"? Post by: error on May 04, 2011, 03:06:13 PM While we're at it, let's just attach arbitrary data to the transaction.
Title: Re: Method of supporting a "return address"? Post by: BitterTea on May 04, 2011, 03:09:41 PM 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. Title: Re: Method of supporting a "return address"? Post by: Mike Hearn on May 04, 2011, 03:17:38 PM 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. Title: Re: Method of supporting a "return address"? Post by: BitterTea on May 04, 2011, 03:19:17 PM Oh yeah, this was on testnet. :)
Title: Re: Method of supporting a "return address"? Post by: Gavin Andresen on May 04, 2011, 05:39:17 PM 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. Title: Re: Method of supporting a "return address"? Post by: Mike Hearn on May 04, 2011, 06:04:35 PM 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.
|