Post
Topic
Board Development & Technical Discussion
Re: Transaction metadata (do we need an OP_DROP transaction type?)
by
Stefan Thomas
on 10/09/2012, 18:56:35 UTC
Am I missing some other simple, secure, decentralized, non-blockchain scheme for attaching metadata to transactions?

Maybe. Off the top of my head (sorry in advance if I'm missing something obvious):

Currently, the way we handle metadata in Bitcoin is that the metadata is transferred to the recipient, who then replies with a uniquely generated address. Once the sender makes the payment, the metadata can be determined by the address.

In theory, this already allows secure association of arbitrary metadata with a Bitcoin transaction. The problem is that we need to contact the recipient *before* we make the transaction, which doesn't work well for many use cases.

So how about this.

The recipient publishes their public ECDSA point P.

A sender generates a JSON metadata object M and calculates its hash e = SHA256(M). The sender then calculates a new public point PM = P * e. Next, the sender creates a transaction sending the money to the address RIPE160(SHA256(PM)). Finally, he transmits M to the recipient through a secure channel - this could be sent directly via HTTPS, encrypted email, etc. or perhaps left as an message in a DHT, encrypted with ECDH and the recipient's public point P as the key.


What properties does such a scheme have?

The recipient is committed to one set of metadata M for this transaction unless they can find a SHA256 collision. As long as the metadata object is kept private, no one else can determine the relationship between the public point P and the transaction-specific point PM. The recipient does not need to be always-online.