# PDK Community Strategy Sync

## Strategy Canvas

Compared to other strategies for **breaking Common Input Heuristic**

### Current Strategy:

## Tech as a tool to break CIH as a privacy tool
*KEY: 🟣 Payjoin, 🟡 Lightning, 🟢 equal amount CoinJoin

        Low - - - - - - - - - - - - - - - - - - - - High

Cost (sats)     🟣        🟡                      🟢

Ubiquity        🟢 🟣                      🟡

Personal Privacy     🟡                 🟣      🟢

Network Privacy   🟢          🟣🟡               

Ease of Use     🟢           🟡        🟣

Overt           🟣            🟡                     🟢

Systemic Support    🟢      🟣           🟡

Interactivity               🟣              🟡      🟢

I have an idea of how we can move forward

Resolve differences of opinion about the current state of play.

#### Feedback

- Coinjoin operators are shutting down
- Coinjoin has footguns and toxic change and ways to do it wrong
- interactivity & fees add a mental burden

Can rank values: Overt/covert, Ease of Use , ... price seems less important

#### Dan After Chart

             low - - - - - - - - - - - - - - - - - - - - - high

*Price           🟣        🟡                      🟢

Ubiquity        🟢 🟣                      🟡

Personal Privacy     🟡               🟢        🟣*

Network Privacy   🟢          🟡                🟣

Ease of Use     🟢           🟡        🟣*

Overt           🟣            🟡                     🟢

Systemic Support    🟢            🟡        🟣*

*Interactivity               🟣              🟡      🟢

Ease of Understanding 

## Four Actions Framework

### Eliminate

- Wallet-specific dependency

### Reduce

- Mixer/Ciphepunk marketing
- Spending costs & blockspace use ❓
- Barriers to adoption (language environment dep, )

### Raise

- Civic engagement and cultural contrubutions ❓
- Wallet Support
- Tooling & Software Support

### Create

- Widget for use without a specific wallet integration
- Educational resources, Plan B Network, Demo videos, Payjoin Playlist channel
- Walkthrough

## Six Paths to Reconstruct Market Boundaries

Look across...

### Path 1: Alternative Industries

- Batching\Fireblocks/custodians/BitGo
- Stablecoins
- StateChains
- OpenDimes
- Cash / Coins
- jurisdictional arbitrage, overseas bank relationship
- Dark Pools (Private Securities exchanges)
- Algorithmic Trading
- gold
- Other cryptocurrency e.g. Monero / Tornado Cash
- Gift Cards
- Privacy.com virtual credit cards
- Art / NFT hodling and exchange
- Trusts

### Path 2: Strategic groups

- Centralized CoinJoin (Wasabi, Samourai)
- "Decentralized" JoinMarket
- Sidechains (Liquid, Botanix)
- Swaps (boltz)
- Lightning service providers
- Ecash wallets
- OpenDimes
- Statechains
- CoinPools?

### Path 3: Across the Chain of Buyers

- Exchanges, Trading Desks, Brokers
- Soverign Individual types
- Casinos
- Remittance Providers
- Merchants
- Payment processors
- Funds

two main buyer groups: cypherpunks & Bitcoin Service Businesses

Note: commercial entities seem overrepresented and underserved here

### Path 4: Complementary Product & Service offerings

- eCash Mints
- VPN
- Encrypted Email / Calendar / Storage
- Password manager
- Lightning liquidity / LSP
- Wallet / CoinJoin
- Buying / Selling Bitcoin Exchange
- Fireblocks MPC Custody
- Unchained Multisig Custody
- custodians
- stable sats / derivatives
- Hardware manufacturers (Signers, Nodes, Miners)

### Path 5: Functional or Emotional Appeal to Buyers

- Human Rights
- High Net Worth Security
- Saving Sats
- Scaling Bitcoin
- UTXO Management is too complex / need to learn about it
- Being part of a movement (think Lightning Torch to learn how it works)
- Bitcoin Scaling concerns
- Cipherpunks
- "For the Streets" 🤢
- The Paranoid
- Savers, Security for wealth management, retirement
- An institutional sense of safety

### Path 6: Across Time

Look at *Irreversible* trends with a *clear trajectory* that are *decisive* to our operation

- More attention from regulators & financial institutions
- Wallets supporting more interactivity
- Non-monetary use of Bitcoin (inscriptions, metadata storage)
- Bitcoin URI `bitcoin:<Address>?amount=<Amount>&=pj=...` BIP21 Payment options becoming more numerous, addresses are proliferating
- Payments on l2 separating from settlements on l1
- More expressivity in bitcoin script
- Blockspace becoming more expensive / in demand
- Number go up (same sat fees become more expensive in \$)
- Cost of entry cost to hold utxo

## Tagline

Privacy preserving payjoin batching could save the network 30% or more in transaction fees.

Simple batching to scale bitcoin, cut costs and preserve privacy

scale bitcoin

cut costs
save fees
save satoshis
save sats

"keep it private"
Protect data

Scale Bitcoin is relevant

## Three Tiers of Nonconsumers

Who isn't using the product yet that could?

### First: non-implementing wallets

- Sparrow
- BTCPayServer
- Nunchuk
- Bitcoin Core
- BullBitcoin
- Galoy
- Boltz

wallets should be fighting each other to integrate first
Could that inspire pressure to integrate?

### Second: Bitcoin businesses

- Block / Cash App
- Swan
- Unchained
- Casa
- Fireblocks
- coinbase

these guys want to protect their competitive edge

### Third: Settlement layer

- BlackRock super funds
- Microstrategy
- Central banks, treasuries / finance ministries, soverign wealth funds

these guys want the highest security & maturity imaginable

## Widget or "Headless" Wallet? Boneless? Walletless, Keyless?

All of our payjoin integrations have been dependent on a specific wallet coupling to payjoin logic. What if we released a web app to handle any wallet that could deal with PSBTs and just handle the networking for you?

Put regular & payjoin side by side. Show sats savings, time savings, privacy statistics. NUMBERS! visualization like mempool.space can show funds move. Examples help

Bar chart for relative costs (payment + consolidation vs payjoin, cut-through, etc.)

## Oblivious HTTP with secp256k1 Hybrid Public Key Encryption (HPKE)

The BIP 77 review is going well. It differs from the implementation in that the spec requires secp256k1 HPKE but the implementation uses off the shelf ed25515 DHKEM(Curve25519, HKDF-SHA256) which is the HPKE standard. We want to use secp256k1 since every bitcoin wallet already uses this cryptography so it can reduce our dependency. We'll have to port [rust-hpke](https://github.com/rozbb/rust-hpke) or build a new crate to support this curve if we agree with this logic.

The IETF [draft for secp256k1-based DHKEM for HPKE](https://datatracker.ietf.org/doc/draft-wahby-cfrg-hpke-kem-secp256k1/00/) has also expired. A new discussion bringing this up in the context of bitcoin core would be valuable

Can use hkdf from bip 324 https://github.com/rust-bitcoin/bip324/tree/main/protocol