Take the 2-minute tour ×
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It's 100% free, no registration required.

I'm exploring having a bitcoin (or any blockchain) backed a distributed secure messaging system.

This is a peer to peer network that would pay for transport. In essence, it's the wild west, your key pair is your wax seal, and you've given someone $10 to deliver your letter back home to New York. I want to use Bitcoin to hold that $10 in escrow until the letter has been delivered.

I know Bitcoin can do multi-signature transactions but I'm not positive Bitcoin can do what I want, so I turn to this community.

  • Bitcoin gives us public and private keys for secure message delivery.
  • Bitcoin gives us the ability to pay people for transport.
  • We have 3 parties involved. A courier, sender and receiver.
  • We also have two transactions. One of the message from sender to receiver (or a key for said message), and one of the payment from sender to courier.

I'd like to ensure both transactions happen simultaneously. Without trust.

share|improve this question

2 Answers 2

Here is one possible idea that I believe is almost what you want and quite likely (or so I hope!) both good enough and actually particularly good by incentizing all involved parties to collaborate to that goal. The basic idea is to incentize the recipient to sign for reception in a way that prevents him from lying just to collect the incentive.

Use multisig Bitcoin transactions, where the sender sends bitcoin into a multisig address requiring four distinct signatures, one from each party and a special throw-away one. The sender also performs his signature, authorizing a payment to the other two parties (say worth 9 dollar to the courier and 1 dollar to the sender) in a way that not only all other parties have to sign it, but beyond that yet another signature by the sender is required (using a fresh bitcoin address the sender generated only for this message). Instead of keeping the private key, the sender uses the public key of the recipient to encrypt the private key into a cyphertext that only the receiver can decrypt. This is possible with the ECC keys underlying bitcoin, although they are used in bitcoin in a different way, to generate signatures (but alternatively any other asymmetric crypto can be used, e.g. PGP/OpenSSL).

This way, only by completing the delivery can the payment proceed, and the sender cannot withdraw from his commitment anymore. It falls slightly short of what you desired (all payment going to the courier) because without an incentive to bother decrypting and finalizing the payment, it is likely that the recipient simply will not bother, creating significant risk to the courier of not getting paid. But with an incentive, and no means to change the split fraction, we can expect the recipient to usually (and with sufficient incentive, almost always) collaborate, which reassures the courier to go along with the scheme.

The obvious drawback of this scheme is that it requires off-blockchain communication, because (unless I am mistaken), partially signed multsig transactions do not get propagated across the network, and because of the encryption involved in transfering the private key to the fourth bitcoin address. Also, if you were not talking about a physical courier service, this solution does not apply, because having an encrypted communication channel to a sufficiently authenticated recipient (such that the sender already trusts sending to that person) implies that you can already pass any message without a courier as intermediary.

A maybe less obvious drawback is that the cypthertext attached to the message to be delivered must not be easily separated from the two, or your courier (or the wild west bandit robbing him) could just do that, and have only the ciphertext, not your message delivered in the hope that the recipient will collaborate in hiding the nondelivery by signing for collecting the incentive anyways. With digital messages, this can be achieved (e.g. xor the ciphertext with a hash of the message), but then again, for purely data-based messages, you do not need the courier if you have everything necessary for this scheme.

share|improve this answer
    
Ooo I like this - However I'd like a scheme without incentives being the only mechanism. I was thinking the courier and receiver could end up with a package that they could only open together. In that package would be money for the courier and encrypted message for the receiver. –  reconbot Feb 28 at 21:43
    
Also off the blockchain communication is what the courier is for, the point is to incentives the delivery while guaranteeing payment. –  reconbot Feb 28 at 21:51

Seth wants to send Martha a message and is willing to spend 10 BTC to see it delivered. Charlie is happy to deliver it from South Dakota to Michigan at that price. Seth would like to ensure the message is delivered and Charlie wants to ensure he gets paid for his trouble.

They could do the following;

  • Seth signs and encrypts the plaintext message (m1) to Martha into a cyphertext message (c1) using Martha's public key and his private key.
  • Seth further encrypts the cypher text message with a nonce (n1) into a new cypertext message (c2)
  • Seth builds a bitcoin transfer (t1) and adds the nonce (n1) to the transfers comment section and signs it. (t2)
  • Seth then encrypts the signed transfer and nonce (t2) with Charlie's public key into a new message (t3).
  • Seth then encrypts both the encrypted transfer (t3) and the nonce encrypted message (c2) with Martha's public key. This final package is good for shipping (c3)
  • Charlie takes our package to Martha, it's a long trip but the 10btc is worth it.
  • Martha decodes the package (c3) into it's parts the encrypted transfer (t3) and nonce encrypted message (c2)
  • Martha gives Charlie the encrypted transfer (t3)
  • Charlie decrypts the encrypted transfer (t3) into the a signed transfer and nonce (t2)
  • Charlie tells everyone on the plant about the transfer (t2) including Martha. He wants to do this so people know he has the money.
  • Martha takes the transfer (t2) and extracts the nonce (n1) and uses it to decrypt her message (c2) into the signed message (c1)
  • Martha then decrypts the message (c1) again with her private key and gets Seth's letter (m1)

Lets see if I can make this a truth table;

Seth

(m1, seth_pk, martha_pub) => c1
(c1, n1) => c2
(t1, n1, seth_pk) => t2
(t2, charlie_pub) => t3
(t3 + c2, martha_pub) => c3

Martha

(c3, martha_pk) => t3, c2

Charlie

(t3, charlie_pk) => t2

Martha

(t2) => t1, n1
(n1, c2) => c1
(c1, martha_pk) => m1
share|improve this answer
    
I think this answer covers everything. There are a couple flaws (like Seth could double spend before delivery - which may be ok) and I completely ignored BTC contracts. –  reconbot Mar 1 at 5:17
    
Doesn't Charlie have to broadcast the transaction in order to get it in the blockchain? If he doesn't do that Seth could double spend. –  reconbot Mar 1 at 20:22
    
You are right, of course. Mind if I simply delete my previous comment where I somehow missed the point? –  pyramids Mar 1 at 20:51
    
The protocol would benefit from a concise definition of what you mean by "encrypt with a nonce," which isn't exactly how a nonce is used. But from context, it seems clear that instead of a nonce you mean a secret (key), and that you want to encrypt it with asymmetric encryption such that only Charlie can decrypt it. Using Charlie's public bitcoin key should allow doing that, and with that, I don't see any obvious defects. There are more such, well, language issues (e.g., presumably step one is encryption with Martha's public key and signing, not encryption, with Seth's private one). –  pyramids Mar 1 at 20:57
    
Those are valid points =) –  reconbot Mar 2 at 18:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.