One-way Payment Channel

[chenyukang]

1. Background and Motivation

Payment channel networks like the Lightning Network allow for fast off-chain settlements but require both parties to remain online to monitor channel states and prevent the submission of outdated states. This is not user-friendly for average users who only go online when needing to make a payment and cannot run nodes 24/7.

In the CKB Fiber Network, we aim to provide a lightweight payment capability that allows users to initiate payments to any node without staying online. This design proposes a One-way Payment Channel Model, where a user establishes an off-chain channel with a continuously online Fiber node. The user’s balance can only decrease, and the Fiber node acts as a proxy to complete payments.

2. Core Concepts

The channel is One-way, meaning funds only flow from the user to the Fiber node. Since the Fiber node’s balance can only increase monotonically as the channel updates, the Fiber node would lose money if it attempted to broadcast an old state. This implies:

• No economic incentive to cheat: Fiber node loses balance if using old states.
• No Watchtower required: Users do not need constant monitoring.
• No Punish/Revocation mechanism: Standard LN-style penalty transactions are unnecessary.

Furthermore, HTLCs (Hashed Timelock Contracts) are used as conditions for internal state updates, ensuring the Fiber node only receives funds after successfully completing a payment and obtaining a preimage.

3. Participants

Role	Description
User	Intermittently online; does not bear routing or monitoring duties.
Fiber Node	Online 24/7; maintains routing and executes payments for users.
Target Node	Any Fiber node supporting HTLC payments.

4. Channel State Structure

The channel state maintains the following data:

{
    user_balance,
    fiber_balance,
    pending_htlcs: [
        { amount, hashlock, timelock }
    ]
}

pending_htlcs represents pending payment requests initiated by the user.

5. Payment Process (LN-style Off-chain Signature Update)

Step 0: Channel Initialization

User and Fiber node create a Cell with initial state:

• user_balance: N, fiber_balance: 0, pending_htlcs: [].

Step 1: Invoice Acquisition

User receives an invoice containing: hash = SHA256(preimage) and amount = A1.

Step 2: Proxy Request

User sends the complete invoice to the connected Fiber node.

Step 3: HTLC Pending State

The channel state is updated:

• User's balance is temporarily frozen (decreased by amount).
• The Fiber node only gains the amount upon proof of successful payment.

{
    user_balance: N - A1,
    fiber_balance: 0,
    pending_htlcs: [ { A1, hashlock, timelock } ]
}

Step 4: Routing

Fiber node initiates the HTLC payment through the network.

Step 5: Obtaining Preimage

Upon success, the target node returns the preimage.

Step 6: Finalizing Update

Fiber node submits the preimage to the channel:

• HTLC is removed from the state.
• Fiber node's balance is officially increased.

{
    user_balance: N - A1,
    fiber_balance: A1,
    pending_htlcs: []
}

Consecutive payments will continue to update the balance accordingly.

6. Security Analysis

Attack Scenario	Result	Reason
Fiber broadcasts old state	Loss for Fiber	Old states have lower fiber_balance.
Fiber fakes success	Cannot claim funds	preimage is the unique required proof.
Fiber delays closing	User can unilateral close	User can trigger close + timeout.

To prevent users from submitting old states to reclaim funds, a timelock restriction can be added, allowing the Fiber node a window to respond with the latest state.

7. Adaptability and Network Significance

This mechanism makes Fiber nodes replaceable and competitive payment proxies:

• Users can choose any Fiber node for their channel.
• Fiber nodes earn fees only upon successful payment delivery.
• Fiber nodes form a decentralized payment network via HTLC routing.

This model maintains the economic incentives of the Lightning Network while remaining extremely user-friendly.