Bitcoin Forum
December 04, 2016, 10:30:19 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Method of supporting a "return address"?  (Read 856 times)
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 04, 2011, 03:03:26 PM
 #1

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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480847419
Hero Member
*
Offline Offline

Posts: 1480847419

View Profile Personal Message (Offline)

Ignore
1480847419
Reply with quote  #2

1480847419
Report to moderator
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 04, 2011, 03:06:13 PM
 #2

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 04, 2011, 03:09:41 PM
 #3

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
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 04, 2011, 03:17:38 PM
 #4

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
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 04, 2011, 03:19:17 PM
 #5

Oh yeah, this was on testnet. Smiley
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 04, 2011, 05:39:17 PM
 #6

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.

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 04, 2011, 06:04:35 PM
 #7

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!