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

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. 

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.



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.

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. 

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 with jgarzik on this one. Please, don't add this kind of unrelated data to the block chain.

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.

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.

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.

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.

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

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

Signing is a special case of asymmetric encryption.

From the wiki:

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

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.

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?

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.

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.

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

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.

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