<p>We wrote this paper before Bitcoin supported OP_RETURN. Now you would just use OP_RETURN. </p>

<p>In CommitCoin, you can reveal the private key off-blockchain. It might indeed be simpler. Our thinking is having it self-contained on the blockchain, without having to reference anything else or having to have a connection to the publisher was the simpler model.</p>

CC BY-SA 3.0
2016-10-17T02:29:55.423Z
Thank you very much for answering. That makes sense. It doesn't require a separate channel for additional information.
LLS
CC BY-SA 3.0
2016-10-14T18:46:24.283Z
2016-10-14T18:46:24.283Z
Jeremy Clark
<p>I am studying BitCoin recently.</p>

<p>I noticed a method called CommitCoin for secure timestamping. It requires two transactions to send coins back with the same randomness so that others can compute the private key.</p>

<p>However, isn't it easier to just reveal the private key yourself? The whole point is to prove that at some time in the past, I knew something. If I send some coins to the address and send the coins back, and later reveal my private key and it matches the public key, shouldn't it be enough to prove that?</p>

<p>Thanks in advance.</p>

CC BY-SA 3.0
2016-10-13T03:49:47.447Z
Can you give a link to more information on CommitCoin?
Nate Eldredge
CC BY-SA 3.0
2016-10-13T06:45:21.033Z
@NateEldredge I assume asker is referencing [this paper](https://eprint.iacr.org/2011/677.pdf).
Nick ODell
CC BY-SA 3.0
2016-10-14T01:47:10.923Z
@NateEldredge I read it from Bitcoin and Cryptocurrency Technologies. It just briefly introduces it as a way to achieve secure timestamping without creating unspendable coins that give burdens to the network. I just want to know is there any problem if we just create a private key with the hash from data, then send coins to the corresponding address, and send it back. And when required, just reveal that private key. (Or just publish the private key somewhere.)
LLS
CC BY-SA 3.0
2016-10-14T22:42:51.453Z
@LLS: CommitCoin was published in 2012, in 2014 OP_RETURN was added to cater to that use-case.
Murch
<blockchain><timestamp>
Why do we need two transactions for CommitCoin scheme
LLS
# Why do we need two transactions for CommitCoin scheme

(Asked by: username_0 on 2016-10-13)

I am studying BitCoin recently.

I noticed a method called CommitCoin for secure timestamping. It requires two transactions to send coins back with the same randomness so that others can compute the private key.

However, isn't it easier to just reveal the private key yourself? The whole point is to prove that at some time in the past, I knew something. If I send some coins to the address and send the coins back, and later reveal my private key and it matches the public key, shouldn't it be enough to prove that?

Thanks in advance.

**Tags:** blockchain, timestamp

> **Comments:**
> **username_1**: Can you give a link to more information on CommitCoin?  
> **username_2**: @username_1 I assume asker is referencing [this paper](https://eprint.iacr.org/2011/677.pdf).  
> **username_0**: @username_1 I read it from Bitcoin and Cryptocurrency Technologies. It just briefly introduces it as a way to achieve secure timestamping without creating unspendable coins that give burdens to the network. I just want to know is there any problem if we just create a private key with the hash from data, then send coins to the corresponding address, and send it back. And when required, just reveal that private key. (Or just publish the private key somewhere.)  
> **username_3**: @username_0: CommitCoin was published in 2012, in 2014 OP_RETURN was added to cater to that use-case.  

---

## 1 answers

### Answer by username_4 on 2016-10-14. Score: 3 | Accepted answer

We wrote this paper before Bitcoin supported OP\_RETURN. Now you would just use OP\_RETURN.

In CommitCoin, you can reveal the private key off-blockchain. It might indeed be simpler. Our thinking is having it self-contained on the blockchain, without having to reference anything else or having to have a connection to the publisher was the simpler model.

> **Comments:**
> **username_0**: Thank you very much for answering. That makes sense. It doesn't require a separate channel for additional information.  

---

