specs/04.md

BDS-04

Silent Swaps

draft mandatory author:brqgoo

This BDS defines a privacy-preserving, footprint-minimal, offline swap-in mechanism to be used for BitsApp receiving.

Rationale

BDS-01 mandates BitsApp channels to operate one-way-only for the interactivity benefits. This means inbound payments are not allowed for BitsApp channels. Sending on BitsApp is off-chain only, and receiving is on-chain-only. The only way to receive on-chain liquidity through lightning is submarine swaps. However, submarine swaps have many drawbacks:

Receiver privacy

Offline receiving is not possible without compromising privacy.

On-chain footprint

Submarine swaps don't scale. From sweeping funds to opening a channel, overall process consumes 182 vBytes in a HTLC-based approach and 142 vBytes in a PTLC-based approach:

Type	Output	Outpoint	Redemption	Channel output	Total
HTLC-based submarine swaps	43 vBytes	40 vBytes	56 vBytes	43 vBytes	182 vBytes
PTLC-based submarine swaps	43 vBytes	40 vBytes	16 vBytes	43 vBytes	142 vBytes

Specification

This BDS proposes a replacement for submarine swaps; silent swaps. Silent swaps are effectively a specialized form of submarine swaps, however, built in mind with scaling and privacy. Silent swaps utilize a channel factory approach to save massively on fees and space and use ECDH to enable offline receiving while preserving recipient privacy.

The sender non-interactively pays the recipient based on their dedicated Nostr pubkey npub without revealing the npub itself, similar to silent payments. The recipient can get paid without inbound liquidity issues, doesn't need to remain online to receive, and their npub is not doxxed to the rest of the network. When a sender wants to pay the recipient, the sender initiates a swap-in payment through a specialized submarine service provided by BitsApp SSP. Here's how it's done step-by-step:

1. The sender first generates a preimage and a tweaked destination:

• Where the recipient npub is R = r*G , and the sender npub is S = s*G.
• The sender generates a 32-byte random element rand
• The sender calculates a tweaked pubkey for the recipient: R' = hash(s*R, rand)*G + R.
• The sender generates a shared preimage secret for the recipient : P = hash(rand)*G + R
• The sender S then sends a NIP-04 encrypted DM to the recipient containing rand and payment value.
• The recipient R can locally construct his tweaked pubkey R' and preimage P from the rand value, and the sender's npub S.

Although it seems similar to keysend due to the sender generating the preimage, the proof of payment here is not the revealed preimage but the on-chain transaction (swap factory) itself.