<p>That's all well and nice, but it turns out that courts aren't interested in "mathematical proofs" (with good reason).  I recommend reading all the books by Bruce Schneider.</p>

<p>Let's say you got someone to pay you at <code>receive_public_key</code>. Does that mean he has agreed to contract <code>M</code>? No.</p>

<p>The courts would still need to see documentation that your partner actually saw and agreed to the contract <code>M</code>. You could have emailed the guy and said "I'll give you $10 if you send Bitcoins to <code>receive_public_key</code>, then later claim that he agreed to contract <code>M</code>.</p>

<p>This same thing happened in the 90's, with vendors claiming cryptographic digital signatures had the property of <a href="https://en.wikipedia.org/wiki/Non-repudiation" rel="nofollow">Non-repudiation</a>. But the courts disagreed. For example, someone can hold a gun to your head and make you 'sign' a contract (digital or otherwise). No court will consider that a valid contract, fancy math or no fancy math.</p>

CC BY-SA 4.0
2019-08-16T08:04:17.750Z
this is an uninformative answer. a complete waste of time and space.
irth
CC BY-SA 3.0
2014-03-16T18:38:28.100Z
2014-03-16T18:38:28.100Z
BraveNewCurrency
<p>I need to generate a receive address that is directly associated with some metadata, M, that forms part of a verifiable contract.</p>

<p>I require that customers can verify that an address really was generated from a specific contract message, but I do not want them to have the private key to the address.</p>

<p>I obviously don't want to bloat the blockchain nor do I wish to use non-standard transactions. P2SH is also not possible as it is still largely unsupported by many online wallet providers.</p>

<p>So here is my first attempt, based on (<a href="https://bitcointalk.org/index.php?topic=108423.0">https://bitcointalk.org/index.php?topic=108423.0</a>) ... </p>

<pre><code># generate an EC key pair for the company
issuer_public_key = issuer_private_key * G

# create a contract message string, M
M = 'Terms of contract bla bla and also includes issuer_public_key for safety'

# generate a hash of the message
e = SHA256(M)

# create an EC point that is known to both parties
contract_point =  (e * issuer_public_key)

# generate a public key for this contract to form our receive address. Customer agrees to contract when they send BTC to receive address.
receive_public_key = contract_point + issuer_public_key

# the private key for the receive address is thus
receive_private_key = contract_point + issuer_private_key
</code></pre>

<p>Feedback much appreciated</p>

<transactions><hash><encryption><contracts>
How to 'attach' metadata to a bitcoin receive address
grebit
# How to 'attach' metadata to a bitcoin receive address

(Asked by: username_0 on 2013-08-21)

I need to generate a receive address that is directly associated with some metadata, M, that forms part of a verifiable contract.
I require that customers can verify that an address really was generated from a specific contract message, but I do not want them to have the private key to the address.
I obviously don't want to bloat the blockchain nor do I wish to use non-standard transactions. P2SH is also not possible as it is still largely unsupported by many online wallet providers.
So here is my first attempt, based on (https://bitcointalk.org/index.php?topic=108423.0) ... 
# generate an EC key pair for the company
issuer_public_key = issuer_private_key * G

# create a contract message string, M
M = 'Terms of contract bla bla and also includes issuer_public_key for safety'

# generate a hash of the message
e = SHA256(M)

# create an EC point that is known to both parties
contract_point =  (e * issuer_public_key)

# generate a public key for this contract to form our receive address. Customer agrees to contract when they send BTC to receive address.
receive_public_key = contract_point + issuer_public_key

# the private key for the receive address is thus
receive_private_key = contract_point + issuer_private_key

Feedback much appreciated

**Tags:** transactions, hash, encryption, contracts


---

## 1 answers

### Answer by username_1 on 2014-03-16. Score: 2

That's all well and nice, but it turns out that courts aren't interested in "mathematical proofs" (with good reason). I recommend reading all the books by Bruce Schneider.

Let's say you got someone to pay you at `receive_public_key`. Does that mean he has agreed to contract `M`? No.

The courts would still need to see documentation that your partner actually saw and agreed to the contract `M`. You could have emailed the guy and said "I'll give you $10 if you send Bitcoins to `receive_public_key`, then later claim that he agreed to contract `M`.

This same thing happened in the 90's, with vendors claiming cryptographic digital signatures had the property of [Non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation). But the courts disagreed. For example, someone can hold a gun to your head and make you 'sign' a contract (digital or otherwise). No court will consider that a valid contract, fancy math or no fancy math.

> **Comments:**
> **username_2**: this is an uninformative answer. a complete waste of time and space.  

---

