<p>You are attempting to answer the question you are asking in the question. Let me get to the root of what you are asking.</p>

<p>From what I understand, you would like to create a 2 party escrow - buyer sends money in a way that can't be retrieved unless both parties are satisfied.</p>

<p>This can be done in two ways in Bitcoin - one through the use of multisignature transactions, other - through split-key addresses.</p>

<p>The first approach is to send the money to 2-of-2 multisignature combination of addresses - one held by the buyer, and another - by the seller. When they reach consensus, they create a transaction, each signs it and money is transferred. The disadvantage of this approach is that if they don't reach consensus, there is no way to settle the money dispute. If you would introduce some third party acting like an escrow and create 2-of-3 multisignature address, then you would need a consensus of any 2 involved parties. If the buyer and seller agree on a consensus, escrow service does not get involved and everyone is satisfied. If they can't reach consensus, escrow steps in and mediates the solution with the parties forcing a compromise - it can always break a stalemate by cooperating with one party.</p>

<p>The second approach is for both parties to settle on a public key each by themselves, and then combine it through multiplication or addition, creating a split-key address. They both know the public key and associated address, but none of them know the private key. If they agree on an output, the buyer sends the seller their private key and the seller can create a transaction crediting themselves, or if the seller wishes to return the money to the buyer, they can give them their private key. This approach has a few problems:</p>

<ul>
<li>One can't be using the same private keys in multiple transactions, as they get shared with third parties</li>
<li>The person that will receive the second private key can dictate any division of money - nothing can stop them</li>
<li>There is no possibility of creating a 2-of-3 escrow</li>
</ul>

<p>So all in all, use multisignature transactions.</p>

CC BY-SA 3.0
2013-05-31T04:23:54.433Z
2-on-2 multisig is fine, I'm satisfied for this file to never be opened, ever, in fact; but the problem becomes in the creation of the file. -How do we generate the keypair and stuff them inside the PGP wrapper without either user ever getting the chance to see the private key?
Dex Bitcoin
CC BY-SA 3.0
2013-05-31T04:54:43.853Z
@DexBitcoin What is the point of the PGP?
ThePiachu
CC BY-SA 3.0
2013-06-01T04:29:21.833Z
To make the wallet into an encrypted file that can change hands without allowing anyone to see the private key inside it.
Dex Bitcoin
CC BY-SA 3.0
2013-06-01T11:40:20.850Z
@DexBitcoin With traditional encryption, the person encrypting the file would need to have known its content, so it's not useful for your problem.
ThePiachu
CC BY-SA 3.0
2013-05-30T10:42:05.050Z
2013-05-30T10:42:05.050Z
ThePiachu
<p>This can be done in general with <a href="http://en.wikipedia.org/wiki/Fully_homomorphic_encryption#Fully_homomorphic_encryption" rel="nofollow">fully homomorphic encryption</a>. (It wouldn't be a "PGP file" per se but an encrypted message with the specific scheme.) It's not very practical currently though.</p>

<p>But it looks like what you are really trying to do is an arrangement where A and B each have a piece of information, without any of them having seen the other, so that both pieces are needed in order to spend specific bitcoins. In this case, ECDSA addition of keys will work, as will a multi-signature transaction.</p>

CC BY-SA 3.0
2013-05-30T07:42:55.300Z
2013-05-30T07:42:55.300Z
Meni Rosenfeld
<p>I've been trying to figure out a way for a bitcoin wallet keypair to be created between two or more people without either/any one of them holding the private key afterwards.</p>

<p>Instead, I want the buyer to hold a PGP-encrypted file that has the private key inside it.</p>

<p>The buyer is never, ever, to see that private key... It's the seller's wallet that is encrypted... But the seller can't have the private key yet either, just a public key, and the PGP key to open the PGP-protected file.</p>

<p>I thought about a 3rd man in the middle creating the wallet and putting it there, but then the 3rd guy could cash out the wallet himself later... </p>

<p>So is there a trustless way to put the keypair into a PGP file and send that file to the buyer and the PGP key to the seller?</p>

<p>Enjoy the puzzle!</p>

CC BY-SA 3.0
2013-05-30T06:18:04.740Z
It sounds like your goal is to have a Bitcoin address generated by two parties that can only be spent out of by having those two parties cooperate. Is that correct?
Nick ODell
CC BY-SA 3.0
2013-05-30T12:55:36.890Z
Are you sure m-of-n transactions aren't instead what you need?
o0'.
CC BY-SA 3.0
2013-05-31T04:18:22.203Z
@Nick: Yes, or more specifically, can only be spent, by only the vendor, when the buyer sends the pgp encrypted wallet to the vendor. (Redemption)
Dex Bitcoin
CC BY-SA 3.0
2013-05-31T04:21:50.253Z
@Lorhoris: I'm pretty sure M-of-n aren't going to help this need. I definitely want the end product to be a file encrypted in something like PGP, where the person holding it can't get inside and the other person can get inside, (and be the first one to access the wallet) but doesn't possess it in any way.
Dex Bitcoin
<private-key><pgp>
Fun puzzle: How to generate keypair without anyone seeing the private key?
Dex Bitcoin
# Fun puzzle: How to generate keypair without anyone seeing the private key?

(Asked by: username_0 on 2013-05-30)

I've been trying to figure out a way for a username_0 wallet keypair to be created between two or more people without either/any one of them holding the private key afterwards.

Instead, I want the buyer to hold a PGP-encrypted file that has the private key inside it.

The buyer is never, ever, to see that private key... It's the seller's wallet that is encrypted... But the seller can't have the private key yet either, just a public key, and the PGP key to open the PGP-protected file.

I thought about a 3rd man in the middle creating the wallet and putting it there, but then the 3rd guy could cash out the wallet himself later...

So is there a trustless way to put the keypair into a PGP file and send that file to the buyer and the PGP key to the seller?

Enjoy the puzzle!

**Tags:** private-key, pgp

> **Comments:**
> **username_1**: It sounds like your goal is to have a username_0 address generated by two parties that can only be spent out of by having those two parties cooperate. Is that correct?  
> **username_2**: Are you sure m-of-n transactions aren't instead what you need?  
> **username_0**: @username_1: Yes, or more specifically, can only be spent, by only the vendor, when the buyer sends the pgp encrypted wallet to the vendor. (Redemption)  
> **username_0**: @Lorhoris: I'm pretty sure M-of-n aren't going to help this need. I definitely want the end product to be a file encrypted in something like PGP, where the person holding it can't get inside and the other person can get inside, (and be the first one to access the wallet) but doesn't possess it in any way.  

---

## 2 answers

### Answer by username_3 on 2013-05-30. Score: 3 | Accepted answer

You are attempting to answer the question you are asking in the question. Let me get to the root of what you are asking.

From what I understand, you would like to create a 2 party escrow - buyer sends money in a way that can't be retrieved unless both parties are satisfied.

This can be done in two ways in username_0 - one through the use of multisignature transactions, other - through split-key addresses.

The first approach is to send the money to 2-of-2 multisignature combination of addresses - one held by the buyer, and another - by the seller. When they reach consensus, they create a transaction, each signs it and money is transferred. The disadvantage of this approach is that if they don't reach consensus, there is no way to settle the money dispute. If you would introduce some third party acting like an escrow and create 2-of-3 multisignature address, then you would need a consensus of any 2 involved parties. If the buyer and seller agree on a consensus, escrow service does not get involved and everyone is satisfied. If they can't reach consensus, escrow steps in and mediates the solution with the parties forcing a compromise - it can always break a stalemate by cooperating with one party.

The second approach is for both parties to settle on a public key each by themselves, and then combine it through multiplication or addition, creating a split-key address. They both know the public key and associated address, but none of them know the private key. If they agree on an output, the buyer sends the seller their private key and the seller can create a transaction crediting themselves, or if the seller wishes to return the money to the buyer, they can give them their private key. This approach has a few problems:

* One can't be using the same private keys in multiple transactions, as they get shared with third parties
* The person that will receive the second private key can dictate any division of money - nothing can stop them
* There is no possibility of creating a 2-of-3 escrow

So all in all, use multisignature transactions.

> **Comments:**
> **username_0**: 2-on-2 multisig is fine, I'm satisfied for this file to never be opened, ever, in fact; but the problem becomes in the creation of the file. -How do we generate the keypair and stuff them inside the PGP wrapper without either user ever getting the chance to see the private key?  
> **username_3**: @username_0 What is the point of the PGP?  
> **username_0**: To make the wallet into an encrypted file that can change hands without allowing anyone to see the private key inside it.  
> **username_3**: @username_0 With traditional encryption, the person encrypting the file would need to have known its content, so it's not useful for your problem.  

---

### Answer by username_4 on 2013-05-30. Score: 0

This can be done in general with [fully homomorphic encryption](http://en.wikipedia.org/wiki/Fully_homomorphic_encryption#Fully_homomorphic_encryption). (It wouldn't be a "PGP file" per se but an encrypted message with the specific scheme.) It's not very practical currently though.

But it looks like what you are really trying to do is an arrangement where A and B each have a piece of information, without any of them having seen the other, so that both pieces are needed in order to spend specific bitcoins. In this case, ECDSA addition of keys will work, as will a multi-signature transaction.


---

