Order ID in a new transaction type?

[Stefan Thomas]

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

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

Which algo is used for the asym. encryption btw?

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.

[BitterTea]

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?

From the wiki:

Addresses

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

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

[Stefan Thomas]

There is no encryption in Bitcoin, only signing.

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

[randomguy7]

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

[Gavin Andresen]

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

[jgarzik]

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.

[randomguy7]

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.

[Pieter Wuille]

There is no encryption in Bitcoin, only signing.

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

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.

[jgarzik]

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.

[caveden]

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

[genjix]

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.

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

[Matt Corallo]

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.

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. 

[Stefan Thomas]

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

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

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.

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

[JollyGreen]

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. 

[Mike Hearn]

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.

[Gavin Andresen]

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

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

[Mike Hearn]

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

[Luke-Jr]

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

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

[chromicant]

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. Really easy math wise as well...it's just a system of linear equations IIRC.

[we6jbo]

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.