Order ID in a new transaction type?

[Gavin Andresen]

So I got email today from a merchant asking the most-frequently-asked question:  if I just put a bitcoin address on my "pay me" page, how do I know who paid me?

Which got me to wondering... can we do better than answer "run a bitcoin daemon and ask it for a new address for every order"  or  "use a shopping cart interface from your online wallet provider" ?

Ideally, the web software could generate a payment URI without talking to bitcoind, and copying/pasting or clicking on the URI would generate a transaction tagged with the right order ID.

Adding another transaction type that allows (say) an extra, arbitrary 512 bytes of data mostly solves the problem; the web software could encrypt or hash the order ID and generate a transaction that is the store's public bitcoin address and the encrypted/hashed order ID (or customer number or whatever).

Can we do better?  It would be nice if it was impossible to tell how many orders the merchant was getting...

[1714951273]

1714951273

[1714951273]

1714951273

[1714951273]

1714951273

[1714951273]

1714951273

[1714951273]

1714951273

[Matt Corallo]

It is more complicated to implement but what about signing the order id with the bitcoin private key and sending that.  It could be easily checked on the server side, but this is a larger question of do we really want to use the bitcoin private keys for other signing?

[Gavin Andresen]

It is more complicated to implement but what about signing the order id with the bitcoin private key and sending that.  It could be easily checked on the server side, but this is a larger question of do we really want to use the bitcoin private keys for other signing?

The web server doesn't have the bitcoin private key, and the problem I'm trying to solve is an order process where the web server doesn't have to communicate with bitcoin at all to generate the "pay me" address/link.

[genjix]

Do you want me to setup a site which accepts payments for people? It's a very easy thing to setup & release code.

i.e

Merchant signs up with me.
Their merchant site redirects the user to a link like ?merchant=mymerchant.
You login to my site using OpenID and it gives you an address to send BTC to.
Merchant can query me to get their balance or I push the balance to them or something.

But is this really any better than just using accounts or using mybitcoin? I don't think so.

[theymos]

If IP transfers were made secure, a message could be sent directly.

[Matt Corallo]

It is more complicated to implement but what about signing the order id with the bitcoin private key and sending that.  It could be easily checked on the server side, but this is a larger question of do we really want to use the bitcoin private keys for other signing?

The web server doesn't have the bitcoin private key, and the problem I'm trying to solve is an order process where the web server doesn't have to communicate with bitcoin at all to generate the "pay me" address/link.

I meant the client signs a order id with their bitcoin key and sends that to the web server.  Then the server can know for sure who the address is (or what they are paying).

[jgarzik]

If this data is stored in the block chain, it reawakens the entire BitDNS/BitX debate.

512 bytes of blank data space in the chain just makes it trivial for non-currency users to use bitcoin for its generic data broadcasting services...

[Pieter Wuille]

So I got email today from a merchant asking the most-frequently-asked question:  if I just put a bitcoin address on my "pay me" page, how do I know who paid me?

Which got me to wondering... can we do better than answer "run a bitcoin daemon and ask it for a new address for every order"  or  "use a shopping cart interface from your online wallet provider" ?

Ideally, the web software could generate a payment URI without talking to bitcoind, and copying/pasting or clicking on the URI would generate a transaction tagged with the right order ID.

Adding another transaction type that allows (say) an extra, arbitrary 512 bytes of data mostly solves the problem; the web software could encrypt or hash the order ID and generate a transaction that is the store's public bitcoin address and the encrypted/hashed order ID (or customer number or whatever).

I don't think you need another transaction type for this, see https://en.bitcoin.it/wiki/Script#Transaction_with_a_message.
You do need support in the client to add a message (just some random byte sequence in some encoded format, maybe prefixed with a marker and a suffixed with checksum to allow easy regcongition without fully parsing the script) to a transaction. Ideally, it would also be possible to have bitcoin: URI with such a string, so transactions created by clicking such a link automatically have it.

Can we do better?  It would be nice if it was impossible to tell how many orders the merchant was getting...

I doubt a better solution than still using (some) separate addresses is possible for this.

[Matt Corallo]

Do you want me to setup a site which accepts payments for people? It's a very easy thing to setup & release code.

i.e

Merchant signs up with me.
Their merchant site redirects the user to a link like ?merchant=mymerchant.
You login to my site using OpenID and it gives you an address to send BTC to.
Merchant can query me to get their balance or I push the balance to them or something.

But is this really any better than just using accounts or using mybitcoin? I don't think so.

I think this is the ultimate future for the accepting of bitcoin in the mainstream.  Most people don't even want to write their own commerce software backend anyway (neither should they for security reasons, etc).

[jgarzik]

Also, I think it is a bad idea for most merchants to run a local bitcoind node.  That implies they will need to know a good deal about P2P networking, in order to defend their installation against attacks.  You have to track bitcoin software closely for security updates, that sort of thing.

That's just not realistic for most merchants, IMO.

We should be directing most merchants to APIs such as mybitcoin.com's SCI or mtgox.com's merchant API.

And they can provide an order id (I think MBC does already?) through those Web APIs.

[genjix]

OK, I misunderstood the OP.

Why not just change the wallet format. Instead of having a flat directory of accounts containing addresses, instead you have a tree of containers. Each container can hold either a) addresses and b) other containers.

This way you could assign an address for a transaction like:

getaccountaddress genjix.order26

getbalance genjix  (balance from genjix genjix.order23 genjix.order26 ...)
getbalance genjix.order26

[Matt Corallo]

OK, I misunderstood the OP.

Why not just change the wallet format. Instead of having a flat directory of accounts containing addresses, instead you have a tree of containers. Each container can hold either a) addresses and b) other containers.

This way you could assign an address for a transaction like:

getaccountaddress genjix.order26

getbalance genjix  (balance from genjix genjix.order23 genjix.order26 ...)
getbalance genjix.order26

I believe gavin meant for sites to not have to run their own bitcoind nodes or handle addresses on the web end. 

[theymos]

Using a single publicly-posted address might have security problems. From the paper:

The receiver generates a new key pair and gives the public key to the sender shortly before
signing.  This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment.

[carp]

It is more complicated to implement but what about signing the order id with the bitcoin private key and sending that.  It could be easily checked on the server side, but this is a larger question of do we really want to use the bitcoin private keys for other signing?

The web server doesn't have the bitcoin private key, and the problem I'm trying to solve is an order process where the web server doesn't have to communicate with bitcoin at all to generate the "pay me" address/link.

I was giving this exact problem some thought recently. My question is, how simple of a merchant site do you want to support? If the system is going to be handing out local transaction ids, then it has to generate them right?

The conclusion that I came to is that this can already be done. If you have to track orders anyway, then, why not pre-gen a number of addresses, and give the webapp a bulk load of them. Then, with each transaction, it marks each one as used, and ads it to tracking.... no bitcoin client needed until it is time to re-up the addresses.... which can be a manual process, or could be automated in some way.

[phantomcircuit]

Why not just have clients tell the server the tx hash?

[Syke]

Also, I think it is a bad idea for most merchants to run a local bitcoind node.  That implies they will need to know a good deal about P2P networking, in order to defend their installation against attacks.  You have to track bitcoin software closely for security updates, that sort of thing.

They're going to have to have bitcoind running somewhere if they want to use the coins they were sent.

We should be directing most merchants to APIs such as mybitcoin.com's SCI or mtgox.com's merchant API.

And they can provide an order id (I think MBC does already?) through those Web APIs.

That just defeats the purpose of a peer-to-peer currency. Those merchants might as well just use any number of centrally controlled ecurrencies.

[Matt Corallo]

Why not just have clients tell the server the tx hash?

Because I could find someone who sent a tx to pay a minute ago and claim it was my tx.

[Matt Corallo]

Also, I think it is a bad idea for most merchants to run a local bitcoind node.  That implies they will need to know a good deal about P2P networking, in order to defend their installation against attacks.  You have to track bitcoin software closely for security updates, that sort of thing.

They're going to have to have bitcoind running somewhere if they want to use the coins they were sent.

Not necessarily, if they use mtgox they can imidiatley transfer the BTC into USD or on mybitcoin, they can just transfer them to another site which gives them USD, EUR, etc.  They never need to touch a bitcon client (unless you count mybitcoin). 

We should be directing most merchants to APIs such as mybitcoin.com's SCI or mtgox.com's merchant API.

And they can provide an order id (I think MBC does already?) through those Web APIs.

That just defeats the purpose of a peer-to-peer currency. Those merchants might as well just use any number of centrally controlled ecurrencies.

Who cares?  In the end virtually no on but geeks care how centralized or decentralized a currency is as long as there is mainstream acceptance.

[Stefan Thomas]

512 bytes of blank data space in the chain just makes it trivial for non-currency users to use bitcoin for its generic data broadcasting services...

I can already encode 512 bytes of data in my transaction using crafted recipient addresses.

So the question isn't "Should we allow it?" but rather "Should it be done by requiring people to encode it in addresses or by adding a message field?"

I'm in favor of allowing more data in transactions as long as the fee closely depends on the amount of data somebody wants to send around.

[randomguy7]

How can you create a special recipient address? Isn't the address basically a public key (which should not allow to simply craft specific keys). Which algo is used for the asym. encryption btw?