Bitcoin Forum

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

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.

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.

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

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

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

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.


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

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

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.

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. 

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

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.

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

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

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

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

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

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.

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.

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?

Yes, but other nodes can't know if I generated a public address randomly as a keypair or whether I just made it up.


ECDSA

An addendum to my original post: I'm not just suggesting a fee that increases linearly. A fee that increases exponentially with the size seems warranted since the data eats resources in three dimensions: Size, time and replication. So growing with size to the third power would seem the most logical.

From the wiki (https://en.bitcoin.it/wiki/Protocol_Specification#Addresses):

There is no encryption in Bitcoin, only signing. ECDSA is used for this purpose, specifically secp256k1.

Signing is a special case of asymmetric encryption. </terminologynazi>

But if the address is basically the hash of a pub key, it's not possible to (easily) encode much information into it.

RE: opening up the "store random stuff in the block chain" argument:

Several things make me not worried about that:

1. OP_CHECKSIG drives network-wide costs (see the thread on network-wide transaction cost back-of-the-envelope calculations).
2. New -limitefreerelay code will, I'm pretty confident, mitigate penny-flooding.
3. 512 bytes plus inputs plus outputs will will make these either "very-low-priority-free" or over 1K non-free transactions.
4. We're past the point where block chain download size is 'convenient' for new users.  We should implement lightweight client mode (download only block headers until you start solo mining) as soon as possible.


RE: pregenerate a bunch of addresses to use for payment:

I like that idea!   If you're getting, say, 20 bitcoin orders a day then 1,000 addresses would last you a month.  And even if you recycled them when you ran out it should be easy to match orders to addresses based on the transaction date and amount...


The whole "click to pay" feature needs to be figured out, and should work nicely in all four cases of (customer,merchant) using (bitcoin,online wallet).  My brain isn't up to it today, though...

I think providing the first [working, sustainable] decentralized digital currency is enough.

And what that means is, people should remember that supporting currencies have multiple layers.  The US dollar itself does not provide any hooks for payment APIs, nor chargebacks, nor fraud protection.  These are all layers on top of the currency itself, and occur out-of-band with respect to information transiting with the currency itself.

If we keep the base currency simple, and not used for other exotic goals such as distributed data publishing, that makes it most likely that bitcoin-the-currency will succeed.

So, adding a 512-byte opaque data area to each TX, for this merchant, seems excessive because

1) It could be done elsewhere.  Merchants are best served by a merchant friendly solution that provides gadgetry like order id's.  Bitcoin is a money transfer network, and traditionally merchants do not hook directly into a money transfer network.  They connect to a provider (FirstACH, PayPal, ...) who then connects them to the transfer network.  The great freedom that bitcoin provides is universal public access to the money transfer network -- but that comes with a high maintenance cost of living directly on a beta-quality P2P network.  Your small business coffee shop or flower shop should not be encouraged to connect directly to the bitcoin P2P network unless their staff has the time and skill to understand and handle P2P security issues.

2) Privacy-eroding poor programming practices become easier, such as storing unencoded order data in that area.  Programmers should never store anything except cryptographic hashes or encrypted data in such a data area, but they will be tempted to do otherwise because it's easy.

3) It would seem to open the door to other data storage applications.  Is data storage possible now?  Yes.  But that doesn't mean we should encourage non-currency uses.

That said, as a programmer I certainly recognize the value of being able to attach a piece of my data to a transaction whose contents is entirely outside the control of the creator, save for $BitcoinAddress and $Amount.  Thus, my fallback position on this issue has always been, if overruled by the community, argue for no more than a 32-byte data area.  Enough to store a cryptographic hash of your own, but small enough still to (hopefully) discourage people from storing Lady Gaga music in the block chain.

Reusing the addresses could also be usefull to fight attempts of dos attacks which try to use up all preset destination addresses and thereby making further payments impossible.

For RSA, this is true, there it is just encrypting the hash of the data with your private key, and verifying it by decrypting it with the public key. This is possible since the public and private keys can be used interchanged.

The DSA family of algorithms however, are only usable for signing, and can't be used for encryption, as far as I know.

Also, I would rather like to see a feature that permits bitcoin to sign and verify simple messages.  That verifies you control a private key, without needing to send any in-band data.

I agree with jgarzik on this one. Please, don't add this kind of unrelated data to the block chain.

Agreed. Keep it simple. Keep it perfect.

In fact I'm starting to think there should be a basic Bitcoin implementation as a reference, and end-user Bitcoin with all the magic (name lookup service, wallet encryption, gui). I'm thinking about possibly forking Bitcoin for that reason :p

I agree completely, I think there are too many advantages to having merchants use mtgox, mybitcoin, paypal-like services instead of running their own system.  One of the most important ones, which I think can't be stressed enough is that merchant systems that deal with financial data need to be secure.  This means much more than just turning on SSL and leaving it there.  Most merchants, even those who know a bit of PHP and JS, do not know nearly enough to code a properly secure financial site. 

In the end the simplest solution always works.  Bitcoin is simple and elegant as-is.  Adding more just complicates it and we should let other layers on top of the basic currency do that work.  The most successful technologies in the past have often been the ones which are simple to use and implement and have support for layers on top of them and I think we should mimic that. 

<offtopic>Signing itself is a form of asymmetric encryption. To sign something you encrypt it with your private key and other people decrypt it with your public key to confirm you indeed used the correct private key. Though your point is well taken that from the perspective of the user, DSA is not used for encryption.</offtopic>



You are still working off of the assumption that you can somehow limit the amount of data people can write into the block chain. You can't. You can only control the cost of doing so. Whether you require a larger fee for a single transaction or more transactions is fairly irrelevant.

That said, 32 bytes is plenty of room for a hash, a shortened URL or even "Happy Birthday!" so I'd be happy with that as a compromise/immediate solution.

To allow larger messages without centralization and without further changes to the blockchain, a DHT (http://en.wikipedia.org/wiki/Distributed_hash_table) could one day be implemented in Bitcoin clients similar to the way modern BitTorrent and eMule clients have one. Just store the key for the DHT in the transaction and the DHT in turn could make it's expiry, size limits etc. dependent on the underlying transaction's fee to help defend against spamming/attacks. Just like BitTorrent, not every client would have to support such a protocol extension, it would work just fine as an addon for those who need it without polluting the block chain or Bitcoin's core protocol. Like jgarzik said: Layers.

There is one issue that comes to my mind when considering messages stored in the block chain. The message is stored there forever, and readable to everyone whether the recipient wants it there or not.  I could write anything I want in my message and send it out.  Revealing the other users identity or email address, a negative feedback, whatever.  I guess it could be encrypted with the keys. 

If order IDs are put in transactions the next most common question will become "so how do I stop my competitors finding out my sales volume?".

Agreed with those who say the solution is just better webstore integration, pre-generating keys, or the use of a service like MyBitcoin.

Right, that was the problem I was hoping to brainstorm about.  I didn't want to re-open the "add data to the transaction database" discussion (I think "add data to the block chain" is misleading, since transaction data isn't actually part of the block-header-chain or transaction-merkle-tree).

I'm still wondering if there is a way to create transactions on the web server, without talking to bitcoind, using a small-ish number of pregenerated public keys, such that each transaction is unique and competitors can't tell how many transactions belong to any particular merchant.

Pre-generating a bunch of keys works, assuming that competitors don't know the pre-generated keys (bad assumption long-term if they keys are re-used, since they could just order a bunch of stuff and note the keys used for paying).

But you still need to know when the coins arrive right?

I'm not sure how it's possible to run an online shop that accepts BitCoins without having a node or using something like MyBitcoin. Unless the merchant does it all manually.

Perhaps the real solution is to try and organize people to integrate BitCoin with popular shopping cart software. I know some of it was already done but did the changes make it upstream?

As to keeping the node secure and up to date, hopefully it's secure out of the box and making it auto-update (even on Linux) is probably easier than many alternatives. First step would be to have it provided via an apt repository hosted on bitcoin.org (the official distributions are way too slow).

Orders can be verified/filled by a system without any external services (eg, only port 8333).

I don't know the crypto side of things-- is it possible to create a half-key which can be combined with another half-key? So for example, the webserver can customize half the key per transaction (leading to unique addresses for the customer), but not have the information to spend that tx until its half-key is combined with the locked-up-safe master-half-key...

Yup. Secret sharing (http://en.wikipedia.org/wiki/Secret_sharing). Really easy math wise as well...it's just a system of linear equations IIRC.

There's a number of problems with stores and anonymity mainly if the stores hold my information and their servers are broken into or worst then my information is out in the open. So a solution to solving this would be to include a public key with my bitcoin transaction. The store receives my public key and the transaction and my account which is labeled by public key is credited. When I go to make an order on the stores website, I encrypt my order with my private key, the store then receives the encrypted file and decrypts the file which they then process, take the money out of my account and destroy the encrypted contents. This way at no time will my order or information be stored on a database. In addition, the store can prove that I in fact made the order because the complete order information will be encrypted by the same keypair that I sent with the bitcoin transaction.

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

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:
... 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 (http://bitcointalk.org/index.php?topic=1514.msg19214#msg19214).  Seems like a neat and doable idea.

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

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

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

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

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.

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.

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.

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

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

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


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.