From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 04 Oct 2026 07:55:26 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xDNca-0000AC-Cp for bitcoindev@gnusha.org; Sun, 04 Oct 2026 07:55:26 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-45e6091d8a1sf759478fac.1 for ; Sun, 04 Oct 2026 07:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1791125718; x=1791730518; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=fcOTtZrPfHTcjA7POJD1oXfQZzleZTqmYl4k/mFDK5A=; b=wSj+kby7JYlsfeEKf6u3BvGR5/lZzKxQSpJgWTAabDHTRPc2tialoIwGdpRN6ixUr6 f+y0dZMfrvvxt+MWUTFcYWoFWd0m9rTUdWIaFYjFyD77aJhZvnf3UkQL8+61eGU7Iyrm OS+KuVZH0nhcOVfu82xRoTgVVyF6ieP0OsNFnDnBRiIKr6mMMym8Pb4JM6rjjpR3FWZ+ xI6Pc1dlibnCCxKGeBT2ZTvhz4ipiTxh97nnLiGPC184VDaN5ZfjbvfZ3uepOC4BNs2C kEYTr780h64NJFiDvjfwy0XqsL04awiku1WI1dJB2fVd3qJfmg8jhjLSqIF4J1vzq8tV /WBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791125718; x=1791730518; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=fcOTtZrPfHTcjA7POJD1oXfQZzleZTqmYl4k/mFDK5A=; b=sPmeuLQWf54ngwNLNV+OKy6MBvgXtM6ohw8ZdemNOAO1xr+kmUxWpaLn68vrrHtW5M XXtiGzccFshGK68uMSbD+rZElKpQ870cjKC/jx0SwawZ5+vNlsXu/0hif6ZhFAjrnX2y aCzUs7h41qTtcaNQIM1o1FphzM4Ff+RNpkVZQraZTA6ZK+/GDDmi+V3+HUW22eUO9Su9 7f8UHqz9sLcVO33Xi8xVoQtn6KsuS0zCKhJI/nPLM87/gcd1MoR6XaYjcI2D4Jhsolcq 0/WeuHinVQ4ZpyO17lxdtof6QvxoTP17szXdNYBgwlCyhyZg9Ju50uuRU8DnTP51NGMY j/VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791125718; x=1791730518; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=fcOTtZrPfHTcjA7POJD1oXfQZzleZTqmYl4k/mFDK5A=; b=dMOHz4j7yON6gHcN/L0gKkx61NYbg5L5394deR0cbqpgiKadD1ylC79T6N+J00hbC6 jDaGxtVTZaTIxps4zcL5JYjxyPRjQI6MeOhRZGZYQ0jx0nBAQQqHbrfZ13x5Vk/xwtvC D4jb6UzEIdmC80Qnmsoiihd96qMshN2HRlSgYbvZrqhBBg7y99PX7/DBDd8CBn0FD1lw 3pTSy6XUjkqGKFEVKlcmYPxGvBlXIJEUzKpSm3r9Fj1rj7kcFXabezyw0HNqnvqrg7+r nUNVkbcfNS/Z3x/GGY3jhXMMlPolqitkqBLoS3Jst2r4YwHoMvkR3GkI91gyDhBTWLRv k7AQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBynofI7whZKXyrBhoA8Z1v3WF9YC5zaoIUunr+MZJa5CqOTevK5YKcOm6n1wIRWGzm1n9jfWsMkNLth@gnusha.org X-Gm-Message-State: AFuF++kR9YqUTVnVYV+0R+TGHb3iXokmXrKxGb7/7pHrsotgNYi6gES7 IE/skZz7+S++gUPKYwPvZYt1c+2bGM52GyRkBFC5ZUy5V4Vkqs1aeAj+ X-Received: by 2002:a05:6870:3344:b0:486:a82a:a345 with SMTP id 586e51a60fabf-49e15e57ff7mr7106242fac.25.1791125718314; Sun, 04 Oct 2026 07:55:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdf3q+MO4ze5OX3xNA1SyQnmKzksipSwvBifo47wyGaBsg==" Received: by 2002:a05:687c:22c1:20b0:493:f51a:bff1 with SMTP id 586e51a60fabf-49df37ac892ls875031fac.1.-pod-prod-00-us-canary; Sun, 04 Oct 2026 07:55:13 -0700 (PDT) X-Received: by 2002:a05:6808:2e4f:b0:4ec:1bf1:fa82 with SMTP id 5614622812f47-4f30c3c40d8mr9409279b6e.46.1791125713206; Sun, 04 Oct 2026 07:55:13 -0700 (PDT) Received: by 2002:a05:690c:c13:b0:8a6:990a:8ca5 with SMTP id 00721157ae682-8ae4d2110c2ms7b3; Sun, 4 Oct 2026 07:51:09 -0700 (PDT) X-Received: by 2002:a05:690c:a0ab:b0:8a8:4d6:22ec with SMTP id 00721157ae682-8acdae4a420mr40079507b3.7.1791125468374; Sun, 04 Oct 2026 07:51:08 -0700 (PDT) Date: Sun, 4 Oct 2026 07:51:08 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] LN-GAP : Lightning governed by arbitrary programs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_76948_1783357857.1791125468076" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_76948_1783357857.1791125468076 Content-Type: multipart/alternative; boundary="----=_Part_76949_1120832004.1791125468076" ------=_Part_76949_1120832004.1791125468076 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hi list, Paper=20 https://github.com/AdamISZ/ln-gap/blob/master/docs/paper/lngap-short.pdf=20 (my words) and Repo: https://github.com/AdamISZ/ln-gap (AI generated 95% , see note at=20 start of README) The party trick here is: play chess in a Lightning channel and have the=20 winner get the pot, "trustlessly". Same for blackjack, which is more=20 interesting as a hidden information game. Non-party-trick applications, in= =20 a moment. Before we address the scare quotes in the room, let's mention the main=20 concept: you can always play such challenge-response games on bitcoin=20 itself, up to some complexity limit, leveraging the idea that "to disprove= =20 something can be exponentially smaller than to prove something", so like, i= =20 show one piece on one square of the chessboard that proves your move is=20 illegal; things like that. But playing those games on chain for 50 rounds= =20 is basically never practical/desirable/economic/scalable. So you obviously= =20 *want* to do it in a channel or similar. The problem with that is that, as the paper's conclusion says "Lightning=20 cannot adjudicate silence". So stalling forces games onchain. Fine for=20 Lightning's own game, which only has like 3 rounds. The trick here is to=20 adjudicate silence, and specifically adjudicate only that, in what's called= =20 a "venue". The basic picture for resolving disputes: (wrong move or no move) -> Alice posts tx 'claim' that says 'no move or=20 wrong move from Bob on move d' -> (optional) Bob posts tx 'rebuttal' that= =20 says 'here is my move for move d and here is its attestation by the venue'= =20 -> (optional) Alice posts 'disproof' that says 'here is the exact predicate= =20 in your move that is illegal' or 'here is proof that the venue attests you= =20 didn't post the move in time'. You end up with usually zero, but max 3 transactions (4 depending on how=20 you squint at it), hence O(1), independent of the complexity of the program= =20 under dispute (more on that below; it's not true naively, due to e.g. stack= =20 limits, if you do it straightforwardly, though chess and similar work fine)= . (The biggest of those transactions turns out to be 'rebuttal', but it tends= =20 to be no more than 20-40 kvB which is fine; as noted, stack limits are what= =20 you tend to hit first.) So back to this "trustlessly" claim: Interestingly, a "venue" does not have to be a proof of publication=20 *ledger*. That is, it doesn't need to enforce unique history (but proof of= =20 publication or not *is* the idea). It just needs to say "Signed message X= =20 was or was not published before time T" and that's it. Equivocation would= =20 be addressed by the signature from the contract participant. The venue=20 doesn't need to know what X means (a la client side validation).=20 So as a single point of failure such a 'venue' would not be great. Alice=20 and Bob are in a contract. Vernon the venue colludes with Bob. Alice makes= =20 a move, Bob stalls, Alice posts the "he stalled" claim transaction onchain,= =20 Bob then posts his valid move as a rebuttal in the next transaction, and=20 his move is legal, so Alice cannot disprove, and *cannot* post "the venue= =20 said he didn't post his move on time" because Vernon refused to provide=20 that. So collusion enables stalling and prevents its punishment. But even this crap version has the property that Vernon never gets to hold= =20 the money, which removes some classes of attack, and allows contracting in= =20 pure bitcoin terms on complex contracts. And on slower timescale games,=20 Vernon's lying about the move being published can even be entirely=20 publically provable, burning reputation, future fee stream and possibly a= =20 timelocked bond. What LN-GAP as documented and coded does: the venue is a committee=20 (realistically up to hundreds not more for technical reasons; the demos use= =20 5) drawn, perhaps randomly, from a larger set. They can post timelocked=20 bonds to participate. Crucially, they can atomically receive fees over=20 channels using something I'm calling "EC-OTS", see paper for details, with= =20 their publications, so there is a positive incentive to participate.=20 Liveness is 1 of n, i.e. only one committee member has to be willing to=20 publish your move/state update. But a threshold majority must attest the=20 fact that you didn't move before your deadline, and it's that that can=20 resolve the 'stalling' problem. For actually posting illegal moves/state=20 transitions, we apply the 'disproving is smaller' principle above:=20 demonstrate illegality on one leaf of a tapscript tree. Anyway the paper argues for how some combination of public entities with=20 reputations to lose (and who don't have nasty custody of user funds issues;= =20 they don't even know what the contracts adjudicate, for that matter - their= =20 lawyers will be happy!), with some anonymous but timelocked-bonded entities= =20 as a committee; the latter subset help with the liveness argument, but can= =20 more easily be sybiled; the former help with credibility due to high=20 reputation burn (vs low value timelocked burn, probably, for anon entities;= =20 though you *could* argue for all-anon, too). Running as a member of the venue is extremely lightweight; no computation= =20 burden, no history burden. What *is* burdensome for both contract=20 participants and venue members is: liveness is leaned on heavily. You lose= =20 if you go offline for a long enough period. Applications: games are fun and are the obvious application of the idea,=20 being multi-round, defined ruleset interactions. Others: consider the=20 classic filecoin application, but with a twist: the service provider offers= =20 the user a contract where they prove they're holding the 1TB file every 1= =20 day with some merkle proof scheme, and the user is required to pay on that= =20 schedule, but with a twist: if the service provider cannot provide the=20 proof one day, they have to give up a big deposit (effectively insurance=20 payout that compensates the user for loss of valuable files). This latter= =20 mechanism is distinctive to this scheme; neither filecoin/sia nor some=20 other schemes that have been proposed do this "adjudicate silence" part to= =20 pay back the aggrieved party. Proof of computation is similar to proof of storage. A note of comparison:= =20 garbled circuits schemes, while very heavy in general, can do the one-off= =20 resolution of a payment via a complex computation, without infrastructure= =20 like 'venues'. But they don't solve stalling (not that they are claimed=20 to). A similar comment about ZKCP. Lots of little nuances there, but,=20 sidetrack. Where it gets really interesting is where I try to justify "arbitrary". As= =20 in, any program of any complexity. This is clearly nonsense for a program= =20 with a very large internal state, because Bitcoin Script does not support a= =20 stack size of greater than 1000, even if taproot cleverly gives you the=20 ability to resolve an ungodly large amount of predicates via its MAST style= =20 tree. In Section 7 of the short paper, it's argued that you can do the same thing= =20 as BitVMX [1], which is an extension of the original BitVM idea [2], that= =20 is: you can resolve a dispute over a computation with a bisection. BitVMX= =20 does that onchain, and you're talking non-trivial, say, 30 rounds. If we do= =20 that bisection *off-chain* we're basically using the venue in the same way= =20 as above, thereby keeping an O(1) footprint onchain in dispute (although to= =20 be fair it's already O(log n), but even that may be impractically large).= =20 The codebase currently just holds a proof of concept example that it's=20 possible, though it's close to the stack limit [3] . This could work for=20 literally *any* guest program, hence the 'arbitrary programs' claim of the= =20 title. I briefly muse about how that could enable things like bridges to rollups,= =20 I guess in theory that might make sense, albeit it's a radical reimagining= =20 of what 'bridge' even is (the coins don't go anywhere; liquidity is=20 required etc). Which brings me to my final comments: A big part of this whole line of thinking is "even though a bilateral=20 contract with fixed liquidity is of course extremely limited, it buys a lot= =20 in terms of privacy, scale, speed from being Lightning-style". Bilateral=20 contracts are not multilateral contracts but it is not at all crazy to=20 imagine doing the same type of thing with shared facts, shared across=20 multiple such contracts. Imagine e.g. auctions. I was originally quite=20 enthused about that idea specifically, but got sidetracked :) The venue, as noted in the paper, has a DLC oracle flavor to it (indeed the= =20 EC-OTS observation is very similar to the DLC observation), but it's as=20 proposed a very specific kind of oracle: it attests the timing of a=20 self-certifying fact (the mover's move and their signature) rather than an= =20 external world event. So the whole 'committee of oracles' that is often=20 discussed for DLCs can make even more sense here as they're only=20 responsible for recording what, at slower timescales, is just objectively= =20 true. Cheers, AdamISZ/waxwing [1] https://arxiv.org/abs/2405.06842 BitVMX-CPU [2] idea goes way back, Arbitrum, TrueBit and probably some academic papers= =20 much earlier, I forget [3] I quote some concrete details from the long version of the paper:=20 "The program is BitVMX=E2=80=99s Groth16 verifier, a RISC-V build of a=20 pairing-based verifier, checking a RISC0 [12] proof that a STARK receipt of= =20 a guest program is valid. On a genuine proof it halts with success after=20 478,727,216 steps. Challenged, BitVMX=E2=80=99s search code takes 29 rounds= (some=20 nine minutes off chain), which is a contract of 119 depths: 2,058=20 pre-signed transactions, with 1,919 disprove leaves and 62 prove leaves at= =20 the final depth of the first phase. All 59 moves of that phase were sealed= =20 by the venue, and on regtest the dispute was the claim (220 vB), the=20 rebuttal (24.3 kvB, as re-measured on a smaller program: its size depends= =20 on the heads, not the program) and the proof of the halting ecall (58.5=20 kvB). The on-chain cost does not depend on the program=E2=80=99s length. Th= e leaves=20 are large (a prove leaf is about 228 KB of script, at a peak stack of 948= =20 of the 1,000 allowed), but they depend only on the contract=E2=80=99s keys,= so they=20 are built once per contract and channel updates reuse them." Notice here=20 that again the stack size is the real limit. Also note that the performance= =20 do not depend on the complexity of the guest program, since what we're=20 disputing is the groth16 proof. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= d10324a6-8067-427e-aa31-5886dd22e4fen%40googlegroups.com. ------=_Part_76949_1120832004.1791125468076 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi list,

Paper https://github.com/AdamISZ/ln-gap/blob/master/docs/paper/lngap-sho= rt.pdf (my words)

and

Repo: https://github.com/AdamISZ/ln-gap (AI generated 95% , see note at = start of README)

The party trick here is: play chess in a Lightning channel and have the = winner get the pot, "trustlessly". Same for blackjack, which is more intere= sting as a hidden information game. Non-party-trick applications, in a mome= nt.

Before we address the scare quotes in the room, let's mention the main c= oncept: you can always play such challenge-response games on bitcoin itself= , up to some complexity limit, leveraging the idea that "to disprove someth= ing can be exponentially smaller than to prove something", so like, i show = one piece on one square of the chessboard that proves your move is illegal;= things like that. But playing those games on chain for 50 rounds is basica= lly never practical/desirable/economic/scalable. So you obviously *want* to= do it in a channel or similar.

The problem with that is that, as the paper's conclusion says "Lightning= cannot adjudicate silence". So stalling forces games onchain. Fine for Lig= htning's own game, which only has like 3 rounds. The trick here is to adjud= icate silence, and specifically adjudicate only that, in what's called a "v= enue".

The basic picture for resolving disputes:

(wrong move or no move) -> Alice posts tx 'claim' that says 'no move = or wrong move from Bob on move d' -> (optional) Bob posts tx 'rebuttal' = that says 'here is my move for move d and here is its attestation by the ve= nue' -> (optional) Alice posts 'disproof' that says 'here is the exact p= redicate in your move that is illegal' or 'here is proof that the venue att= ests you didn't post the move in time'.

You end up with usually zero, but max 3 transactions (4 depending on how= you squint at it), hence O(1), independent of the complexity of the progra= m under dispute (more on that below; it's not true naively, due to e.g. sta= ck limits, if you do it straightforwardly, though chess and similar work fi= ne).

(The biggest of those transactions turns out to be 'rebuttal', but it te= nds to be no more than 20-40 kvB which is fine; as noted, stack limits are = what you tend to hit first.)

So back to this "trustlessly" claim:

Interestingly, a "venue" does not have to be a proof of publication = *ledger*. That is, it doesn't need to enforce unique history (but proof of = publication or not *is* the idea). It just needs to say "Signed message X w= as or was not published before time T" and that's it. Equivocation would be= addressed by the signature from the contract participant. The venue doesn'= t need to know what X means (a la client side validation).=C2=A0

So as a single point of failure such a 'venue' would not be great. Alice= and Bob are in a contract. Vernon the venue colludes with Bob. Alice makes= a move, Bob stalls, Alice posts the "he stalled" claim transaction onchain= , Bob then posts his valid move as a rebuttal in the next transaction, and = his move is legal, so Alice cannot disprove, and *cannot* post "the venue s= aid he didn't post his move on time" because Vernon refused to provide that= . So collusion enables stalling and prevents its punishment.

But even this crap version has the property that Vernon never gets to ho= ld the money, which removes some classes of attack, and allows contracting = in pure bitcoin terms on complex contracts. And on slower timescale games, = Vernon's lying about the move being published can even be entirely publical= ly provable, burning reputation, future fee stream and possibly a timelocke= d bond.

What LN-GAP as documented and coded does: the venue is a committee (real= istically up to hundreds not more for technical reasons; the demos use 5) d= rawn, perhaps randomly, from a larger set. They can post timelocked bonds t= o participate. Crucially, they can atomically receive fees over channels us= ing something I'm calling "EC-OTS", see paper for details, with their publi= cations, so there is a positive incentive to participate. Liveness is 1 of = n, i.e. only one committee member has to be willing to publish your move/st= ate update. But a threshold majority must attest the fact that you didn't m= ove before your deadline, and it's that that can resolve the 'stalling' pro= blem. For actually posting illegal moves/state transitions, we apply the 'd= isproving is smaller' principle above: demonstrate illegality on one leaf o= f a tapscript tree.

Anyway the paper argues for how some combination of public entities with= reputations to lose (and who don't have nasty custody of user funds issues= ; they don't even know what the contracts adjudicate, for that matter - the= ir lawyers will be happy!), with some anonymous but timelocked-bonded entit= ies as a committee; the latter subset help with the liveness argument, but = can more easily be sybiled; the former help with credibility due to high re= putation burn (vs low value timelocked burn, probably, for anon entities; t= hough you *could* argue for all-anon, too).

Running as a member of the venue is extremely lightweight; no computatio= n burden, no history burden. What *is* burdensome for both contract partici= pants and venue members is: liveness is leaned on heavily. You lose if you = go offline for a long enough period.

Applications: games are fun and are the obvious application of the idea,= being multi-round, defined ruleset interactions. Others: consider the clas= sic filecoin application, but with a twist: the service provider offers the= user a contract where they prove they're holding the 1TB file every 1 day = with some merkle proof scheme, and the user is required to pay on that sche= dule, but with a twist: if the service provider cannot provide the proof on= e day, they have to give up a big deposit (effectively insurance payout tha= t compensates the user for loss of valuable files). This latter mechanism i= s distinctive to this scheme; neither filecoin/sia nor some other schemes t= hat have been proposed do this "adjudicate silence" part to pay back the ag= grieved party.

Proof of computation is similar to proof of storage. A note of compariso= n: garbled circuits schemes, while very heavy in general, can do the one-of= f resolution of a payment via a complex computation, without infrastructure= like 'venues'. But they don't solve stalling (not that they are claimed to= ). A similar comment about ZKCP. Lots of little nuances there, but, sidetra= ck.

Where it gets really interesting is where I try to justify "arbitrary". = As in, any program of any complexity. This is clearly nonsense for a progra= m with a very large internal state, because Bitcoin Script does not support= a stack size of greater than 1000, even if taproot cleverly gives you the = ability to resolve an ungodly large amount of predicates via its MAST style= tree.

In Section 7 of the short paper, it's argued that you can do the same th= ing as BitVMX [1], which is an extension of the original BitVM idea [2], th= at is: you can resolve a dispute over a computation with a bisection. BitVM= X does that onchain, and you're talking non-trivial, say, 30 rounds. If we = do that bisection *off-chain* we're basically using the venue in the same w= ay as above, thereby keeping an O(1) footprint onchain in dispute (although= to be fair it's already O(log n), but even that may be impractically large= ). The codebase currently just holds a proof of concept example that it's p= ossible, though it's close to the stack limit [3] . This could work for lit= erally *any* guest program, hence the 'arbitrary programs' claim of the tit= le.

I briefly muse about how that could enable things like bridges to rollup= s, I guess in theory that might make sense, albeit it's a radical reimagini= ng of what 'bridge' even is (the coins don't go anywhere; liquidity is requ= ired etc). Which brings me to my final comments:

A big part of this whole line of thinking is "even though a bilateral co= ntract with fixed liquidity is of course extremely limited, it buys a lot i= n terms of privacy, scale, speed from being Lightning-style". Bilateral con= tracts are not multilateral contracts but it is not at all crazy to imagine= doing the same type of thing with shared facts, shared across multiple suc= h contracts. Imagine e.g. auctions. I was originally quite enthused about t= hat idea specifically, but got sidetracked :)

The venue, as noted in the paper, has a DLC oracle flavor to it (indeed = the EC-OTS observation is very similar to the DLC observation), but it's as= proposed a very specific kind of oracle: it attests the timing of a self-c= ertifying fact (the mover's move and their signature) rather than an extern= al world event. So the whole 'committee of oracles' that is often discussed= for DLCs can make even more sense here as they're only responsible for rec= ording what, at slower timescales, is just objectively true.

Cheers,

AdamISZ/waxwing

[1]=C2=A0https://arxiv.org/abs/2405.06842 BitVMX-CPU

[2] idea goes way back, Arbitrum, TrueBit and probably some academic pap= ers much earlier, I forget

[3] I quote some concrete details from the long version of the paper:=C2= =A0

"The program is BitVMX=E2=80=99s Groth16 verifier, a RISC-V build of a p= airing-based verifier, checking a RISC0 [12] proof that a STARK receipt of = a guest program is valid. On a genuine proof it halts with success after 47= 8,727,216 steps. Challenged, BitVMX=E2=80=99s search code takes 29 rounds (= some nine minutes off chain), which is a contract of 119 depths: 2,058 pre-= signed transactions, with 1,919 disprove leaves and 62 prove leaves at the = final depth of the first phase. All 59 moves of that phase were sealed by t= he venue, and on regtest the dispute was the claim (220 vB), the rebuttal (= 24.3 kvB, as re-measured on a smaller program: its size depends on the head= s, not the program) and the proof of the halting ecall (58.5 kvB). The on-c= hain cost does not depend on the program=E2=80=99s length. The leaves are l= arge (a prove leaf is about 228 KB of script, at a peak stack of 948 of the= 1,000 allowed), but they depend only on the contract=E2=80=99s keys, so th= ey are built once per contract and channel updates reuse them." Notice here= that again the stack size is the real limit. Also note that the performanc= e do not depend on the complexity of the guest program, since what we're di= sputing is the groth16 proof.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/d10324a6-8067-427e-aa31-5886dd22e4fen%40googlegroups.com.
------=_Part_76949_1120832004.1791125468076-- ------=_Part_76948_1783357857.1791125468076--