Order ID in a new transaction type? - page 3.

carp

member

Activity: 82

Merit: 10

Quote from: Gavin Andresen on March 14, 2011, 05:24:16 PM

Quote from: Matt Corallo on March 14, 2011, 05:19:16 PM

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.

theymos

administrator

Activity: 5166

Merit: 12850

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

Quote

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.

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: genjix on March 14, 2011, 05:38:16 PM

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.

genjix

legendary

Activity: 1232

Merit: 1076

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

jgarzik

legendary

Activity: 1596

Merit: 1091

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.

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: genjix on March 14, 2011, 05:24:59 PM

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).

Pieter Wuille

legendary

Activity: 1072

Merit: 1174

Quote from: Gavin Andresen on March 14, 2011, 05:08:52 PM

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.

Quote from: Gavin Andresen on March 14, 2011, 05:08:52 PM

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.

jgarzik

legendary

Activity: 1596

Merit: 1091

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...

Matt Corallo

hero member

Activity: 755

Merit: 515

Quote from: Gavin Andresen on March 14, 2011, 05:24:16 PM

Quote from: Matt Corallo on March 14, 2011, 05:19:16 PM

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).

theymos

administrator

Activity: 5166

Merit: 12850

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

genjix

legendary

Activity: 1232

Merit: 1076

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: Matt Corallo on March 14, 2011, 05:19:16 PM

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.

Matt Corallo

hero member

Activity: 755

Merit: 515

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

legendary

Activity: 1652

Merit: 2216

Chief Scientist

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...

Topic: Order ID in a new transaction type? - page 3. (Read 7050 times)