Pith. sign in

REVIEW 3 major objections 5 minor 11 references

Payment Channels with Proofs

T0 review · 3 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that Proofgold payment channels can carry off-chain bets on whether a proposition will be proven by a deadline, using a composite hash-timelock and proposition-timelock script to keep stale commitments from being exploited

desk verdict A genuine new construction—HTLC+OP_PROVEN ptlc—with an honest implementation, but the abstract overclaims deadline semantics; the paper itself concedes a race window. read the letter →

arxiv 2509.08268 v1 pith:PEHMPGF6 submitted 2025-09-10 cs.LO

Chad E. Brown , Cezary Kaliszyk , Josef Urban This is my paper
classification cs.LO
keywords paymentchannelsProofgoldlightningnetworkhashtimelockcontractspropositiontimelockprovabilitymarketsblockchainLayer2
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that Proofgold payment channels can be extended to carry proof-contingent bets—wagers on whether a proposition will be proven on-chain by a deadline—without putting the bet itself on the slow Layer 1 blockchain. The proposal matters because Proofgold's Layer 1 produces roughly one block per hour and its commit-and-reveal bounty mechanism takes about a day, so off-chain proof payments need Layer 2 speed while keeping on-chain recourse. The load-bearing mechanism is a composite script that is both enforceable and revocable: the proof condition settles who wins the contested output, and the hash-lock secret makes old commitment transactions unusable for cheating. The authors implement the channels in the Proofgold Lava client and test revoked-commitment and racing attacks. If correct, this is the foundation for a Proofgold lightning network, proof request markets, and a prediction market for provability of mathematical statements.

What carries the argument

The central object is the composite script h(h,δ,N,p(P,β,T,α)): a hash timelock contract wrapped around a proposition time lock contract p(P,β,T,α). The inner script is spendable by β if proposition P has been proven on-chain via OP_PROVEN, or by α after time T via OP_CLTV. The outer script is spendable immediately by whoever reveals a secret hashing to h and signs with δ, or after N blocks by satisfying the inner script. In commitment transactions δ is the counterparty, so when secrets are revealed during a channel update, a stale commitment's bet output can be pulled by the counterparty instead of stolen. The OP_PROVEN check anchors the bet to Layer 1; the 48-block CSV delay gives the coun

What would settle it

Set up a channel with a bet that P will be proven by block height T. At height T, Alice broadcasts her commitment with the 60-bar third output. At height T+1, publish a proof of P on-chain. After T+48, ask whether the third output can be spent both by Alice's timeout branch and by Bob's OP_PROVEN branch. If both branches validate, the claim that Layer 1 deterministically decides the bet is false.

Watch

Extended reading notes

Core claim

On the Proofgold blockchain, two parties with an open bidirectional payment channel can place a conditional bet whose payout depends on whether a proposition P is proven on-chain before a deadline T. The bet lives only in the channel's commitment transactions, not on Layer 1: one output goes to the prover-side bettor if P appears, and to the other side if time runs out. The central construction is the composite script h(h,δ,N,p(P,β,T,α)), a hash timelock wrapped around a proposition time lock. The hash-lock part revokes old commitments the way Lightning channels revoke them, stopping a party who lost the bet from publishing a stale commitment to grab the third output. The proposition-lock pa

Load-bearing premise

The load-bearing premise is that a proof appearing near the deadline settles the bet deterministically; the paper concedes a gray zone from block height T to T+48 where either party could be called the winner, so the advertised 'proof by T' bet actually requires the proof to arrive a few blocks before T.

Editorial extensions

If this is right

  • A party can pay for a proof off-chain by betting that no proof will appear by a deadline; the prover or anyone who finds a proof collects by betting the opposite.
  • If a proof exists and the payer refuses to update the channel, the prover can publish the proof on Layer 1 and close the channel at the corrected balance; if no proof exists and the prover refuses to concede, the payer closes and claims the pot after the timeout.
  • Revealing previous commitment secrets on a channel update makes old commitment transactions unattractive to publish, closing the revoked-commitment attack described in the paper.
  • Bets routed through intermediate channels can form a lightning network for proofs; a middleman who finds a proof has an incentive to share it in one direction and hide it in the other, a behavior the paper flags and suggests countering by publicizing proofs on receipt.
  • The ratio of stakes can be read as an implied probability that a proof will appear by the deadline, turning the network into a prediction market for theorem provability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's own deadline ambiguity means the implied probability is not P(proof by T) but P(proof available early enough before T to survive the 48-block race); a sharper market would quote that adjusted probability.
  • A natural hardening is to require the proof's hash commitment to be published on-chain before T, so the event 'proven by T' is observable at T instead of after the CSV delay.
  • The HTLC-plus-PTLC composition is not specific to OP_PROVEN; the same two-layer revocation trick should work for any on-chain condition that becomes spendable after a delay, such as oracle-reported outcomes.
  • One could test whether the withholding strategy—find a proof in the ambiguous window, hide it, open a new certain bet—is actually profitable once fees and capital lockups are counted; if it is, the protocol's winner semantics are systematically biased toward late-proof holders.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes an extension of Bitcoin-style bidirectional payment channels to the Proofgold network, in which channel outputs can be conditioned on whether a proposition P has been proven by a given time. The construction combines hashed timelock contracts (HTLCs) with a new 'proposition time lock contract' (PTLC) built on Proofgold's OP_PROVEN opcode. The authors argue that this makes proof-contingent bets revocable in the same way HTLCs make ordinary payments revocable, so that a party can safely share a proof off-chain and the channel can be updated; if the counterparty is uncooperative, Layer 1 remains the recourse. They also sketch how such channels could compose into a lightning network for Proofgold, discuss prediction-market interpretations of the bets, and report an implementation in the Proofgold Lava client with tests covering channel opening, updating, closing, and conditional payments. The paper is self-aware about some limitations, most notably the uncertain T-to-T+N resolution window, but the abstract and key claims nevertheless assert a 'proven by a certain time' semantics that the construction does not actually deliver.

Significance. If the construction worked exactly as advertised, it would be a useful foundational step toward a faster, Layer-2 proof market on Proofgold, with potential applications to collaborative formalization and mathematical prediction markets. The paper is a systems/engineering contribution rather than a formal security analysis: it specifies scripts precisely enough to implement, ships a public repository with tests, and does not fit data or hide free parameters. The core limitation that a proof appearing near the deadline leaves both parties able to claim the bet output is disclosed in Section III, and the authors are honest that the effective semantics are not 'proof by T' but rather a race after T+N. Because the motivating application is explicitly paying for proofs by a deadline, this mismatch is the central scientific issue: the construction as written does not deliver the advertised deadline semantics. Nevertheless, the underlying idea of combining HTLC revocation with a proof-conditioned output is plausible and likely salvageable with either a revised construction that checks proof publication height or a revised and carefully scoped claim.

major comments (3)
  1. [Section III, Figures 3–4] The script h(h, δ, N, p(P, β, T+48, α)) does not enforce that the proof appeared by time T. Bob's branch of the ptlc only checks OP_PROVEN at spend time; it contains no check that the proof's publication height is ≤ T or even ≤ T+48. Consequently, a proof published after T, or even after T+48 if Alice has not yet claimed the output, can still make Bob the winner of the 60-bar output. This contradicts the abstract's 'proven by a certain time' and the statement that the ptlc 'does work to enforce the bet as described.' The paper itself concedes this in the paragraph about the uncertain period from T to T+N, but the central claim should be restated: the output enforces a claim race, not a proof deadline. Either the construction must be changed to require a proof with a verifiable publication height, or the abstract/introduction must define the bet as 'Bob can claim if OP_PROVEN becomes true
  2. [Section III, timing analysis] The protocol's timing discussion assumes Bob can publish τB2 and the proof within the 48-block HTLC window, but it does not account for Proofgold's commit-and-reveal publication latency of roughly 24 blocks mentioned in Section I and III. OP_PROVEN only becomes true after the reveal, so a proof obtained slightly before T may not be provable on chain until after T, and Bob may be unable to spend the third output before Alice's T+48 claim. The sentence 'Bob should really supply the proof at most a few blocks before height T' is therefore not quantified and is not supported by the block-height arithmetic. The effective deadline for Bob is at least the commit-and-reveal latency earlier than T, and this should be analyzed explicitly. This strengthens the last-minute failure mode identified in the paper itself.
  3. [Section III, last paragraph] The paper notes that in the T-to-T+N window 'either could be considered the winner' and that Bob is incentivized to withhold a late proof and place a new, certain bet. This is not a minor edge case; it is precisely the regime the abstract's deadline semantics promises to handle. The motivating application—paying for proofs by a deadline—fails exactly when proofs arrive near T. The manuscript should either provide a game-theoretic or incentive analysis showing under what conditions the protocol still constitutes a meaningful bet, or explicitly scope the contribution away from exact-deadline payments. As written, the load-bearing claim that the bet resolves on 'proof by time T' is not supported by the script semantics.
minor comments (5)
  1. [Section II, notation] The definition of h(h, α, N, β) lists both spending branches as 'signed by α.' One branch should be signed by β, otherwise the HTLC's distinction between the secret holder and the timeout claimant is lost. The later usage in the commitment transactions (e.g., h(hA1, β, 48, α)) suggests the intended second branch is signed by β.
  2. [Figures 3–4 captions] The captions say 'bet that Bob will not have a proof of P before block height T' and 'will have a proof of P before block height T,' but the scripts use T+48. Either adjust the captions to T+48 or explain the offset in the caption text.
  3. [Section III] There is a typo: 'After48blocks' should be 'After 48 blocks.' Also, the phrase 'essentially be a competition to spend the output first' is vague; the protocol should specify the exact race conditions and which party can win under what block-height order.
  4. [Section VI] The implementation section lists test scenarios but gives no details on the outcomes or on whether the tests include the T-to-T+48 race. Given the central limitation, it would be valuable to state explicitly that this race is not resolved by the implementation, and to describe what the tests do and do not verify.
  5. [Section V] The prediction-market interpretation is intuitive but the paper does not discuss how the market clears across multiple counterparties or how the odds update in practice. A brief comment on the relationship to [4] and the limitations of using a single channel pair as a price signal would strengthen the discussion.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the protocol is a direct script construction benchmarked against Bitcoin Lightning, with no fitted predictions or self-citation chain.

full rationale

The paper contains no fitted parameters, no quantitative predictions, and no equation whose output is an input by construction. The PTLC p(P, β, T, α) is explicitly defined in Section III via OP_PROVEN and OP_CLTV, and the HTLC composition h(h, δ, N, p(P, β, T, α)) is defined via OP_CSV and a hash secret. These are direct script constructions, not outcomes derived from the bet they are intended to enforce. The statement "Using the ptlc p(P, beta, T, alpha) does work to enforce the bet as described" is a design claim tested against the Bitcoin Lightning design [1], an external benchmark, and against the implementation tests in the linked repository. The probability interpretation in Section V is a standard market-odds argument, not a fitted quantity. Self-citations [2] and [3] describe Proofgold and set theories; they are not load-bearing for the script composition or for any derived result. The paper itself flags a real limitation: "If Bob obtains a proof during the uncertain period from T to T+N, either could be considered the winner of the bet" (Section III). This means the delivered semantics are approximate, but that is a correctness/security concern, not circularity: the script's behavior is not defined in terms of the bet's intended outcome. Section VIII similarly notes missing performance metrics and a formal economic model; these are acknowledged limitations, not circular inputs. Overall, no load-bearing step reduces to its own definition or to a self-citation.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The ledger is light: no fitted parameters, no invented physical entities. The paper's load on the reader is four domain assumptions about the Proofgold scripting environment and the timing of on-chain proof publication. The last two are the fragile ones, and the paper itself flags their failure modes in the uncertain T to T+48 window and the unresolved middleman incentive.

assumptions (4)
  • domain assumption Proofgold's scripting language includes multisig, OP_CSV, OP_CLTV and OP_PROVEN with the semantics assumed in Sections II and III.
    The whole construction depends on these opcodes existing and behaving as described; OP_PROVEN checks whether a proposition hash root is proven on the Proofgold chain.
  • domain assumption The Poon-Dryja payment channel construction is sound as cited [1], and the paper lifts its funding, commitment and revocation logic without re-deriving it.
    Section II builds directly on [1]; any flaw in the underlying Lightning design propagates into this extension.
  • ad hoc to paper Publishing a proof on Layer 1 and having OP_PROVEN observe it can be done within the htlc delay window, so the third output is claimable by the intended party.
    Section III's race analyses show this fails in the T to T+48 uncertain window, which the authors acknowledge: 'either could be considered the winner of the bet'.
  • ad hoc to paper The bet resolution semantics match the stated 'proven by a certain time' behavior.
    The paper itself corrects this: the bet is really on finding a proof a few blocks before T ('it is more accurate to say Bob is betting he will have a proof of P at the latest a few blocks before T').
invented entities (1)
  • Proposition time lock contract (ptlc) p(P, beta, T, alpha) and its htlc composition h(h, delta, N, p(P, beta, T, alpha)) independent evidence
    purpose: A channel output spendable by one party if P is proven on Proofgold's chain (via OP_PROVEN) or by the other after time T, enabling proof-contingent bets and proof payments.
    Not a physical postulate: a script construct implemented and committed in the public proofgold-lava repository (commit 69fc329a), so its behavior is testable against a running Proofgold node. Its composition with htlc is claimed to restore revocability, though the uncertain window limits this.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Payment Channels with Proofs." pith.science (2026). https://pith.science/paper/PEHMPGF6

@misc{pith2026250908268,
  author       = {Pith},
  title        = {Pith review of: Payment Channels with Proofs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PEHMPGF6}},
  note         = {Machine review of arXiv:2509.08268}
}
read the original abstract

The fundamental building blocks of the Bitcoin lightning network are bidirectional payment channels. We describe an extension of payment channels in the Proofgold network which allow the two parties to bet on whether a proposition will be proven by a certain time. These provide the foundation for a Proofgold lightning network that would allow parties to request proofs (by betting there will be no proof by a certain time) and other parties to provide proofs (and be rewarded by betting there will be a proof). The bets may also provide a way to approximate the probability that a certain proposition is provable (in the given amount of time). We describe the implementation of payment channels supporting proofs in Proofgold and discuss a potential lightning network that could be built as a result. One application of such lightning network would be a large decentralized infrastructure for fast collaborative formalization projects.

Figures

Figures reproduced from arXiv: 2509.08268 by the authors.

Figure 1
Figure 1. Alice’s initial commitment transaction τ A 1 Channel fund 100 bars α 100 bars h(h B 1 , α, 48, β) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Bob’s initial commitment transaction τ B 1 behavior with the ptlc behavior. That is, we also need the third output to be controlled by the counterparty after a secret has been revealed. We simply denote this as the composition h(h, δ, N, p(P, β, T, α)) where h is the hash of a secret, N is a number of blocks, P is a proposition, T is a time and δ, β and α are addresses. The script h(h, δ, N, p(P, β, T, α)) states th… view at source ↗
Figure 3
Figure 3. Alice’s commitment transaction τ A 2 with the bet that Bob will not have a proof of P before block height T Channel fund 50 bars α 90 bars h(h B 2 , α, 48, β) 60 bars h(h B 2 , α, 48, p(P, β, T + 48, α)) [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Bob’s commitment transaction τ B 2 with the bet that Bob will have a proof of P before block height T have three outputs: 50 bars to α 90 bars to h(h B 2 , α, 48, β), and 60 bars to h(h B 2 , α, 48, p(P, β, T + 48, α)), as shown in [PITH_FULL_IMAGE:figures/full_fig_p0…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

11 extracted references · 7 canonical work pages

  1. [1]

    Poon and T

    J. Poon and T. Dryja, ``The bitcoin lightning network: Scalable off-chain instant payments,'' 2016, https://lightning.network/lightning-network-paper.pdf

    work page 2016

  2. [2]

    C. E. Brown, C. Kaliszyk, T. Gauthier, and J. Urban, ``Proofgold: Blockchain for formal methods,'' in 4th International Workshop on Formal Methods for Blockchains, FMBC@CAV 2022, August 11, 2022, Haifa, Israel, ser. OASIcs, Z. Dargaye and C. Schneidewind, Eds., vol. 105. 1em plus 0.5em minus 0.4em Schloss Dagstuhl - Leibniz-Zentrum f \" u r Informatik, 20...

    doi:10.4230/oasics.fmbc.2022.4 2022

  3. [3]

    C. E. Brown and K. P a k, ``A tale of two set theories,'' in Intelligent Computer Mathematics - 12th International Conference, CICM 2019, Prague, Czech Republic, July 8-12, 2019, Proceedings , ser. Lecture Notes in Computer Science, C. Kaliszyk, E. C. Brady, A. Kohlhase, and C. S. Coen, Eds., vol. 11617. 1em plus 0.5em minus 0.4em Springer, 2019, pp. 44--60

    work page 2019

  4. [4]

    Su, ``Mathcoin: A blockchain proposal that helps verify mathematical theorems in public,'' IACR Cryptol

    B. Su, ``Mathcoin: A blockchain proposal that helps verify mathematical theorems in public,'' IACR Cryptol. ePrint Arch. , vol. 2018, p. 271, 2018

    work page 2018

  5. [5]

    Decker and R

    C. Decker and R. Wattenhofer, ``A fast and scalable payment network with bitcoin duplex micropayment channels,'' in Stabilization, Safety, and Security of Distributed Systems - 17th International Symposium, SSS 2015, Edmonton, AB, Canada, August 18-21, 2015, Proceedings , ser. Lecture Notes in Computer Science, A. Pelc and A. A. Schwarzmann, Eds., vol. 92...

    work page doi:10.1007/978-3-319-21741-3 2015

  6. [6]

    Miller, I

    A. Miller, I. Bentov, S. Bakshi, R. Kumaresan, and P. McCorry, ``Sprites and state channels: Payment networks that go faster than lightning,'' in Financial Cryptography and Data Security - 23rd International Conference, FC 2019, Frigate Bay, St. Kitts and Nevis, February 18-22, 2019, Revised Selected Papers , ser. Lecture Notes in Computer Science, I. Gol...

    doi:10.1007/978 2019

  7. [7]

    Kappos, H

    G. Kappos, H. Yousaf, A. M. Piotrowska, S. Kanjalkar, S. Delgado - Segura, A. Miller, and S. Meiklejohn, ``An empirical analysis of privacy in the lightning network,'' in Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part I , ser. Lecture Notes in Computer Scienc...

    work page 2021

  8. [8]

    Naor and I

    O. Naor and I. Keidar, ``On payment channels in asynchronous money transfer systems,'' in 36th International Symposium on Distributed Computing, DISC 2022, October 25-27, 2022, Augusta, Georgia, USA , ser. LIPIcs, C. Scheideler, Ed., vol. 246. 1em plus 0.5em minus 0.4em Schloss Dagstuhl - Leibniz-Zentrum f \" u r Informatik, 2022, pp. 29:1--29:20. [Online...

    work page doi:10.4230/lipics.disc.2022.29 2022

Show all 11 references
  1. [9]

    Dziembowski, S

    S. Dziembowski, S. Faust, and K. Host \' a kov \' a , ``Foundations of state channel networks,'' IACR Cryptol. ePrint Arch. , p. 320, 2018. [Online]. Available: https://eprint.iacr.org/2018/320

    2018

  2. [10]

    write newline

    " write newline "" initialize.prev.this.status FUNCTION begin.bib " write newline preamble empty 'skip preamble write newline if " thebibliography " longest.label * " " * write newline " [1] #1 " write newline " url@samestyle " write newline " " write newline " [2] #2 " write ...

  3. [11]

    11em plus .33em minus .07em 4000 4000 100 4000 4000 500 `\.=1000 = #1 \@IEEEnotcompsoconly \@IEEEcompsoconly #1 * [1] 0pt [0pt][0pt] #1 * [1] 0pt [0pt][0pt] #1 * \| ** #1 \@IEEEauthorblockNstyle \@IEEEcompsocnotconfonly \@IEEEauthorblockAstyle \@IEEEcompsocnotconfonly \@IEEEco...

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.