<p>Yes. You can view a transaction as being a public link between a number of public keys. If different people have the secret keys for those public keys then they have all the necessary information to calculate shared Diffie-Helman elliptic curve points. So in the simple case that you transfer all the bitcoins in an address to someone else's address then you can use his address and your private key to calculate a point which will be the same as the point calculated by him using his private key and your address. Nobody else can calculate these points.</p>

CC BY-SA 3.0
2013-10-15T13:26:16.997Z
Could you elaborate on how this works? In particular, is it a problem that an address is not itself a public key, but only its hash?
Nate Eldredge
CC BY-SA 3.0
2013-10-15T22:35:40.933Z
With current whitelisted scripts, all transactions (apart from coinbase) allow the recipient to obtain a public key where the sender knows the private key. You are right that if the coins are sent to an address from which there have never been any spends then the sender cannot complete their half of the key agreement until the recipient spends the coins or otherwise reveals the relevant public key.
Barack Obama
CC BY-SA 3.0
2013-10-22T08:33:23.803Z
The public key of the receiver is not in the transaction, only the public key of the sender.  The hash of the public key of the receiver is in the transaction, but I don't see how that is enough to make a shared secret.
Eyal
CC BY-SA 3.0
2013-09-14T02:05:22.067Z
2013-09-14T02:05:22.067Z
Barack Obama
<p>No.</p>

<p>However, it would be possible to build a scheme on top of the public and private keys that they used to exchange a secret key, similar to how RSA/DSA is used to make session keys for encryption.</p>

CC BY-SA 3.0
2013-09-12T20:34:06.517Z
This would require the receiver to transmit additional information back to the sender, correct?
John Henry
CC BY-SA 3.0
2013-09-14T16:42:43.237Z
@JohnHenry: No, there are schemes that have no such requirement, such as ECIES, which instead require the sender to disclose a public key and to know the recipient's public key.
David Schwartz
CC BY-SA 3.0
2013-09-15T13:38:50.593Z
ECIES does establish a shared session key, but there is still bidirectional communication involved (one way is the disclosure of the public key, the other is the message + ephemeral key). In any case, I don't see how that is relevant here - the question is about Bitcoin transactions I assume.
Pieter Wuille
CC BY-SA 3.0
2013-10-15T10:57:34.237Z
@PieterWuille The question only asks about establishing a shared secret, which an ECIES session key is. So you would only need the part of ECIES that doesn't require any bidirectional communication.
David Schwartz
CC BY-SA 3.0
2013-09-12T11:58:30.930Z
2013-09-12T11:58:30.930Z
Eyal
<p>No. </p>

<p>This is because the receiver does not play any role in the transaction. They don't even have to know about it. The transaction actually takes place between the sender and the bitcoin network, and the sender needs to have a private key which (hopefully) is secret.</p>

CC BY-SA 3.0
2013-09-14T16:43:06.927Z
There are schemes that create a shared secret without one party playing any role in the transaction.
David Schwartz
CC BY-SA 3.0
2013-09-13T01:15:10.990Z
2013-09-13T01:15:10.990Z
Loourr
<p>After making a transaction and receiving all the hashes and ids, is there a number that is secret and only the two people involved in the transaction know?</p>

<transactions>
Is there a secret number that is only known by the sender and the receiver after making a transaction?
aninom
# Is there a secret number that is only known by the sender and the receiver after making a transaction?

(Asked by: username_0 on 2013-09-12)

After making a transaction and receiving all the hashes and ids, is there a number that is secret and only the two people involved in the transaction know?

**Tags:** transactions


---

## 3 answers

### Answer by username_1 on 2013-09-14. Score: 1

Yes. You can view a transaction as being a public link between a number of public keys. If different people have the secret keys for those public keys then they have all the necessary information to calculate shared Diffie-Helman elliptic curve points. So in the simple case that you transfer all the bitcoins in an address to someone else's address then you can use his address and your private key to calculate a point which will be the same as the point calculated by him using his private key and your address. Nobody else can calculate these points.

> **Comments:**
> **username_2**: Could you elaborate on how this works? In particular, is it a problem that an address is not itself a public key, but only its hash?  
> **username_1**: With current whitelisted scripts, all transactions (apart from coinbase) allow the recipient to obtain a public key where the sender knows the private key. You are right that if the coins are sent to an address from which there have never been any spends then the sender cannot complete their half of the key agreement until the recipient spends the coins or otherwise reveals the relevant public key.  
> **username_3**: The public key of the receiver is not in the transaction, only the public key of the sender.  The hash of the public key of the receiver is in the transaction, but I don't see how that is enough to make a shared secret.  

---

### Answer by username_3 on 2013-09-12. Score: 0

No.

However, it would be possible to build a scheme on top of the public and private keys that they used to exchange a secret key, similar to how RSA/DSA is used to make session keys for encryption.

> **Comments:**
> **username_4**: This would require the receiver to transmit additional information back to the sender, correct?  
> **username_5**: @username_4: No, there are schemes that have no such requirement, such as ECIES, which instead require the sender to disclose a public key and to know the recipient's public key.  
> **username_6**: ECIES does establish a shared session key, but there is still bidirectional communication involved (one way is the disclosure of the public key, the other is the message + ephemeral key). In any case, I don't see how that is relevant here - the question is about Bitcoin transactions I assume.  
> **username_5**: @username_6 The question only asks about establishing a shared secret, which an ECIES session key is. So you would only need the part of ECIES that doesn't require any bidirectional communication.  

---

### Answer by username_7 on 2013-09-13. Score: -1

No.

This is because the receiver does not play any role in the transaction. They don't even have to know about it. The transaction actually takes place between the sender and the bitcoin network, and the sender needs to have a private key which (hopefully) is secret.

> **Comments:**
> **username_5**: There are schemes that create a shared secret without one party playing any role in the transaction.  

---

