Bitcoin Forum
December 10, 2016, 07:05:09 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Order ID in a new transaction type?  (Read 6250 times)
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
March 16, 2011, 11:57:25 PM
 #41

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?

...

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


Can't you work out how many order and the value the merchant was getting just by looking in the block chain at the number and value of payments to the publicly posted "pay me" address? Surely there's no way around this other than the merchant using a new receiving address for every sale he makes?

It would be useful if you would specify the details of what you are trying to achieve in exhaustive detail as at the moment it is unclear.

It is possible to encode fairly significant amounts of information in currently permissible bitcoin transactions by specifying the random value (often termed k) in the ECDSA signing algorithm.  32 bits could be easily encoded without any significant decrease in security.  

An explanation can be found on the Wikipedia page for Subliminal Channels.

ByteCoin
1481353509
Hero Member
*
Offline Offline

Posts: 1481353509

View Profile Personal Message (Offline)

Ignore
1481353509
Reply with quote  #2

1481353509
Report to moderator
1481353509
Hero Member
*
Offline Offline

Posts: 1481353509

View Profile Personal Message (Offline)

Ignore
1481353509
Reply with quote  #2

1481353509
Report to moderator
1481353509
Hero Member
*
Offline Offline

Posts: 1481353509

View Profile Personal Message (Offline)

Ignore
1481353509
Reply with quote  #2

1481353509
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481353509
Hero Member
*
Offline Offline

Posts: 1481353509

View Profile Personal Message (Offline)

Ignore
1481353509
Reply with quote  #2

1481353509
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 17, 2011, 01:13:33 AM
 #42

Can't you work out how many order and the value the merchant was getting just by looking in the block chain at the number and value of payments to the publicly posted "pay me" address? Surely there's no way around this other than the merchant using a new receiving address for every sale he makes?

Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output.  Make the txout something like:
Code:
  OP_OVER OP_HASH160 OP_XOR <hash160_xor_r1> OP_EQUALVERIFY OP_CHECKSIG
... and to spend the txin is:  <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160).  Or something like that (I shouldn't be thinking about cryptography when I'm this tired).


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

Activity: 1470


View Profile
March 17, 2011, 01:33:57 AM
 #43

Can't you work out how many order and the value the merchant was getting just by looking in the block chain at the number and value of payments to the publicly posted "pay me" address? Surely there's no way around this other than the merchant using a new receiving address for every sale he makes?

Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output.  Make the txout something like:
Code:
  OP_OVER OP_HASH160 OP_XOR <hash160_xor_r1> OP_EQUALVERIFY OP_CHECKSIG
... and to spend the txin is:  <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160).  Or something like that (I shouldn't be thinking about cryptography when I'm this tired).

Although not really the same thing, this reminds me of ArtForz' idea for theymos' bitcoin scratch-off cards.  Seems like a neat and doable idea.


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

Activity: 2506


View Profile
March 17, 2011, 02:04:27 AM
 #44

Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output.  Make the txout something like:
Code:
  OP_OVER OP_HASH160 OP_XOR <hash160_xor_r1> OP_EQUALVERIFY OP_CHECKSIG
... and to spend the txin is:  <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160).  Or something like that (I shouldn't be thinking about cryptography when I'm this tired).

Very interesting idea! I added it to the script page on the wiki.

OP_XOR is disabled, unfortunately, so it would require updating everyone.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 17, 2011, 12:01:44 PM
 #45

Actually, falling asleep last night I realized what I proposed would be yet another variation on an 'anybody can claim' transaction (anybody can just choose an r1 that make r1 XOR hash_xor_r1 evaluate to a hash that they own).

I think this would work:
Code:
OP_OVER OP_ADD OP_HASH160 <hash160(r1+public_key)> OP_EQUALVERIFY OP_CHECKSIG
... supply <scriptsig> <public_key> <r1> to claim.

I'm not suggesting anything like this get implemented any time soon, I started this thread just to explore what is possible.

How often do you get the chance to work on a potentially world-changing project?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
March 17, 2011, 02:42:44 PM
 #46

Yeah... I can imagine clever ways of obfuscating it such that you can't tell who's getting paid until they actually sign the transaction and spend the output.  Make the txout something like:
Code:
  OP_OVER OP_HASH160 OP_XOR <hash160_xor_r1> OP_EQUALVERIFY OP_CHECKSIG
... and to spend the txin is:  <scriptsig> <public_key> <r1> (where r1 is a random number used to obfuscate the publicly visible hash160).  Or something like that (I shouldn't be thinking about cryptography when I'm this tired).

If this were easy then surely Satoshi would have implemented it from the start; after all the address is one step removed from the public key presumably to prevent offline attacks trying to find the private key. It seems like you're looking to be another step removed. Is there much point?

ByteCoin
MacRohard
Member
**
Offline Offline

Activity: 103


View Profile
March 17, 2011, 03:16:08 PM
 #47

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


Well.. it's already possible to see who paid you using the block navigator... as long as they paid from a 'known' address...

How about we have single use sending accounts.. you could assemble the funds for making payment into a temporary local account from your other accounts and then send it on to the merchant's public bitcoin address.

You can then prove it was you that sent it by sending the merchant the private key for this temporary wallet address. The wallet nolonger contains any coins as you already sent them to the merchant's public address but they can see that this wallet is where the coins came from. You'd want to serialize these temporary wallet files into some format that could easily be pasted into an email.

Large merchants probably would want to use single use receiving addresses as it's easier to automate but single use source addresses could be made to work for small merchants that have static html websites and take orders through email - which may well be our best bet for growing the bitcoin market.. small businesses that can start taking bitcoin payments simply by adding a bitcoin address to their website may just do it to see if they get any orders.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
March 17, 2011, 07:42:27 PM
 #48

Actually, falling asleep last night I realized what I proposed would be yet another variation on an 'anybody can claim' transaction (anybody can just choose an r1 that make r1 XOR hash_xor_r1 evaluate to a hash that they own).

I think this would work:
Code:
OP_OVER OP_ADD OP_HASH160 <hash160(r1+public_key)> OP_EQUALVERIFY OP_CHECKSIG
... supply <scriptsig> <public_key> <r1> to claim.

I'm not suggesting anything like this get implemented any time soon, I started this thread just to explore what is possible.

Is OP_ADD necessary? It prevents address payments, and the hash of the random number is already unguessable.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 17, 2011, 08:11:34 PM
 #49

Is OP_ADD necessary? It prevents address payments, and the hash of the random number is already unguessable.

... I think that's right, you don't need the OP_OVER OP_ADD.  You have to know the random number to generate a valid signature, given only its hash.

You'd have to be very careful NEVER to use the same random number anybody else has ever used or will ever use; if your 'random' number is an order number (or even common-hash-of-an-order-number) then you're sunk, anybody can generate a valid <signature> <public_key> <r> triple.

For two extra bytes per transaction it might be better to hash in the public key, just so people don't shoot themselves in the foot.

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

Activity: 2506


View Profile
March 18, 2011, 01:42:42 AM
 #50

True. You'd want to add the hash of the public key to the random number instead of the full public key, though, or else address transactions won't be possible.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 19, 2011, 01:50:03 PM
 #51

If this were easy then surely Satoshi would have implemented it from the start; after all the address is one step removed from the public key presumably to prevent offline attacks trying to find the private key. It seems like you're looking to be another step removed. Is there much point?

Satoshi has a bunch of features that he 'figured out from the start' that are not implemented yet; I'll ask him if this is one of them after I figure out exactly what feature I want and convince myself it is possible to do securely.  So I'm going to try to gather my thoughts and see if there is much point:

This is the main problem I was trying to solve:

  • A merchant's website should give the customer a unique payment address during the chekcout process.  Ideally, generating that unique address would be done entirely on the web server without requiring a RPC call to a bitcoind process running somewhere.

Communicating with bitcoin or some merchant-services website during the checkout process adds another possible point of payment failure-- it is better for the merchant if their customers can continue to pay them even if their bitcoin daemon (or MyBitcoin or MtGox merchant services) is temporarily down for maintenance.

OP_OVER OP_ADD solves that problem, and, thinking about it, has some other very nice properties.  Here's how it would work in practice:

1. Merchant gets one or more public keys to use for payments.  They're stored in the web server's database.

2. Customer checks out:  web server computes HASH160(public_key+order_id), and converts the result to a bitcoin address version#2 (first byte is not base58-encoded-0, but something else).

3. That bitcoin address makes its way to bitcoin software running on the customer's machine (or at an online wallet service).  Since it is a version#2 address, bitcoin creates an OP_OVER OP_ADD.... transaction for it instead of an OP_DUP ... transaction.

4. Merchant's web server software tells a bitcoind running somewhere "if you see payments to HASH160(public_key+order_id), that's one of mine."

5. When the merchant want's to spend the bitcoins it got from the customer, it has to tell a bitcoind running somewhere the public_key,order_id pair.


If the merchant doesn't completely trust the payment processor then keeping steps (4) and (5) separate is very nice-- the payment processor can't spend the merchant's bitcoins until the merchant tells them the order_ids  (merchant would have to use truly random order_ids to be completely safe, of course).

And, as noted before, this is a little more private than standard bitcoin transactions because the public key isn't revealed until the coins are spent.



How often do you get the chance to work on a potentially world-changing project?
devrandom
Newbie
*
Offline Offline

Activity: 26



View Profile WWW
March 19, 2011, 11:23:14 PM
 #52

I see a couple of issues:

* If you have a limited number of public keys, information about the merchant's transaction volume is still leaked when the merchant spends their revenue coins.  Normally you'd be able to guess the merchant's profit margin, so just divide the outgoing transactions by (1 - profit_margin) to calculate the original revenue and transaction volume.

* Verifying funds received still needs to be done, so a bitcoind connection still has to be established before shipping.  If bitcoind interaction is required, might as well generate a batch of keys every hour or every day.

So it seems to me that generating unique transactions keys in batch and ahead of time is still the way to go.

https://github.com/devrandom
goldmongler
Newbie
*
Offline Offline

Activity: 9


View Profile
March 23, 2011, 04:28:12 PM
 #53

what if

-customer checks out using form
-server encrypts, sends to somewhere running mail::gpg perl script
-decrypts, parses email form into database
-creates a reply email, inserts either one of the bulk generated bitcoin addresses or uses bitcoind to generate one
-sends customer an email invoice saying 'here's your payment address. give it to this exchanger kthx'
-sends merchant an encrypted copy for records/shipping
-nukes all history out of the database

bonus if it can parse a gpg key the customer optionally sends and encrypt their reply email with it.

or just populate sql database with mybitcoin addresses and present a page on checkout with info and address, and email customer same info..?
ffe
Sr. Member
****
Offline Offline

Activity: 297



View Profile
March 24, 2011, 04:32:25 AM
 #54


If this were easy then surely Satoshi would have implemented it from the start; after all the address is one step removed from the public key presumably to prevent offline attacks trying to find the private key. It seems like you're looking to be another step removed. Is there much point?

Satoshi has a bunch of features that he 'figured out from the start' that are not implemented yet; I'll ask him if this is one of them after I figure out exactly what feature I want and convince myself it is possible to do securely.  So I'm going to try to gather my thoughts and see if there is much point:

This is the main problem I was trying to solve:

  • A merchant's website should give the customer a unique payment address during the chekcout process.  Ideally, generating that unique address would be done entirely on the web server without requiring a RPC call to a bitcoind process running somewhere.

Communicating with bitcoin or some merchant-services website during the checkout process adds another possible point of payment failure-- it is better for the merchant if their customers can continue to pay them even if their bitcoin daemon (or MyBitcoin or MtGox merchant services) is temporarily down for maintenance.

OP_OVER OP_ADD solves that problem, and, thinking about it, has some other very nice properties.  Here's how it would work in practice:

1. Merchant gets one or more public keys to use for payments.  They're stored in the web server's database.

2. Customer checks out:  web server computes HASH160(public_key+order_id), and converts the result to a bitcoin address version#2 (first byte is not base58-encoded-0, but something else).

3. That bitcoin address makes its way to bitcoin software running on the customer's machine (or at an online wallet service).  Since it is a version#2 address, bitcoin creates an OP_OVER OP_ADD.... transaction for it instead of an OP_DUP ... transaction.

4. Merchant's web server software tells a bitcoind running somewhere "if you see payments to HASH160(public_key+order_id), that's one of mine."

5. When the merchant want's to spend the bitcoins it got from the customer, it has to tell a bitcoind running somewhere the public_key,order_id pair.


If the merchant doesn't completely trust the payment processor then keeping steps (4) and (5) separate is very nice-- the payment processor can't spend the merchant's bitcoins until the merchant tells them the order_ids  (merchant would have to use truly random order_ids to be completely safe, of course).

And, as noted before, this is a little more private than standard bitcoin transactions because the public key isn't revealed until the coins are spent.





I was answering a different question and came up with the following:

Here’s a use case: The client creates a special kind of transaction that you could attach to the email. This transaction transfers a certain amount of Bitcoin from your public key to the recipients public key. This transaction is not published and therefore not yet final. Furthermore, it has a time to live, say 48 hours.

At the receiver the software checks the validity of the transaction. If it is valid and the money is there in Bitcoin it presents the email to you. If you like the email you do nothing and the transaction expires. No funds transfer. After the transaction expires the sending wallet deletes its copy of the transaction and credits the sender with the coin.

If you don’t like the email you click the button and the coin is collected. (The transaction is published and bundled into the next Bitcoin block.) The sending wallet sees the transaction and makes the deduction of funds from the wallet permanent.

This is like a check in the mail. It’s safe because only the recipient public key can collect it and it can’t be lost because of the expiration date.


It’s a form of check in bitcoin. The key idea is that the receiver adds a well formed transaction to the block chain, not the sender. This can be made to solve the merchant problem as well without having to add a new transaction type to the block chain. It would work as follows:

Define  a well formed Transaction as Tw.
Define a covered transaction, Tc, as one where a field in the transaction is “covered” redering the transaction invalid as far as the normal client is concerned.
Assume the sender uses the receiver’s public key to generate the cover in such a manner that only the receiver (using his private key) can uncover it.
So, the sender starts by creating a well formed transaction Tw. He then covers it using the receivers public key producing Tc. He sends Tc to the receiver out of band (it’s exported from the client and sent in some other transaction, encoded for pasting in an email for example.) Only the receiver can uncover Tc to produce Tw which he can check and submit to the network if he wants to cash the check.

One detail. The sender should put the amount of the check into a single public key he owns before creating the check. The sender can effectively cancel the check by sending himself the amount of the check from that key. If his cancel went in before  the merchant’s cashing of the check then the check is canceled. If the merchant got Tw published first then the cancel is too late. This mechanism allows an effective expiration time limit on the check.
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!