TSP-0010 — PTLC

Proposal Number: TSP-0010

Proposal Number: TSP-0010
Proposal Name: PTLC (Point Time-Locked Contract) Contract Specification
Category: Consensus (C) — pre-Oct 2025 numbering retained as 000x
Status: Draft
Author: Tondi Foundation Development Team & Avato Labs
Created: 2025-09-05
Target: Tondi Frontier (v2026a)
Scope: PTLC contract specification, adaptor signatures, Taproot compatibility, MuSig2 integration, cross-chain atomic swaps

1. Abstract

This proposal defines the complete specification for implementing PTLC (Point Time-Locked Contract) on the Tondi network. PTLC replaces traditional HTLC hash preimage conditions with elliptic curve point conditions, using Schnorr adaptor signatures to achieve "off-chain conditional negotiation with minimal on-chain disclosure." The specification covers: script and spend templates, adaptor signature interactions, timeout refund paths, cross-chain atomic swaps and DLC/oracle integration, standardization and policy recommendations, security and testing points. PTLC is compatible with Tondi's Taproot-only design and introduces no new opcodes or consensus modifications.

2. Motivation

HTLCs have limitations in privacy and composability:

  • Linkability: The same hash preimage across multi-hop routing enables correlation analysis;
  • Probing and Sandwich Attacks: Exposed hash conditions facilitate channel probing;
  • Distinct Script Appearance: HTLC script forms are easily identifiable and censorable;
  • Limited Multi-Path Aggregation: Hash preimage reuse reduces privacy.

PTLC shifts conditions from "hash values" to "curve points Y = y·G" and couples them off-chain via adaptor signatures, so on-chain only a regular Taproot Key-Path signature appears (indistinguishable from conventional payments), thereby:

  • Significantly enhancing privacy (no leaked scripts or conditions);
  • Naturally integrating with MuSig2 for complex routing and splits;
  • Seamlessly combining with DLC/oracle signatures for expanded contract expressiveness;
  • Applicable to cross-chain atomic swaps (BTC ↔ Tondi, Tondi ↔ EVM, etc.).

3. Terminology and Notation

  • G: secp256k1 base point; n: its order;
  • BIP-340 Schnorr: Signature (R, s), where s = k + e·x (mod n), e = H(R∥P∥m);
  • Adaptor Signature: Given public point Y = y·G,
    • Pre-signature σ̃ = (R, s*) can be completed to valid signature σ = (R, s) upon knowing y;
    • Given σ̃ and σ, y can be extracted;
  • Key-Path: Taproot key-path spend; Script-Path: TapLeaf path spend;
  • CLTV/CSV: Absolute/relative time locks;
  • Participants:
    • Payer A (possibly previous hop in routing), Payee B (next hop/endpoint).

Note: This draft follows common Schnorr adaptor signature constructions; implementation details align with standard references (see §11 References).

4. Specification Overview

PTLC outputs consist of two parts:

  1. Immediate Claim Path (Key-Path): B, upon receiving A's σ̃ and public point Y, can spend on-chain with a regular signature only after obtaining the discrete log y (appearance identical to conventional payments).

  2. Timeout Refund Path (Script-Path): If B does not claim before deadline T, A refunds via a TapLeaf path including CLTV.

This design ensures:

  • Minimal on-chain disclosure (Key-Path spend shows only (R,s));
  • Clear failure fallback (Script-Path with CLTV single/multi-sig script);
  • No new consensus rules (see §9).

5. Output Template

5.1 Taproot Structure

  • Internal key P_int: Single key or MuSig2 aggregated key;
  • Commitment tree (optional): Includes one refund leaf Leaf_refund;
  • Output public key: P_out = TapTweak(P_int, merkle_root).

5.2 Refund Leaf (Recommended Template)

// Absolute time lock refund (CLTV):
<T> OP_CHECKLOCKTIMEVERIFY OP_DROP <P_refund> OP_CHECKSIG
  • T: Absolute block height or timestamp; literal in script;
  • P_refund: A's (or participants' MuSig2 public key).

Relative time lock (CSV) alternative: OP_CHECKSEQUENCEVERIFY OP_DROP <P_refund> OP_CHECKSIG.

6. Witness and Spend

6.1 Immediate Claim (Key-Path)

  • On-chain witness: [sig_B] (BIP-340 standard signature).
  • Off-chain condition: B can only complete σ̃ to valid sig_B upon obtaining y.

6.2 Timeout Refund (Script-Path)

  • On-chain witness: [sig_refund] [script] [control_block];
  • Validity condition: Transaction nLockTime ≥ T (or nSequence ≥ D for CSV).

7. Adaptor Signature Protocol (Normative)

This section provides the minimal required flow for two parties; MuSig2 scenarios in Appendix A.
7.1 Public Parameters

  • Message m = Sighash(tx, input_index, flags);
  • P (valid public key for Key-Path, single or aggregated);
  • Public point Y = y·G (provided by upstream/oracle/counterparty).

7.2 Pre-Signature Generation (by A)

  1. Generate random k and compute R = k·G (BIP-340 recommended deterministic + aux_rand scheme);
  2. Compute challenge e = H(tag_ptlc || enc(R) || enc(P) || m || enc(Y));
  3. Compute pre-signature scalar s* = (k + e·x) mod n, where x is the private key or aggregated share for P;
  4. Output pre-signature σ̃ = (R, s*) and public point Y to B;
  5. Security recommendation: A should domain-separate σ̃ (see §10.4).

Note: Uses straightforward "additive" adaptor: final signature s = (s* + y) mod n.

7.3 Completion and On-Chain Claim (by B)
Upon obtaining y:

  1. Compute s = (s* + y) mod n;
  2. Generate valid Schnorr signature σ = (R, s);
  3. Spend the output via Key-Path (see §6.1).

7.4 Extract y (by A)
Upon seeing σ = (R, s) on-chain or off-chain, with held σ̃ = (R, s*):

  • Compute y = (s − s*) mod n;
  • Obtain the discrete log y consistent with Y = y·G, usable for subsequent on-chain/cross-chain claims.

This "extraction" property ensures cross-chain atomicity: Claim on one chain reveals y, enabling counterparty (or upstream) claim on another (see §8).

8. Cross-Chain and Oracle

8.1 Cross-Chain Atomic Swaps (BTC ↔ Tondi Example)

  • Parties deploy one PTLC output on each chain using the same Y;
  • Set timeout gradient: Tondi's refund height T_ton earlier than BTC's T_btc, ensuring failure rollback;
  • Upon B claiming with Key-Path on one side, A extracts y via s − s* and completes claim on the other;
  • On timeout, parties take respective chain's Script-Path refunds.

8.2 Oracle/DLC Integration

  • Let Y = Y_oracle be the oracle-published point (or multi-oracle aggregated point);
  • Upon event occurrence, oracle releases y (or computable from its signature);
  • Any holder of σ̃ can complete and claim;
  • Avoid cross-event reuse via point aggregation and message binding (Y = H(event)·G or include event tag in σ̃ domain separation).

9. Consensus Impact and Standardization

  • Consensus Layer: This proposal introduces no new rules; Key-Path spends are standard BIP-340 signatures; refund leaves use BIP-342 opcodes (CLTV/CSV, etc.);
  • Standardization Policy:
    • Key-Path spends: Treated as conventional;
    • Refund leaves: Recommend following existing standard script templates (single/multi-sig + CLTV/CSV);
    • Relation to OP_SUCCESSx: This proposal is independent; if scripts include SUCCESSx, follow Tondi's policy restrictions (see separate proposals).

10. Security and Implementation Notes

10.1 Nonce Security

  • Use BIP-340 recommended deterministic nonces including aux_rand, ensuring single-use per message;
  • Prohibit k reuse; in MuSig2, use secure joint nonce protocol (see Appendix A).

10.2 Adaptor Signature Uniqueness

  • σ̃ must bind to m, P, Y (via domain separation tags or m' = H(tag ∥ m ∥ enc(Y)));
  • Prevent party reuse of σ̃ in different contexts leading to exploitable correlation attacks.

10.3 Extraction Robustness

  • A should validate (R, s) as a valid Schnorr signature before extracting y;
  • Execute y = (s − s*) mod n only upon verification.

10.4 Domain Separation
Recommend the following tag:

  • tag_ptlc = "TSP-0010/PTLC/adaptor";
  • Set e = H(tag_ptlc ∥ enc(R) ∥ enc(P) ∥ m ∥ enc(Y)) during pre-signature;
  • Or explicitly record enc(Y) and m in s* computation/storage for auditing and replay protection.

10.5 Time Lock Selection

  • Refund time T (or D) should satisfy cross-chain/multi-hop routing safety windows;
  • Typical recommendation: Downstream shorter than upstream; in cross-chain, priority claim chain uses shorter refund time.

10.6 Failure and Rollback

  • If B does not claim, A can take Script-Path refund after T;
  • Wallets should automatically monitor expirations and pre-build refund transactions (RBF/CPFP supported).

11. Compatibility and Wallet Specification

  • Addresses and Outputs: Conventional Taproot addresses;
  • Signatures: BIP-340; aggregation recommends MuSig2;
  • SIGHASH: DEFAULT or ALL; compatible with RBF/CPFP policies;
  • Identification and Marking: Wallets may internally mark "PTLC output" for expiration monitoring;
  • Privacy: Indistinguishable on-chain externally; logs should avoid leaking Y and σ̃.

12. Reference Implementation (Pseudocode)

Note: The following is normative pseudocode showing APIs and key equations; actual code must use audited secp256k1/Schnorr and MuSig2 implementations.

// Encodings: bytes32 for scalars, bytes33 for points (x-only where applicable)

function AdaptorPreSign(sk_x, P, m, Y):
    k  <- NonceGen(sk_x, m, aux_rand)
    R  <- k*G
    e  <- H(tag_ptlc || enc(R) || enc(P) || m || enc(Y)) mod n
    s* <- (k + e*sk_x) mod n
    return (R, s*)

function AdaptorComplete(preSig=(R,s_star), y):
    s <- (s_star + y) mod n
    return (R, s)

function ExtractSecret(sig=(R,s), preSig=(R,s_star)):
    assert VerifySchnorr(sig, P, m)
    y <- (s - s_star) mod n
    return y

Refund Leaf Template (CLTV):

<T> OP_CHECKLOCKTIMEVERIFY OP_DROP <P_refund> OP_CHECKSIG

13. Testing Points

  1. Validity: Under random x, y, k, verify σ is valid for P, m;
  2. Extractability: Given (σ̃, σ), recover y;
  3. Cross-Chain Consistency: Use same Y on two chains; claim on one enables extraction and claim on the other;
  4. Replay/Binding: After changing m or Y, old σ̃ unusable in new scenarios;
  5. Refund Path: Validate failure/success for nLockTime < T and ≥ T;
  6. MuSig2: Correctness of σ̃ and σ under joint nonces and aggregated challenges;
  7. Boundary Conditions: Modular normalization of s, s*, y; reject R = O;
  8. Privacy Observation: Statistical indistinguishability (Key-Path spends should match conventional payments).

14. Deployment and Policy

  • No soft/hard fork required; nodes and miners validate per standard rules;
  • Wallet/Library Upgrades:
    • Add AdaptorPreSign/Complete/Extract APIs;
    • Include refund leaves in output construction;
    • Monitor expirations and auto-broadcast refund transactions;
  • Relay Policy: Follow Tondi's existing standards; Key-Path spends relay by default; refund leaves follow standard CLTV/CSV policies.

15. Rationale

  • Binary structure of Key-Path claim + Script-Path refund maximizes privacy while retaining failure fallback;
  • Additive adaptor s = s* + y is simple, with mature proofs and implementations;
  • Domain separation binding P, m, Y mitigates context confusion and replay risks;
  • No new opcodes for ease of interoperability with Tondi and BTC.

16. Backwards Compatibility

  • Fully compatible with existing Taproot transactions;
  • Non-supporting wallets treat as ordinary P2TR outputs;
  • Refund leaves spendable as standard scripts (post-expiration) in non-PTLC wallets.

17. Security Audit Checklist (For Implementers)

  • Use mature libraries for secp256k1/Schnorr/MuSig2 (common choices: libsecp256k1 + musig2 branch);
  • Nonce generation includes aux_rand;
  • Structured storage for pre-signatures and final signatures (anti-tampering);
  • Clear sighash flags for transaction m (including Tapleaf/Taproot bits);
  • Monitor mempool & chain for timely y extraction;
  • Pre-construct fee-bumps (CPFP/RBF) before timeout;
  • Ensure safe timeout window ordering in cross-chain;
  • External interfaces avoid leaking σ̃ and internal tags.

18. Appendix A: MuSig2 Scenarios (Key Points)

  • Replace §7's P, x, k, R, e with MuSig2 aggregated versions:
    • Participants first aggregate public key P = MuSig2KeyAgg(P1,...,Pn);
    • Run joint nonce protocol to get R = R1 + ... + Rn;
    • Compute aggregated challenge e = H(tag_ptlc ∥ R ∥ P ∥ m ∥ enc(Y));
    • Each locally computes s_i = k_i + e·x_i, aggregate s = Σ s*_i (mod n);
    • Holder of y or coordinator completes s = s* + y (mod n) and broadcasts;
    • Any holder of σ̃ can extract y = s − s* (mod n) upon seeing σ.

19. References (Selected)

  • BIP-340/341/342 (Schnorr/Taproot/Tapscript)
  • MuSig2 paper and implementation docs
  • Scriptless Scripts (Maxwell/Poelstra/Ruffing et al.)
  • Lightning PTLC design discussions and BOLTs drafts
  • DLC (Discreet Log Contract) related papers