<p>For a proof of existence, you do not actually need to store the data in the blockchain. Merely commiting to it, by using its hash in way that is later provably used, is enough.</p>

<p>One such way is using a mechanism originally described as pay-to-contract.</p>

<p>Warning: elliptic curve math follows.</p>

<p>You start with any public key X (yours or someone elses). Then construct the modified key X' = (X + H(X || C)*G) [with H a hash function, || concatenation, and G the secp256k1 generator point], and send a transaction (possibly as part of an actual need to send money to X) to the address corresponding to X'. The receiver (which can be yourself if you do this for a change output) will need to add the value H(X || C) to his private key corresponding to X, to be able to spend the coins.</p>

<p>However, revealing X and C, plus the transaction in the blockchain you used to send to X', is a proof that C was actually known at the time of the transaction.</p>

<p>This scheme has the advantage of not requiring any data in the chain more than the transaction would already consume, and additionally that it is indistinguishable from a normal transaction, making it harder to censor or be subject to changing policy of nodes on the network.</p>

<p>An alternative possibly exists which works without modified addresses of transaction, but is not well studied yet.</p>

CC BY-SA 3.0
2015-05-11T15:02:32.240Z
Do you happen to have a reference for the possible alternative you mentioned?
Christopher Gurnee
CC BY-SA 3.0
2015-05-03T08:32:15.113Z
2015-05-03T14:40:58.040Z
2015-05-03T14:40:58.040Z
Pieter Wuille
<p>One more possible way (and a predecessor of OP_RETURN)
quote from <strong>Mastering Bitoin</strong> by Andreas M. Antonopoulos</p>

<blockquote>
  <p>Moreover, such transactions create UTXO that cannot be spent, using
  the destination bitcoin address as a free-form 20-byte field. Because
  the address is used for data, it doesn’t correspond to a private key
  and the resulting UTXO can never be spent; it’s a fake payment. This
  practice causes the size of the in-memory UTXO set to increase and
  these transactions that can never be spent are therefore never
  removed, forcing bitcoin nodes to carry these forever in RAM, which is
  far more expensive.</p>
</blockquote>

<p>Regarding that quote it's possible to store data in address field and that's how OP_RETURN begins</p>

CC BY-SA 3.0
2015-05-26T04:54:03.437Z
2015-05-26T04:54:03.437Z
Igor Barinov
<p>I am working on iOS camera app and would like to store hash of photos inside blockchain for the "proof of existence".</p>

<p>AFAIK transaction with OP_RETURN in output has some disadvantages</p>

<ul>
<li>non-refundable. so every transaction burns coins and removes something from a finite resources. forever. </li>
<li>can be rejected by miner/can be subject to reject because of low fee and negative impact of burning coins</li>
<li>subject to change. OP_RETURN field used to be 80 bytes and has been changed to 40 bytes.</li>
</ul>

<p>I appreciate any ideas</p>

CC BY-SA 3.0
2015-05-26T14:02:47.983Z
I believe the OP_RETURN byte limit actually used to be 40 bytes and was increased to 80.
morsecoder
CC BY-SA 3.0
2015-05-26T14:19:48.730Z
@StephenM347 it used to be 80 now it's 40 https://github.com/bitcoin/bitcoin/blob/0.10/src/script/standard.h
Igor Barinov
CC BY-SA 3.0
2015-05-26T14:20:55.140Z
static const unsigned int MAX_OP_RETURN_RELAY = 40;
Igor Barinov
<blockchain><op-return>
Alternatives to OP_RETURN to store data in Bitcoin blockchain
Igor Barinov
# Alternatives to OP_RETURN to store data in Bitcoin blockchain

(Asked by: username_0 on 2015-05-03)

I am working on iOS camera app and would like to store hash of photos inside blockchain for the "proof of existence".

AFAIK transaction with OP\_RETURN in output has some disadvantages

* non-refundable. so every transaction burns coins and removes something from a finite resources. forever.
* can be rejected by miner/can be subject to reject because of low fee and negative impact of burning coins
* subject to change. OP\_RETURN field used to be 80 bytes and has been changed to 40 bytes.

I appreciate any ideas

**Tags:** blockchain, op-return

> **Comments:**
> **username_1**: I believe the OP_RETURN byte limit actually used to be 40 bytes and was increased to 80.  
> **username_0**: @StephenM347 it used to be 80 now it's 40 https://github.com/bitcoin/bitcoin/blob/0.10/src/script/standard.h  
> **username_0**: static const unsigned int MAX_OP_RETURN_RELAY = 40;  

---

## 2 answers

### Answer by username_2 on 2015-05-03. Score: 7

For a proof of existence, you do not actually need to store the data in the blockchain. Merely commiting to it, by using its hash in way that is later provably used, is enough.

One such way is using a mechanism originally described as pay-to-contract.

Warning: elliptic curve math follows.

You start with any public key X (yours or someone elses). Then construct the modified key X' = (X + H(X || C)\*G) [with H a hash function, || concatenation, and G the secp256k1 generator point], and send a transaction (possibly as part of an actual need to send money to X) to the address corresponding to X'. The receiver (which can be yourself if you do this for a change output) will need to add the value H(X || C) to his private key corresponding to X, to be able to spend the coins.

However, revealing X and C, plus the transaction in the blockchain you used to send to X', is a proof that C was actually known at the time of the transaction.

This scheme has the advantage of not requiring any data in the chain more than the transaction would already consume, and additionally that it is indistinguishable from a normal transaction, making it harder to censor or be subject to changing policy of nodes on the network.

An alternative possibly exists which works without modified addresses of transaction, but is not well studied yet.

> **Comments:**
> **username_3**: Do you happen to have a reference for the possible alternative you mentioned?  

---

### Answer by username_0 on 2015-05-26. Score: 1

One more possible way (and a predecessor of OP\_RETURN)
quote from **Mastering Bitoin** by Andreas M. Antonopoulos

> Moreover, such transactions create UTXO that cannot be spent, using
> the destination bitcoin address as a free-form 20-byte field. Because
> the address is used for data, it doesn’t correspond to a private key
> and the resulting UTXO can never be spent; it’s a fake payment. This
> practice causes the size of the in-memory UTXO set to increase and
> these transactions that can never be spent are therefore never
> removed, forcing bitcoin nodes to carry these forever in RAM, which is
> far more expensive.

Regarding that quote it's possible to store data in address field and that's how OP\_RETURN begins


---

