Bitcoin Transactions with Auto-Response Return Address

[JPage]

   Since bitcoin transactions can in special cases include a very small data payload, it is possible to include a sender's 'return address'.  When the sender of bitcoin is a customer in an e-commerce sale, the merchant can instantly deliver goods and services via this 'return address'.
   Bitcoin users can achieve single-click buying from a bitcoin client having a user profile with a default delivery address encoded therein.  Bitcoin transactions are formed at the client with the delivery address included as a tiny data payload.  Merchants 'see' their bitcoin payments directly on the blockchain and effect delivery by parsing a return address from the blockchain and dispatching goods or service to the customer by way of the address.
   While having the remarkable advantage of single click shopping from a bitcoin client, it additionally has the great benefit of enabling shopping directly from a printed poster - rather than a website.  A simple QR code scan from an advertisement poster results in delivery of goods and service - without having to visit an e-commerce checkout page.
   More details can be viewed in this whitepaper: Bitcoin Transactions with Auto-Response Return Address.
   Maybe we should kick this around here before we make a new BIP.  Do you have any comments?

[TimS]

How do you propose the shipping address, etc. be encrypted in the blockchain? ECDSA, as used in Bitcoin currently, is only for signing data, not encrypting something that can later be decrypted. You might include an RSA public key in the poster, and encrypt with that.
Including this encrypted data could easily bloat the message to the point that a larger transaction fee is required (not to mention bloating the blockchain). And you have to be online to broadcast your transaction to the network, anyway, so I'm not sure why "enabling shopping directly from a printed poster" is a big deal. I'm not sure this gives you much over BIP 0070. And I'm ok with having the website validate that it understands my details before paying it for its goods/services.

[JPage]

How do you propose the shipping address, etc. be encrypted in the blockchain? ECDSA, as used in Bitcoin currently, is only for signing data, not encrypting something that can later be decrypted. You might include an RSA public key in the poster, and encrypt with that.
Including this encrypted data could easily bloat the message to the point that a larger transaction fee is required (not to mention bloating the blockchain). And you have to be online to broadcast your transaction to the network, anyway, so I'm not sure why "enabling shopping directly from a printed poster" is a big deal. I'm not sure this gives you much over BIP 0070. And I'm ok with having the website validate that it understands my details before paying it for its goods/services.

Shopping via any new medium should be interesting to retailers where every sales channel is money in the bank. 

There are many forms of encryption which work well.  Even plain text is doable - for some users.  Blockchain bloat is a big problem because of activity like Satoshi Dice - but OP_Return is prunable.  Data carried as an OP_Return field doesn't load up the blockchain. 

You do have to be on-line, but the merchant doesn't.  A merchant can have a QR code on a poster with the latest Nike shoes - and passers-by can have them delivered to their house tomorrow with just one click. 

Besides, the 'shop from poster' idea isn't nearly as important as the 'single-click' shopping (a la Amazon) from web stores.  Have another look at the whitepaper. 

[DeathAndTaxes]

OP_RETURN is limited to 40 bytes.  That is good for a txn return bitcoin address but not much more.  Certainly not enough to shop from a poster or do entire order and delivery processing on blockchain.

[JPage]

OP_RETURN is limited to 40 bytes.  That is good for a txn return bitcoin address but not much more.  Certainly not enough to shop from a poster or do entire order and delivery processing on blockchain.

Fruebjergvej 3
DK-2100 Kobenhavn
DENMARK

is 40 bytes.  

patty@gmx(dot)com  is far less than 40 bytes.  email is a really good mode for delivery of electronic goods and services like concert tickets.

These examples could make great return addresses for such system.  Merchants can arrange their QR codes to correspond to product selection choices such as size/color.  

There are some really nice abbreviations available too.  For example:
"901 Market Street, Philadelphia, Pennsylvania  19107" is really equal to: "901MarketSt 19107"
"Fruebjergvej 3 DK-2100 Kobenhavn DENMARK" is "Fruebjergvej3DK2100"


Amazon's single click system makes shopping REALLY easy - especially impulse shopping.  Bitcoin users can enjoy the same functionality.  I think this will further help to bring bitcoin into common use in commerce.

Although I agree 40 bytes is a severe limit.  I think the core devs could be convinced to bring that back up to 80 where it started.  Those data are 100% prunable so it doesn't technically upset the blockchain much.  

[DeathAndTaxes]

Sure some addresses will be less than 40 bytes but 100% of addresses in 100% of the cases?  So how does a merchant handle a bad delivery address?  Just mail it to a known bad address and hope it works?  A standard which can only handle a subset of possible values isn't a very good standard.

[JPage]

Sure some addresses will be less than 40 bytes but 100% of addresses in 100% of the cases?  So how does a merchant handle a bad delivery address?  Just mail it to a known bad address and hope it works?  A standard which can only handle a subset of possible values isn't a very good standard.

The customer sets up his bitcoin client until its validation can confirm a valid less than 40 byte address is possible. 

To be honest, I imagine OP_RETURN should be revised to 80 bytes once further demand for it is generated.  In an extreme case, the proposed system can just do like CounterParty and Mastercoin and shove additional data into things like MultiSig and other parts of the transaction or create 'unspendable outputs' to provide for greater data payloads.  However, this is to be despised and avoided at all cost.  An 80 byte OP_Return might be a best approach.

Another approach which has more overhead has a reference in OP_Return and an off blockchain look-up table carries the full customer address information.

I wonder if anyone has other possible solutions? 

[Envrin]

Just an off-the-cuff reply, as I haven't given this much thought.

Maybe contact the developer(s) of BitID (or another OAuth type solution), and see if you can work together, and get something integrated?  Then instead of including the full shipping address & customer details in the blockchain each time, you only need that public key / identifier.  Keeps it under the 40 byte limit in 100% of the cases, plus helps on the security side of things, as full contact info isn't being added to the blockchain.

[JPage]

Just an off-the-cuff reply, as I haven't given this much thought.

Maybe contact the developer(s) of BitID (or another OAuth type solution), and see if you can work together, and get something integrated?  Then instead of including the full shipping address & customer details in the blockchain each time, you only need that public key / identifier.  Keeps it under the 40 byte limit in 100% of the cases, plus helps on the security side of things, as full contact info isn't being added to the blockchain.

True.  We've been working on a registry which accomplishes this feature.  A simple unique identifier is sent with the transaction and registered merchants can 'look up' the postal address in a table available to authorized merchants for that purpose.  Keeps the blockchain very clean and tidy - which of course is a primary concern.