Bitcoin Integration Guide

This is a work-in-progress

Encrypted Peer Connections

High-level ideas on how to use telehash to encrypt connections to the bitcoin network:

  • upon startup an endpoint should generate a new hashname to identify it to the network for that session
  • if an endpoint has prior/OOB context of the keys to a known ip/port, it should attempt an encrypted connection first, and fallback to a traditional tcp socket
  • when using a traditional tcp socket, an endpoint should embed its current hashname keys in base58 in its agent string
  • when receiving keys in a user agent string, a new encrypted connection should be attempted and replace the current one
  • TBD, add an encrypted bit to the advertised services so that its support is propogated
  • TBD, show how to use a channel to send/receive messages in parallel over a link

Hashname Pinning

When a hashname needs to be associated to a transaction it can be included as an OP_RETURN output by generating a random 8-byte nonce and processing the 32-byte hashname with the ChaCha20 cipher. The key input must be a common or private shared value used by the parties generating the transaction as well as validating it, as determined by the needs of the application.

The result is the 40 bytes for the OP_RETURN value, the 8-byte nonce followed by the 32-byte encrypted hashname.

This transaction acts as a reference that can be independently validated by anyone with the key input as a public lock to a single hashname.

Chain of Custody

The blockchain may be used in combination with telehash to form a chain of custody from the bitcoin values/wallets to specific hashnames. This is similar to pinning, but the hashnames in custody are always kept private and never recorded in the blochain.

  • create an original genesis transaction that begins the chain of custody and serves as the parent fixture/reference id for all parties
  • every transaction has only two outputs, the refund output and the custody output
  • the custody output must be a P2SH with whatever associated value is relevant to the current chain

In order for any hashname to assert that it is in current custody of the chain to another, it must create and sign a valid new transaction that uses the most recent confirmed transaction's P2SH custody output as it's input, and a single OP_RETURN output of the 32-byte hash of the sender+recipient hashnames appended, with a 0 value associated so that the transaction cannot be accidentially broadcast (note: what is a better way to validate but prevent ever broadcasting?)

The recipient must fully validate the transaction, verify that the input(s) are correct and output hash is correct, as well as the chain of transaction input/outputs leads back to the shared genesis transaction.