Bitcoin Forum
December 10, 2016, 11:01:12 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Order ID in a new transaction type?  (Read 6251 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 14, 2011, 09:08:52 PM
 #1

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

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481367672
Hero Member
*
Offline Offline

Posts: 1481367672

View Profile Personal Message (Offline)

Ignore
1481367672
Reply with quote  #2

1481367672
Report to moderator
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 14, 2011, 09:19:16 PM
 #2

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?

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 14, 2011, 09:24:16 PM
 #3

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.

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

Activity: 1232


View Profile
March 14, 2011, 09:24:59 PM
 #4

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

Activity: 2506


View Profile
March 14, 2011, 09:26:06 PM
 #5

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 14, 2011, 09:26:42 PM
 #6

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

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 14, 2011, 09:28:20 PM
 #7

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
March 14, 2011, 09:33:08 PM
 #8

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 14, 2011, 09:36:05 PM
 #9

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

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 14, 2011, 09:36:12 PM
 #10

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
March 14, 2011, 09:38:16 PM
 #11

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
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 14, 2011, 09:42:01 PM
 #12

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. 

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
March 14, 2011, 09:45:28 PM
 #13

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
carp
Member
**
Offline Offline

Activity: 82


View Profile
March 14, 2011, 09:45:57 PM
 #14

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

Activity: 463


View Profile
March 14, 2011, 09:49:49 PM
 #15

Why not just have clients tell the server the tx hash?
Syke
Legendary
*
Offline Offline

Activity: 2100


View Profile
March 14, 2011, 09:51:57 PM
 #16

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.

Buy & Hold
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 14, 2011, 09:52:25 PM
 #17

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
March 14, 2011, 09:55:04 PM
 #18

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Stefan Thomas
Full Member
***
Offline Offline

Activity: 235


AKA: Justmoon


View Profile WWW
March 14, 2011, 09:56:47 PM
 #19

Quote from: jgarzik
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.

Twitter: @justmoon
PGP: D16E 7B04 42B9 F02E 0660  C094 C947 3700 A4B0 8BF3
randomguy7
Hero Member
*****
Offline Offline

Activity: 528


View Profile
March 14, 2011, 10:04:13 PM
 #20

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?
Pages: [1] 2 3 »  All
  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!