Topic: Method of supporting a "return address"? (Read 1063 times)
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.
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.
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.
Oh yeah, this was on testnet. 
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.
It's not guaranteed that any of the inputs are owned by the user in shared wallet services.
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 (
While we're at it, let's just attach arbitrary data to the transaction.
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?
When sending, it could be in an "advanced options" dialog.
What do you think?
Jump to: