[DIS] fiber-payjoin-kit: Collaborative Channel Funding Privacy for the Nervos Fiber Network RES

DAOs & Funding CKB Community Fund DAO
1

[DIS] fiber-payjoin-kit: Collaborative Channel Funding Privacy for the Nervos Fiber Network RESub

Executive Summary

When a Fiber Network payment channel is opened, the funding transaction is permanently recorded on CKB Layer 1. Standard channel openings use a single funder, all CellInputs belong to one wallet. Chain surveillance tools use this to identify who opened the channel and cluster their complete transaction history.

fiber-payjoin-kit is an open-source Rust library enabling collaborative channel funding on the Nervos Fiber Network. Both parties contribute CellInputs to the funding transaction, making chain attribution impossible.

This proposal requests $6,000 for Phase 1: the core coordination primitive and two working end-to-end demos against a real Fiber node.

Funding Request

Component Amount Purpose
Phase 1 — Core Primitive + Demos $6,000 CellInput coordination engine, Fiber node demos, documentation

1. The Problem

Standard Fiber channel funding exposes the funder permanently on CKB L1:

Standard channel open:
CellInput: Wallet_A  (100 CKB)  ← single funder, permanently tagged
Output:    Channel script

Collaborative channel open:
CellInput: Wallet_A  (60 CKB)  ─┐
CellInput: Wallet_B  (40 CKB)  ─┴─ who funded what? impossible to determine
Output:    Channel script

Two concrete pain points the community has raised:

Fee-contribution deadlock: A user wanting to open a channel may have CKB locked in large UDT cells with insufficient liquid CKB for on-chain fees. Collaborative funding allows the counterparty to contribute a fee-covering Cell, unblocking channels that would otherwise fail at fee estimation.

Funding origin exposure: Every channel opening creates a permanent on-chain link between the funder’s wallet and the channel — an operational security risk for any privacy-conscious node operator or user.

2. The Solution

fiber-payjoin-kit runs as local middleware. The Fiber node is unchanged. Both parties coordinate CellInputs before the funding transaction is broadcast, following Fiber’s existing TxUpdate/TxComplete negotiation flow.

Per direct feedback from jjyr on the CKBuilder-projects review: working at the Cell model level using unsigned CellInput payloads is the correct boundary. Fiber’s funding process is built directly on CKB transactions with no higher-level coordination hook — this is the right instrumentation point.

Non-interactive fallback: if the counterparty is offline, the library falls back to standard single-funder channel opening with no broken payments.

3. Why Us — Proof of Execution

Following the feedback’s that the community needed to see a working Lightning implementation first, we built lightning-payjoin-kit.

That implementation is now complete:

  • Real two-node LDK harness (tests/ldk_two_node_harness.rs): two actual LDK ChannelManagers reach a usable channel through a collaboratively-funded transaction
  • Full flow: FundingGenerationReady → collaborative PSBT → LdkManualFunding → FundingTxBroadcastSafe → usable channel
  • Bitcoin Core regtest: Docker bitcoind accepts and mines the collaborative funding transaction
  • 14 test files covering every layer of the stack

Implementation notes: lightning-payjoin-kit/IMPLEMENTATION.md at main · ILE-Labs/lightning-payjoin-kit · GitHub

How this differs from payjoin/nolooking:
payjoin/nolooking is a server-side LSP model requiring a centralized operator. lightning-payjoin-kit is client-side, coordinating directly between the two parties with no trusted intermediary. It also enforces a commitment-safety boundary that the LSP model does not address. On CKB, coordination uses unsigned CellInput payloads rather than PSBT, with Cell-Deps validation specific to CKB’s model.

4. Development Roadmap

Phase 1 — Core Coordination Primitive

Deliverable 1 — Coordination Engine ($4,000)

  • Two-party CellInput coordination: propose → contribute → validate → sign → finalize
  • Counterparty proposal validation: amount, script integrity, input checks
  • TxUpdate/TxComplete flow instrumented for wallet developer visibility
  • Non-interactive fallback when counterparty is offline
  • Full unit test coverage, devnet broadcast confirmed

Deliverable 2 — Fiber Node Demos and Documentation ($2,000)

  • Demo A: fee-contribution scenario — collaborative funding solving the CKB fee deadlock
  • Demo B: privacy channel opening — multi-input funding via real Fiber node
  • Both demos show TxUpdate/TxComplete message flow so wallet developers can inspect and adapt
  • Architecture documentation, README, integration example

Phase 2 — Separate Future Proposal

Fiber P2P async relay, CLI tooling, wallet integration examples, mainnet deployment.

5. About the Team

ILE Labs — ILE-Labs · GitHub

Charles Emmanuel — Project Lead
GitHub: @CodexEmmzy | Telegram: @charlesCode

Onyekachukwu Nweke — Protocol Lead, Lightning Network and threshold signatures
GitHub: @Onyekachukwu-Nweke

Bolaji Ahmad — Blockchain Engineer, CKBuilders programme participant
GitHub: @bolajahmad

Open-source work: lightning-payjoin-kit (complete), foc-devkit (Filecoin), mx-tx-simulator (MultiversX, fixed 4 upstream SDK bugs), stylus-debug-suite (Arbitrum, live on crates.io)

6. Risks

Risk Mitigation
Fiber node API changes Demos scoped to current TxUpdate/TxComplete interface
CellInput edge cases vs PSBT Lightning PoC proves state machine; CKB differences isolated in Cell adapter layer

About This Resubmission

We submitted this proposal in May 2026 but did not receive enough community votes within the 7-day window to advance. Following feedback from everyone, we have made three significant changes:

  • Reduced scope to a Phase 1 proof of concept only, with a reduced ask of $6,000
  • Built the Lightning equivalent (lightning-payjoin-kit) first as proof of execution — a working two-node LDK harness is now complete
  • Incorporated direct technical feedback on the correct instrumentation point and concrete user pain points to target

Email: [email protected] | Telegram: @charlesCode

15 Likes
CKB Ecosystem Biweekly Update
[DIS] fiber-payjoin-kit: Collaborative Privacy for the Nervos Fiber Network
CKB Ecosystem Biweekly Update
2

I’m impressed by your proposal to renovate Fiber privacy and channel creation completion, but I was noticed by your claim of DON’T change Fiber node, however, implementing those aims cannot deflect from changing Fiber’s on-chain script logic and payload.

So, I’m curious about how will you guys move forward upon this topic? Any technical details for clarification?

1 Like
3

Thanks to everyone who reviewed this. The feedback on our “no Fiber node changes required” claim was fair, and we’re revising the claim rather than defending it.

Having now read through the funding path properly, update_for_peer in crates/fiber-lib/src/ckb/funding/funding_tx.rs, limits.rs, get_funding_lock_script in fiber/channel.rs, and docs/external-funding.md, we agree that the claim was too broad in two specific ways.

First, a channel open is self-identifying on-chain regardless of what happens to the inputs. The funding cell uses Contract::FundingLock with a fixed code_hash and matching cell_dep, meaning a single indexer query can enumerate every open channel with its capacity visible. For public channels, ChannelAnnouncement already publishes the channel outpoint alongside both node keys, making funding-transaction privacy moot there anyway.

Second, the transforms our PoC applies cannot be performed by an external library during a live channel open. The funding transaction is built and driven by the two nodes through TxUpdate/TxComplete; open_channel_with_external_funding returns a structurally frozen transaction where external signers may only fill witnesses; and the funding-lock args are derived from the MuSig2 public keys exchanged during the handshake, so they cannot be computed externally.

What we did find encouraging is that the shape of our responder contribution, appending inputs, appending one change output, and leaving the funding cell at index 0, is already legal under the existing validation rules. verify_peer_funding_contribution already permits a peer to add inputs with zero net contribution to the channel. The obstacle is who performs the contribution, not what the contribution does.

We are restructuring the work into three tiers and scoping our commitment to Tier 1 only.

Accordingly, we’re restructuring the work into three tiers and scoping our own commitment to Tier 1.

Tier 1 requires no fnn changes. The collaborative construction moves entirely outside the channel open, into a separate ordinary payment transaction whose output then funds the channel through open_channel_with_external_funding / submit_signed_funding_tx, which shipped in v0.9.0. The PayJoin counterparty does not need to be the channel peer at all.

Tier 2 is a responder-side privacy-contribution policy in the accepter’s funding builder. This does require node changes on both sides, so we would propose implementing it behind an opt-in feature bit, following the pattern established in #1311, rather than enabling it by default.

Tier 3 is funding-cell indistinguishability,. This requires the on-chain script and payload changes that reviewers correctly identified, and we think it belongs in its own proposal and security review rather than being folded into a tooling proposal.

For Tier 1, to be precise about what it actually provides: It applies only to unannounced channels. It does not hide the fact that a channel was opened or its size. A tuned indexer can still detect that collaborative construction occurred, and the honest claim is that it raises the attribution cost from a single indexer query to sustained chain analysis combined with side information, producing probabilistic rather than deterministic attribution.

Ultimately, the anonymity set, not the protocol itself, is the real security parameter. That is why we now intend to ship this as a general CKB PayJoin library, with Fiber channel funding as its first adapter, rather than positioning it as a Fiber-specific tool.

2 Likes
4

Thanks to your response and clarification, I’m not sure, for Tier 1, you guys intend to change the transaction structure received from open_channel_with_external_funding and send it back with submit_signed_funding_tx, if so, I’ll tell this operation is denied by Fiber protocol, that means no more Inputs and Outputs changes but only open for changes on Witnesses.

So I really hope this concern is carefully considered within your future plan. Good day.

1 Like
5

Thank you all for your attention to details on our proposal.

Since posting the tiered restructure, our team completed a deeper measurement pass against CKB mainnet data. We identified only 8 genuinely collaborative transactions across 6.5 years of chain history, and 98 Fiber channel opens in 90 days from just 4 addresses in 2 pairs. The anonymity set required for this approach to provide meaningful privacy protection does not yet exist on CKB.

We have decided not to build the product at this stage. Instead we will publish the measurements and analysis as open research, which we believe is more valuable to the ecosystem than shipping it as a product.

We appreciate the community’s honest engagement throughout this process. When on-chain collaborative transaction volume grows, the foundation we have laid may become meaningful.

1 Like