Sparkle Protocol: Formal Security Analysis

Formal security analysis and mathematical proofs for Sparkle Protocol.

1. Formal Definitions

1.1 System Model

Definition 1.1 (Parties): Let P = {B, S, C} where:

• B = Buyer (wants inscription, has Lightning sats)
• S = Seller (has inscription, wants sats)
• C = Coordinator (facilitates atomic swap)

Definition 1.2 (Assets):

• I = Inscription (Bitcoin UTXO with ordinal satoshi)
• L_n = Lightning payment of n satoshis

Definition 1.3 (Hash Time-Locked Contract):

An HTLC is a tuple H = (h, t, v) where:

• h = payment_hash (SHA-256 hash)
• t = timeout (block height)
• v = value in satoshis

2. Security Assumptions

2.1 Cryptographic Assumptions

Assumption 2.1 (Hash Function Security):

SHA-256 is:

• Preimage resistant: Given h, computationally infeasible to find p such that SHA256(p) = h
• Collision resistant: Computationally infeasible to find p1 ≠ p2 such that SHA256(p1) = SHA256(p2)

Assumption 2.2 (Lightning Network Security):

Lightning HTLCs provide atomic payment settlement:

• Payment succeeds if and only if preimage is revealed before timeout
• If timeout expires, payment is reverted to sender

Assumption 2.3 (Bitcoin Security):

• Bitcoin transactions cannot be reversed after sufficient confirmations
• Double-spending is computationally infeasible with >6 confirmations

2.2 Trust Assumptions

3. Security Properties

3.1 Atomicity Property

Theorem 3.1 (Weak Atomicity):

Under Assumptions 2.1-2.4, Sparkle Protocol provides weak atomicity:

• If buyer B pays Lightning invoice, then either:
  • (a) Seller S receives payment AND buyer receives inscription, OR
  • (b) HTLC times out and buyer receives refund

3.2 No Double-Payment Property

Theorem 3.2 (Single Payment Guarantee):

A buyer cannot be charged twice for the same inscription.

Proof:

1. Each HTLC is uniquely identified by hash h
2. Per Assumption 2.1, finding collisions in SHA-256 is computationally infeasible
3. Each inscription transfer uses unique HTLC hash
4. Lightning Network prevents double-claiming of same HTLC
5. Therefore: buyer cannot pay twice for same trade. [QED]

3.3 No Theft Property

Theorem 3.3 (Fund Safety):

Under Assumptions 2.1-2.3, the coordinator cannot steal funds from either party.

Proof by Cases:

• Case 1 (Buyer's funds):
  • Buyer's funds locked in HTLC
  • Coordinator can only claim by revealing preimage
  • If coordinator claims but doesn't broadcast PSBT, violates Assumption 2.4
  • If coordinator doesn't claim, HTLC refunds buyer after timeout
  • ∴ Buyer's funds are safe (under trust assumption)
• Case 2 (Seller's inscription):
  • Seller signs PSBT transferring inscription
  • PSBT only broadcasted if buyer pays HTLC
  • If PSBT broadcasted, seller receives Lightning payment
  • If PSBT not broadcasted, seller retains inscription
  • ∴ Seller's inscription is safe. [QED]

4. Attack Vector Analysis

4.1 Coordinator Withholding Attack

Attack 4.1: Malicious coordinator claims Lightning payment but doesn't broadcast PSBT.

Analysis:

• Success condition: Requires violating Assumption 2.4
• Mitigation: HTLC timeout allows buyer to reclaim funds
• Cost to attacker: Reputation loss, potential legal liability
• Defense: Run own coordinator or use bonded/reputable coordinators

4.2 Seller Double-Spend Attack

Attack 4.2: Seller signs PSBT but broadcasts competing transaction spending same UTXO.

Analysis:

• Success condition: Seller's competing tx confirms before PSBT
• Mitigation: Coordinator verifies UTXO status before revealing HTLC preimage
• Cost to attacker: Still loses inscription if PSBT confirms first
• Defense: Coordinator monitors mempool and blockchain state

4.3 Timing Attack

Attack 4.3: Attacker exploits HTLC timeout edge cases.

Analysis:

• Success condition: HTLC expires while PSBT in mempool
• Mitigation: Set conservative timeout periods (e.g., 144 blocks)
• Cost to attacker: Low, but requires precise timing
• Defense: Monitor network conditions, adjust timeout dynamically

5. Game-Theoretic Analysis

5.1 Nash Equilibrium

Proposition 5.1: Honest behavior is a Nash equilibrium for all parties under reputation incentives.

Payoff Matrix (Coordinator-Buyer interaction):

Analysis:

• If coordinator values future fees > one-time theft, broadcasting PSBT is dominant strategy
• Reputation loss makes withholding attack costly in long-term
• Bonding mechanisms can enforce honesty through economic penalties

5.2 Byzantine Fault Tolerance

Sparkle Protocol is NOT Byzantine fault tolerant:

• Single coordinator is trusted (not Byzantine tolerant)
• Multiple coordinators would require consensus protocol (future work)
• Users can choose coordinators, but no automatic failover

6. Proof Limitations

7. Comparison to Other Protocols

7.1 vs. Lightning Network Atomic Swaps

7.2 vs. On-Chain Atomic Swaps

8. Future Research Directions

8.1 Removing Coordinator Trust

Potential approaches to eliminate Assumption 2.4:

• Multi-sig coordinators: Require M-of-N coordinators to broadcast
• Bonded coordinators: Economic penalties for misbehavior
• Blockchain-based coordination: Use smart contracts (requires Bitcoin upgrades)
• Optimistic rollups: Fraud proofs for coordinator misbehavior

8.2 Formal Verification

• Machine-verified proofs using Coq/Isabelle
• Model checking for state transitions
• Symbolic execution of coordinator logic

8.3 Economic Security

• Optimal bonding amounts for coordinators
• Game-theoretic analysis with multiple coordinators
• Sybil resistance mechanisms

9. Mainnet Proof Artifacts

The following cryptographic artifacts demonstrate Sparkle Protocol operating on Bitcoin mainnet.

9.1 On-Chain Transaction Proofs

Verification: Click any TXID above to view on mempool.space. The Sweep TX witness contains the 4-element script-path spend proving hashlock redemption.

9.2 Tapscript Tree Structure

The Sparkle swap address uses a two-leaf Taproot script tree:

                        [TapBranch]
                       /          \
              [Hashlock Leaf]  [Timelock Leaf]
              (buyer claim)    (seller refund)
    

Hashlock Script (Claim Path):

OP_SHA256 <payment_hash> OP_EQUALVERIFY <buyer_pubkey> OP_CHECKSIG

// Hex: a8 20 [32-byte hash] 88 20 [32-byte x-only pubkey] ac

Timelock Script (Refund Path):

<csv_blocks> OP_CHECKSEQUENCEVERIFY OP_DROP <seller_pubkey> OP_CHECKSIG

// Hex: [encoded locktime] b2 75 20 [32-byte x-only pubkey] ac

9.3 Witness Stack (Claim Transaction)

The sweep transaction's witness stack proves script-path spending:

Witness Stack (4 elements):
  [0] Schnorr signature (64 bytes)
  [1] Preimage (32 bytes) - reveals SHA256 preimage
  [2] Hashlock script (67 bytes)
  [3] Control block (65 bytes) - leafVersion || internalKey || siblingHash
    

Raw Transaction Hex (Full Transactions)

Complete transaction data for independent verification:

Lock Transaction (7739c731...55b4):

02000000000101f54a4ab9a670069fb78882bbf0fd474c5ddb4a57a0a542bfc0ba7884f79140110300000000fdffffff02983a000000000000225120b9289ef4e1e27a5a1470b905ff438bc2b9ce8a1754bb816fccfa50261e6a3516110d000000000000225120b47352316ef30c3a3c2af067ed012901d201d30a3468057f402136cd340b09cf01404a4bb52efb3d7bffb9d250ae359b81383f8133d1a76e48c1b2ae43739719836f61de05b2e1aaf113eb8e37e5e7852b392148a655ef8a6e1eca76caea1f5ff1c9ad260e00

Sweep Transaction (1dcbeb24...e994):

02000000000101b455291cd1e5a2508afcc06475e69464f4f7b3a64b7f5ab334ff2b2531c739770000000000fdffffff01bc34000000000000160014a91125d778045379e66c78baf2896fae02c48d6b0440dd38d82eda2f5c83f737ecaf3ab184645f041bcd2d3e648fb7779428e3db29c4e9181ee703096f70c3178e054ccc3f2ca063d2debc71896a5b7b958a434e377b2059bc06251f72768fe5e31ccdb7c2949fe351d9e67ee1bc76898671341f2fd22d45a82002f87182ea2b8072ac76ff44a863583601753b95de696a7775b43fcbc6ead960882086f4c588a351207179ac1b2311b9f7fc7260b7541fa7166997b2d7eca95e0d29ac41c050929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0aa4841deffa14a691066f3675fe30a6a1d19eec58920946e23d4afd586d8844000000000

Raw Witness Data (Hex) - Verified On-Chain

Extracted from script-path spend transaction 1dcbeb24...e994:

# Witness Stack Element [0] - Schnorr Signature (64 bytes)
dd38d82eda2f5c83f737ecaf3ab184645f041bcd2d3e648fb7779428e3db29c4
e9181ee703096f70c3178e054ccc3f2ca063d2debc71896a5b7b958a434e377b

# Witness Stack Element [1] - Preimage (32 bytes)
59bc06251f72768fe5e31ccdb7c2949fe351d9e67ee1bc76898671341f2fd22d

# Witness Stack Element [2] - Hashlock Script (67 bytes)
a82002f87182ea2b8072ac76ff44a863583601753b95de696a7775b43fcbc6ea
d960882086f4c588a351207179ac1b2311b9f7fc7260b7541fa7166997b2d7ec
a95e0d29ac

# Script Breakdown:
#   a8                 = OP_SHA256
#   20                 = PUSH 32 bytes
#   02f87182ea2b8072ac76ff44a863583601753b95de696a7775b43fcbc6ead960
#                      = payment_hash (32 bytes)
#   88                 = OP_EQUALVERIFY
#   20                 = PUSH 32 bytes
#   86f4c588a351207179ac1b2311b9f7fc7260b7541fa7166997b2d7eca95e0d29
#                      = buyer's x-only pubkey (32 bytes)
#   ac                 = OP_CHECKSIG

# Witness Stack Element [3] - Control Block (65 bytes)
c050929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803a
c0aa4841deffa14a691066f3675fe30a6a1d19eec58920946e23d4afd586d884
40

# Control Block Breakdown:
#   c0 = leaf version (0xc0 for tapscript v0)
#   50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0
#      = internal public key (32 bytes)
#   aa4841deffa14a691066f3675fe30a6a1d19eec58920946e23d4afd586d88440
#      = sibling hash / merkle path (32 bytes)
    

Preimage Binding Verification:

PREIMAGE: 59bc06251f72768fe5e31ccdb7c2949fe351d9e67ee1bc76898671341f2fd22d
HASH:     02f87182ea2b8072ac76ff44a863583601753b95de696a7775b43fcbc6ead960

Verification: SHA256(preimage) == payment_hash ✓

# Command to verify locally:
echo -n "59bc06251f72768fe5e31ccdb7c2949fe351d9e67ee1bc76898671341f2fd22d" | xxd -r -p | sha256sum
# Expected output: 02f87182ea2b8072ac76ff44a863583601753b95de696a7775b43fcbc6ead960
    

9.4 Lightning Settlement Proof

Hold invoice settled on mainnet with matching payment hash:

{
  "payment_hash": "02f87182ea2b8072ac76ff44a863583601753b95de696a7775b43fcbc6ead960",
  "preimage":     "59bc06251f72768fe5e31ccdb7c2949fe351d9e67ee1bc76898671341f2fd22d",
  "amount_sats":  15000,
  "state":        "SETTLED",
  "settle_date":  "2025-12-15T14:32:00Z"
}
    

9.5 Cryptographic Binding

9.6 Ordinals Tracker Evidence

Note: Multiple mainnet tests were conducted. Sections 9.1-9.5 document the script-path spend proof (transactions 7739c731...55b4 → 1dcbeb24...e994). This section documents a separate inscription transfer test showing ordinals movement.

Inscription movement tracked through the swap:

Ordinals Explorer Verification

Verify inscription ownership via ordinals explorers:

• ordinals.com: View output 9422e6cb...:0
• ordiscan.com: View output ownership
• mempool.space: Transaction details

9.5 Ordinals Indexer Evidence (Inscription Transfer)

The following satpoint data proves the inscription moved from seller to buyer during the atomic swap:

Inscription Transfer Proof

Verify on Ordinals Explorers

• Lock TX: mempool.space | ordinals.com
• Sweep TX: mempool.space | ordinals.com

Inscription Transfer Cryptographic Binding

# Preimage (revealed when seller settles Lightning invoice):
b0f0af91b3602129c38f3db8febdeecb9e5507ca816116616e360738b58830e9

# Payment Hash (in Lightning hold invoice):
1b812c64655e9ca5e002c16a6f932b6ce95eee29a4f7b7227b371f005b027626

# Verification:
SHA256(preimage) == payment_hash  ✓

Proof: The same preimage that settled the 5,000 sat Lightning invoice is cryptographically bound to the inscription lock script. When the seller revealed the preimage to claim payment, the buyer used it to sweep the inscription.

10. Conclusion

Sparkle Protocol provides provable security under the assumption of honest coordinator behavior (Assumption 2.4). The protocol guarantees weak atomicity: either both parties receive their assets, or the HTLC refunds the buyer.

However, the protocol cannot prevent a malicious coordinator from claiming Lightning payments without broadcasting PSBTs. This is a fundamental limitation of the current design. Users must either:

• Trust reputable coordinators with established track records
• Use coordinators with bonding mechanisms
• Run their own coordinators
• Accept the residual trust assumption

References

1. Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.
2. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
3. Tier Nolan. (2013). Alt Chains and Atomic Transfers. Bitcointalk Forum.
4. Herlihy, M. (2018). Atomic Cross-Chain Swaps. ACM PODC.
5. Osuntokun, O. (2022). BOLT Specifications. Lightning Network.