March 1, 2014

Wild West Mail Delivery in the Age of Bitcoin

If you saw me talk at ManhattanJS you know I have a dream about a decentralized mesh network that supports decentralized applications that cater to our decentralized behaviors.

There are a lot of parts to this dream, the hardware, the network, the software, the apps, the critical mass. All sorts of things. A ton of things. So I have to start somewhere. hackerchat should be the app with some plugable network backends. The two backends I have are one that works on the local network, and one that works over mesh'd xbees.

Say later we figure out a way to have a truly decentralized network. Say a cellphone to cellphone alternative radio network. (GoTenna seems to be doing this btw.) Maybe bluetooth to bluetooth? I like these ideas, they get us a Mobile Ad Hoc Network. We'll need a routing schemes that incentives efficient delivery and one that tolerates extremely high latency all while keeping security in check.

I'm going to start with incentivizing efficient delivery by leveraging a crypto currency (like bitcoin or namecoin) and it's blockchain.

I posted this to the bitcoin stackexchange.

The problem

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.

The Answer?

I got a cool answer but it required some trust. Over dinner I came up with a possible solution.

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;

  1. Seth signs and encrypts the plaintext message (m1) to Martha into a cyphertext message (c1) using Martha's public key and his private key.
  2. Seth further encrypts the cypher text message with a nonce (n1) into a new cypertext message (c2)
  3. Seth builds a bitcoin transfer (t1) and adds the nonce (n1) to the transfers comment section and signs it. (t2)
  4. Seth then encrypts the signed transfer and nonce (t2) with Charlie's public key into a new message (t3).
  5. 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)
  6. Charlie takes our package to Martha, it's a long trip but the 10btc is worth it.
  7. Martha decodes the package (c3) into it's parts the encrypted transfer (t3) and nonce encrypted message (c2)
  8. Martha gives Charlie the encrypted transfer (t3)
  9. Charlie decrypts the encrypted transfer (t3) into the a signed transfer and nonce (t2)
  10. Charlie tells everyone on the plant about the transfer (t2) including Martha. He wants to do this so people know he has the money.
  11. Martha takes the transfer (t2) and extracts the nonce (n1) and uses it to decrypt her message (c2) into the signed message (c1)
  12. 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;

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

(c3, martha_pk) => t3, c2

(t3, charlie_pk) => t2

(t2) => t1, n1
(n1, c2) => c1
(c1, martha_pk) => m1

The major problem I see is that this isn't composable. Charlie couldn't give the package to someone else and offer to pay them a smaller sum to complete the delivery. But I think we could switch this up so it could be composable. I also need to look into Bitcoin Contracts. Which gives a ton of power to a bitcoin transaction and might negate the need for as complex processes.

I keep thinking about the Diamond Age, it had some cool stuff about crypto and networks. Back to dreaming!

-Francis © 2022.
Powered by NextJS and Vercel.