Skip to content

Support Bitcoin BIP340 keypairs as identities in the DHT #211

@lukechilds

Description

@lukechilds

BIP340 Schnorr signatures are used in Bitcoin and derived to taproot addresses: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

They are also used in Nostr for identities and derived into npubs https://github.com/nostr-protocol/nips/blob/master/01.md

If the Hyperswarm DHT enables BIP340 identity resolution an entire class of Bitcoin and Nostr applications can make use of Hyperswarm, the implications are quite large. It can be used to solve Nostr's major relay discovery problem. It can be used to facilitate P2P communication between participants in complex interactive Bitcoin protocols like musig2 offchain multisig nonce sharing, DLC signature sharing, atomic swaps. It can also be used to resolve a known Bitcoin address to a Hypercore that allows querying reusable offchain address like Ark or Lightning, improving payment privacy. The possibilities are huge.

BIP340 signatures are optimised to be small (64 bytes) to preserve Bitcoin block space so fit well within the Hyperswarm requirements of being in a single UDP packet (1KB).

There are very mature and well maintained C libraries for interacting with Bitcoin's secp256k1 curve: https://github.com/bitcoin-core/secp256k1

As well as pure JavaScript variants: https://github.com/paulmillr/noble-secp256k1

This change should allow making direct P2P connections over the Hyperswarm DHT to peers based on their BIP340 pubkeys which can be derived from a Bitcoin taproot address. It should also allow syncing a Hypercore from a BIP340 public key.

Example

Alice starts listening on the DHT and is addressable by her BIP340 pubkey

const keyPair = bitcoinKeypair(aliceBitcoinPrivateKey)
const swarm = new Hyperswarm({keyPair})

Bob can now make direct P2P connections to Alice through the DHT with knowledge of her taproot address

const alicePubkey = decodePubkey(aliceTaprootAddress)

const swarm = new Hyperswarm()
swarm.joinPeer(alicePubkey)

Alice and Bob now have an encrypted bidirectional communication channel that was established through the Hyperswarm DHT with knowledge only of the others Taproot address.

It should also be possible to interact with a Hypercore via BIP340 pubkey so you can resolve a static Bitcoin taproot address to other more private payment addresses

const alicePubkey = decodePubkey(aliceTaprootAddress)

const core = new Hypercore(RAM, alicePubkey)
const alicePaymentProtocols = new Hyperbee(core)

alicePaymentProtocols.get('bolt12')
// 'lno1zrxq8pjw7qjlm68mtp7e3yvxee4y5xrgjhhyf2fxhlphpckrvevh50u0qwnsha0tuuzrkh086l3lgsm3ezwvsnvc9tseezma2f3ptww2ngqq7qszwczwcquwd2gq3stnm6nvp6lme5gnyj8n396mk9rd0090vqqck4vsqvcydp6qkwzh32tz740gwwl70dllg3qukpuezep3amk2afmh3f50y99c2pqlupanxuvce6zewxcf7vhk255wqtlxahzqnvczydzqju6h3aa7cagwl4n6v54hqdg40nql7vt3v3uekqqsss3mtxynjw6cgtc9eznkchlmls'

This allows Bob to resolve Alices static taproot address into a reusable bolt12 lightning offer.

Notes

Ideally the same BIP340 public key should be able to be used for both Hyperswarm and Hypercore connections since this is really powerful to enable P2P communication or data sharing with knowledge only of the other participants BIP340 public key (encoded as a taproot address) but no other way to communicate with them and potentially allowing them to be offline.

e.g maybe Bob is offline but Alice wants to query his Hypercore to get a reusable payment address and some other peer has Bobs Hypercore replicated and can serve the request. Maybe Bob then comes online and Alice wants to get a direct P2P Hyperswarm channel with him to share nonces to do collaborative offchain multisig signing.

Ideally this would be possible without needing seperate public keys. I'm not sure if Hyperswarm can already do this, if not, potentially it's possible by having the identifier be something to the effect of hash(pubkey + 'hypercore') or hash(pubkey + 'hyperswarm') to get unique DHT keys that are valid for the same pubkey.

If this is something you would be interested in supporting natively in the DHT it would open up a huge amount of possibilities for what could be built on top. Let me know if you have any questions. Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions