From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 13 May 2026 18:40:29 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wNL3r-00054j-Lr for bitcoindev@gnusha.org; Wed, 13 May 2026 18:40:29 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-439e3568bf0sf1472234fac.0 for ; Wed, 13 May 2026 18:40:27 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1778722821; cv=pass; d=google.com; s=arc-20240605; b=DUi1rzXTYU4nqO+CsuCcKhWnrGDtDTGuLNQp16iU0MjxJUzFDqqJ3flUmuxaofT9Wz xQ9VNJSxj8WAgyJe7pMBCOV9kRxYFBX3mV2nEb6XfZLrOlqeM5BxVtQ22qtDwVDDOSQs +VmhUDm/CiFnpbHs3JL4+2a1iUAaZeU4OFS9wLRy15EApVwxyPdC4/nj9892poxWPp6u MWfc5DMeu9G+g67B4SPf2fQa09mG1hI/zFi9XbEEn891qEOJUXyBrP9b3V2mwgh8pTkr 7hzHBidrK88t5ulQckkE0lOurMPc6h1C4ZkvTY/QZGxKSOVjgajHEQIDlYwKKa/7rldx 1sDA== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=ccEou5hWoFJuqFU/P7NttKxNDBSZFvfrVjeGmqAB9KM=; fh=uLeXycbk9MtbQwnSfZl+k2RdB+YYRJ/OAXWS+PGtW98=; b=W1z3EWh1v12gJraie05zw5Z5HN8uSAbdqD69A2wfRYpzvQAa+gU501PB5qWEnJjqRr U+5IULlhZ25d5Rb9C65iKJw9Iy2yW7zygkS5q5BozyKZ0RpQLZpkOErEEPXIhQI416yy GIEKN9fhbH4ECLb7qtKrLnOjesuZd+X1xqwewYWfUZWWV7XA12Mv/Lh+rTPlEafKk9pe WsBcRQxl9nn5ei5dhQRqLGP1AG9HFWfsgd4CDvvcZ4RjjW7N26qkID21RS/BzAXGGYU+ UjYomMGanzvZ4YW2cmDKth81kNfmbn4pebFt87qK/Jvy0/Ke9A+djHRot4w745drDYVL 4Bug==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=P59bcRAD; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1233 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778722821; x=1779327621; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=ccEou5hWoFJuqFU/P7NttKxNDBSZFvfrVjeGmqAB9KM=; b=aYZRhuRVNeZtG4SNbU+977JuTp4wYwjmpJQ65fQA3H3n9IUql7H9/exLO2ptc59fg0 GzJa1Jg8SOjGMRUcezc7mczytu4Ok0OOGYAFpdj6DwIxm20XZW+7v1VTnZ+gEAb35+Jp ZOmsnjUUYTLewk4Ub3a/fzaer1B00lcErEnN5j/k2V+G9hygxJGWiXkY43PuL74kczJ4 wlotyXalm43Trh54RMhXVyxPaPWEpiMJh9YHrOHdn7j60lbUnYaG2FLkurj08vQURTzQ lr6b2lJ4Oo3k70YvLsqosDP79PytrmDV/DMC/x+D/tgO2jpZN9p576ds3Ws+fFyZ9kNl UYsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778722821; x=1779327621; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ccEou5hWoFJuqFU/P7NttKxNDBSZFvfrVjeGmqAB9KM=; b=T2f3JUvz9yZMlF7r8RbBv6kDnyiEvgGqvnomS3PiZVhA48HU5Jbj7rUIcA/RmSLQz/ sItr2wCQQCTlutuk+yCBLdsurPH+8ETW3x4HfyrgoVFL4CpP2wa+gew0XYBinmb/lrCv CIvx9hgoZXw9y45ff2tZN/sOFJJ5pFTQacYwoXvAlgPgegxBN9mChpyasRL+cf+RhzYe eyHMFNDYDEq3y1pcG2quSJP+RjCbzq76gVpHEpNDR4tC96BjOhNEW0DTkOKy5Gm17k0D Qo8oA6czyNP4QkHO/4huxrcYqI6XCmos6+N8AuL/fp4DxG+/8Lg85U2PJLeTfj8YD+mH 9DtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778722821; x=1779327621; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=ccEou5hWoFJuqFU/P7NttKxNDBSZFvfrVjeGmqAB9KM=; b=lDv5V7KTOv40az8rz/59Fpc65bx4zhudnHICW4YZvEba1JVD0CfhM++BmPFHGeQrUj mBCqZI35RAys+dhfuws76xSFtEEIDuKLjSTBIQNgyM5gMYydSZdFPShvZJD+rqPNfJnN Px/CZiuw5exgQpwkJjz7+jpAFBlBW7I0x6qz8ri7FlaCzZCTBElHfxNsSuqBjl8tYJc9 fwcpN3OrO/W9i20kEE1q7WwanULB5883y8qt/uK3W3H0QNZ6Ujn+iIOb1dcG4CgGkFYk pGd37WywgeFNS5qHD1QRmUNpjRWlvDT5qp3ZaPOuca273GndYTn7llotFQ/Dc+Ffmzf9 OMvA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+VeQpkddfi/IbLdVs6sBzdfMAU6VwrEX1gA4Y94V21dux+7AYbNbWQc7mdv6IABqDzYMUmkeemIxXh@gnusha.org X-Gm-Message-State: AOJu0Yx/AyOMSLpbinfDD3UVoTZssiSZNWs00gu0JNQV7BnW+ditID0G RUJdc7KIm1K6wZvQW9F/WVqs6ealZsQ9gKIal70z1n4W947eM1h9SxCM X-Received: by 2002:a05:6871:e01a:b0:430:29f5:285f with SMTP id 586e51a60fabf-439ce5fd9d0mr3279523fac.35.1778722821215; Wed, 13 May 2026 18:40:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMJz7gFnFHeENT3iSS+iutKcABej2R1IESc8suPzFUtaw==" Received: by 2002:a05:6871:3510:b0:41c:24d9:eb8b with SMTP id 586e51a60fabf-43a01129c6cls127060fac.0.-pod-prod-02-us; Wed, 13 May 2026 18:40:15 -0700 (PDT) X-Received: by 2002:a05:6808:1783:b0:479:ed26:fbca with SMTP id 5614622812f47-482b2db4b30mr3540814b6e.37.1778722815371; Wed, 13 May 2026 18:40:15 -0700 (PDT) Received: by 2002:a05:620a:4056:b0:8d6:1bc4:a7bc with SMTP id af79cd13be357-90f7a3fd93ams85a; Wed, 13 May 2026 18:38:28 -0700 (PDT) X-Received: by 2002:a05:6214:3bc7:b0:8b4:7009:3b69 with SMTP id 6a1803df08f44-8c7b91d133dmr99660976d6.7.1778722707583; Wed, 13 May 2026 18:38:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778722707; cv=pass; d=google.com; s=arc-20240605; b=cFEY8zpRFAF5LI7xvhD/JCcttj+2UtPcHoTXflnfRX/Uw3fC6Ari/O+Xr1DtHiUPP2 5yAZi7eT3pag6enElQ2jR9FsDHe2u2WkU4l5jgs4+FNlRNztH5fxbXz8g3cOE7jCxmPU UdPHa2deOpGjA3+L/Oq2+Uoyw1eUz/pDXuw+vsu/PsZbQlhfxEMtek0dOQ88z/eLvRjW iPnVpPbMLyN+WUBTN165fdJSZ6fMzJQOdvWsSZtURC5YeCRbA9racNuxn5VSQT6qTDfX ukSeFB4pI3h5gBfye0FFu+/HM1o6oW165q7/VVkpsG7Xq0pii6UnIMYWwjKrPaYKIOMP zbKA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=4nx9UT6AwT71SwBE/ZgRg+LUhioqHoEa5nHXCC2/9ws=; fh=rkm3bHbFkkqaOCEhDYIrUdh+uNF0aEpt1sjHeEyiFh0=; b=DI5mM6naXXtutVUDSKFBgdNutxLI7v1NpAwpj75k/iunYavzRkXSB+7BPx54t41N01 7XxJ0dIK3NhTAZkSvdXh0fUDHW+7GOcTA7cWbW/1lgq1MenoRqyQRW0uSMWP9HJbMnue GWGUzQHW143ebZ/LFItK8wbnxchWEnQP1xgYshzGO8QSXwAIUt2eWGxM1KOX52Iqwz3P UfgCLcdefysy78XtE/jAYugV3TOIbaJk9m0wkXycZB2iVOjIYrNB0H9D7NBftlT4WAFY 3LITXMJJthy9BovTpnHWZ/ur4CF6gEH0ueobZqn2zNQSK9v/MroxyUAG7G8EZ4MLMPQy 8Pkw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=P59bcRAD; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1233 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dl1-x1233.google.com (mail-dl1-x1233.google.com. [2607:f8b0:4864:20::1233]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8c9094e185asi396836d6.4.2026.05.13.18.38.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2026 18:38:27 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1233 as permitted sender) client-ip=2607:f8b0:4864:20::1233; Received: by mail-dl1-x1233.google.com with SMTP id a92af1059eb24-133466cf955so1386439c88.0 for ; Wed, 13 May 2026 18:38:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778722706; cv=none; d=google.com; s=arc-20240605; b=FztY7QB4dW/+dvemv/oVerGc4bbm+mGo08oW+mLwgxeWefkx9WN4KsszpB7n0pbR/+ xzpSiwdWCOPKJbmltJF1Klf1IlU1proitj2GRAX5SdvrAiaANTp20QOLDg+SEHoK2DFI b+rw3Xvp10vUrgownedy5sTd8/6914f2dbQENtocY8lcEbS+tbbzjAdHkaVkr7uqRfW6 zp4BIwKoleNeluS+NYEVOeIPgn11rLyLBnwhegillkijIwX5P7QywhHJaSokfU2gStgi KqsCi7dGv5uYgg7GuYkcGR+IDkqKMlLaMWeYfC1JZi1zhtDgXKcibaSGPTKGyMZ9DnlS 0WeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=4nx9UT6AwT71SwBE/ZgRg+LUhioqHoEa5nHXCC2/9ws=; fh=rkm3bHbFkkqaOCEhDYIrUdh+uNF0aEpt1sjHeEyiFh0=; b=h6G5AKAaQchiyvsL768X8T5F7ifLaJQBB53Aa/0/WyseA4igJkAiDZ1cyWd72cIuKn WYA+6z6T3OXWZ5+XjWwKiLNnOesZWuVLaY5l3SRO1awt8CwtyG3vCqJktysGWvVtugZL YyHU3PkVJLuqTvOZG9tkOqnXLhLtmEb4yUwChAOzKLKnyB61tlHUkyqUNXD+fxlVcTdy gRoQB40YPGPv0AdTtQXfsnD7RWtv48vm9txtncRRWnrTs9EqmZuh97MieDy34GWydGZt Za8yWVIPd5xf7LsXr4zmEDF0QKrbu7OzUS8T9hbKmAPWgwmQtP+ogG1X54GOPka+SRo8 v44Q==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OHRFNKNNbcovGvh/PGfkvnuB9tyTuAJ6g5QATk9TuMx92z7BrE3vGTIHHZXo8v 5ohTJCGuvep4dO2izuIU1vqQ6ZyUaXdywqNiMv194XJ9Dxc/RK6BjJJtMXEbBESnbbPCFcnCQ1u bL/HpxhxrBX+3tSxzsZoJyX0/gRm1DhpRVV0vKetjazPcN2IyC0zKJT1h52TXJwhL5jmCqLyiId IAOXg25N8wcc4Q/MHR0jvObNFVgOO7Zg51x/v677Atl+TxohxGvJJX7l3TlcX0x3VrbgYW2L5kn dPrRQ0Bs X-Received: by 2002:a05:7022:1603:b0:12d:b7e5:a691 with SMTP id a92af1059eb24-1342ee3f0d0mr3944127c88.7.1778722705761; Wed, 13 May 2026 18:38:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 14 May 2026 02:38:14 +0100 X-Gm-Features: AVHnY4KjshofRrrElvhbxbLlRRTsgEhEP6TqMO07CTx1EdHI-n018K7X9EkDIJU Message-ID: Subject: [bitcoindev] Re: Garbled Circuit and Channel Jamming To: Bitcoin Development Mailing List Cc: btc@ariard.me Content-Type: multipart/alternative; boundary="00000000000007eab50651bd27ce" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=P59bcRAD; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1233 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000007eab50651bd27ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, > Two, Alice and Caroll can always collude to have Bob never getting the HT= LC > secret and as such being penalized with the highest fee on the Alice - Bo= b > channel. Somehow, Bob should be able to produce a proof proving that the > heartbeat protocol has played out in integrality on the Bob-Caroll channe= l > and that no HTLC secret was ever learn from Caroll. After writing this initial post and walking back to home, I figured out it was precisely broken on this precise step and never took time until now to say why. There is an easy way for Caroll to escape the replay of Bob's hear= tbeat transcript on Alice-Bob channel, i.e Caroll can just unilaterally force-clo= se the Bob-Caroll channel and provide the HTLC secret on-chain. So to mitigate this, Bob's proof should be composed of the concatenation of the "off-chain" ping-pong transcript _or/and_ the "on-chain" witness or a trace of it. Intuitively, to satisfy any penaly script mechanism on the Alice-Bob channel, the "on-chain" and "off-chain" state has to be reconciliated, as any "on-chain" or "off-chain" outcome is indeed valid. For the trace of the Bob-Caroll "closure" witness, it sounds it could be achieved with some adaptor signature scheme, where Caroll is the oracle for the Alice-Bob chan, the message signed would be the UTXO or the script only, though this is asking more thinking (the signature is pure noise, so it could *not* be set ahead of the reveal on the AB-link)= . Anyway, I'm thinking that this class of "amnesic" knowledge transfer to link an off-chain events between 2 contracting protocols rooted in two distinct UTXOs where contracting parties might have competing interest is very interesting. In my mind, a practical solution would be valuable beyond the pure scope of channel jamming. The operational model would still rely on the counterparties not hitting the chain, though in practice the revocation - penalty mechanism of LN is already working (how many justice txn have seen published on mainnet ? probably in the order of 2-digits). Best, Antoine OTS hash: 7f08ea7660c86cdbc6f8950782081a46f7daadd668a610d025bbeabb52d8828e Le jeu. 22 janv. 2026 =C3=A0 06:41, Antoine Riard = a =C3=A9crit : > Hi, > > Recently, before the EoY vacation to be more precise, I gave a talk on th= e > BitVm > flavors and their advances, which was the opportunity to browse back a bi= t > the > old cryptographic primitive underpinning the claimed advances. One of suc= h > primitive > is indeed the old idea of "garbled circuits" and how to order knowledge > transfer > among two distrusted parties [0]. > > What it's interesting for this class of cryptographic protocol is the wid= e > class > of secure multi-party game that can be built from it, and a bit of > analysis lets > you modelize quite easily channel jamming as a multi-party game (Alice, > Bob, Caroll > the next hop and the blockchain). Few years ago, when with Gleb Naumenko, > we studied > the solution design space for jamming, we briefly mentioned how "smart > contract" > (a.k.a something something covenant for more expressivity), could be a > potential > solution [1] [2]. > > Looking more on "garbled circuits" made me realize that actually we might > have already > the primitives to envision "native contract-based" solutions to the > channel jamming > problem, and this with no consensus change. I.e beyond the known "monetar= y > solutions" > and "reputation-based" solutions [3] > > This is not the intent of this short post to discuss the merits of the > current > reputation-measured channel mitigation, which still have a lot of good > properties > like local vs global, monadic vs consensus, non-fungible vs fungible and > lightning-endogenous vs exogenous on some scarce ressource. Rather than > it's to > bring some prolegomena of a solution to the problem of a channel jamming, > as it has > been said elegantly and succintly: > > "The holy grail? is indeed charging fees as a function of the time the > HTLC was held. > As for now, we are not aware of a reasonable way to do this. There is no > universal > clock, and there is no way for me to prove that a message was sent to you= , > and you > decided to pretend you didn=E2=80=99t. It can easily happen that the fee = for a > two-week > unresolved HTLC is higher than the fee for a quickly resolving one". [4] > > Solving this problem, in my view, means to reconciliate the off-chain > notion > of shared time among the 2 Lightning state machines with the on-chain > imperative > notion of time. A effective notion of time enabling one to determine > objectively > if an event did happen or not (e.g a message exchange) [0]. All the > difficulty > being that off-chain there is no such notion of shared time. > > Let's start with a strawman protocol, that is moving one step closer to a= n > effective notion of shared time among 2 Lightnig state machines. > > One way to solve channel jamming would be to have a (taproot) tree of > scripts > covering the whole time range for which the funds are locked in the offer= ed > HTLC (so ``). I.e for each block belonging to the cltv_expir= y > range, > Bob pays Alice a penalty from his `counterparty_balance` (on Alice's > commitment_tx) > where "local channel time" is ticked by some monotonic counter. This tree > of > scripts would become valid to be spend after some timelock enforced grace > delay. > > It should be noted, that if the HTLC routing is extending beyond the reac= h > of > Bob, Bob has no guarantee that he will get the HTLC secret before the upp= er > bound of Alice's cover penaly script is reached on the Alice - Bob > channel, e.g > time T + 200 > > As soon as the offered HTLC has been committed on both parties commitment > transactions (Alice is the latest's one to receive the RAA), Alice and Bo= b > starts to exchange ping-pong messages where each message is increasing th= e > monotonic counter. Those messages might have as a data payload the preima= ge > for which the Alice to Bob offered HTLC is pending. > > While Bob might have received the HTLC secret from Caroll at absolute > blockchain > time T + 100, and give it to Alice at time T + 110 i.e before the > expiration of > the hard `cltv_expiry`, Alice is always in a position to equivocate and > said she > never received the preimage from Bob ping-pong message. > > So this strawman protocol is obviously broken. > > Let's consider the same protocol, with few differences, the ping-pong > messages > between Alice and Bob are scheduled on some hearbeat rythm, so message > happens > every X, in way that Alice cannot guess if yes or no, a secret exchange > did happen > between Bob and Caroll about the next hop HTLC secret. > > The penalty scripts are also modified where Bob can now prove a ping > message > at time T + 110 has been viewed by Alice, with the correct HTLC secret. S= o > Alice would make a claim by broadcasting a transaction to claim the outpu= t, > and Bob would be able to dismiss the penaly with a valid proof of preimag= e > transfer. > > Other modification, all ping-ping messages sent by Bob from Alice would b= e > now an oblivious transfer, where Alice would sign all the pongs and the > incremented counter [6], among those pongs would be a ciphered HTLC secre= t. > This mechanism allows Bob to obtain an off-chain proof (e.g go to unblind > the > signed HTLC secret) that Alice has seen a preimage at time T + 110, and > they > can now update the HTLC commitment txn, back to the normal flow. If Alice > stucks > the channel, she "knows" that she would loss the proving game with Bob. > > However, this strawman protocol still present 2 bottlenecks, that are > described > in their main lines. > > One, there is no guarantee that Alice engage in the heartbeat protocol, s= o > the HTLC commitment transaction should present some scripting path where > the > ping-pong messages are numbered, and if this has not reach some threshold > before the `cltv_expiry`, she got punished on her local balance. One > counterparty > should always engaged in the "amnesic" knowledge transfer, under the risk > of > on-chain punishment. > > Two, Alice and Caroll can always collude to have Bob never getting the HT= LC > secret and as such being penalized with the highest fee on the Alice - Bo= b > channel. Somehow, Bob should be able to produce a proof proving that the > heartbeat protocol has played out in integrality on the Bob-Caroll channe= l > and that no HTLC secret was ever learn from Caroll. That's where "garbled > circuits" might be useful in minimizing the amount of knowledge leaked fr= om > Bob-Caroll channel to Alice, while still ensuring fairness [7]. > > To conclude, this short post is advancing the idea that oblivious transfe= r > class of protocol, might be able to solve the channel jamming issue where > the messages are exchanged without all the parties "knowing" what has bee= n > exchanged, and being punished by on-chain scripts, if the equivocate from > the knowledge transfer they engage into. I'm not making the claim that th= is > strawman protocol is fully sound game-theoretic wise, though I found if a > shared notions of time can be enforced among 2 Lightning channel > counterparties, > the implications are wider than just solving channel jamming. > > Anyway, I don't have time to flush more the ideas exposed here [8], thoug= h > I > was eager to mention them if some people are bored and wish to play with > interesting cryptographic primitives actually solving real-world lightnin= g > problems. > > Cheers, > Antoine > OTS hash: 98c12f58d4e39e85427cca156cc548d225b2ecb45296be70a93d3534b77aa1c= 7 > > [0] "How to Generate and Exchange Secrets" - Andrew Yao, 1986. > [1] See "Chapter 4 - Solution Design Space" - "Solving channel jamming > issue of the lightning network", Naumenko / Riard, 2022 > [2] As the joking goes "Oh a workable solution to a bitcoin problem > involving > a consensus change, that's a very ice theoretical paper you've here, sir!= ". > [4] See for more - "Unjamming Lightning: A Systematic Approach", > Clara Shikhelman and Sergei Tikhomirov, 2022. > [4] > https://delvingbitcoin.org/t/fee-based-spam-prevention-for-lightning/1524= /2 > [5] "If a tree falls in the forest and no one is around to hear it, does = it > make a sound ?" "A Network of Micropayments Channels Can Solve > Scalability" - > Lightning Network paper. > [6] E.g counter could fit in a nSequence field. > [7] I'm wawing aside the biggest witness trace that Lightning nodes might > have to pay, as one downside of this kind of solution compared to the oth= er > ones. > [8] Yes, the subject would have deserved a real research paper, but > writing your > own bitcoin full-node it's real work, no kidding. > --=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/= CALZpt%2BHJ-iRD9dZQMwmbVuov8sbk9nSkyzPcBS09U9qzxXpzsQ%40mail.gmail.com. --00000000000007eab50651bd27ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi,

> Two, Alice and Caroll can alway=
s collude to have Bob never getting the HTLC
> secret and as such bei=
ng penalized with the highest fee on the Alice - Bob
> channel. Someh=
ow, Bob should be able to produce a proof proving that the
> heartbea=
t protocol has played out in integrality on the Bob-Caroll channel
> =
and that no HTLC secret was ever learn from Caroll. 

After writing t=
his initial post and walking back to home, I figured out it
was precisel=
y broken on this precise step and never took time until now to
say why. =
There is an easy way for Caroll to escape the replay of Bob's heartbeat=

transcript on Alice-Bob channel, i.e Caroll can just unilaterally force=
-close
the Bob-Caroll channel and provide the HTLC secret on-chain. 
=

So to mitigate this, Bob's proof should be composed of the concaten=
ation
of the "off-chain" ping-pong transcript _or/and_ the &qu=
ot;on-chain" witness
or a trace of it. Intuitively, to satisfy any =
penaly script mechanism on
the Alice-Bob channel, the "on-chain&quo=
t; and "off-chain" state has to be
reconciliated, as any "=
;on-chain" or "off-chain" outcome is indeed valid.

Fo=
r the trace of the Bob-Caroll "closure" witness, it sounds it cou=
ld
be achieved with some adaptor signature scheme, where Caroll is theoracle for the Alice-Bob chan, the message signed would be the UTXO
or=
 the script only, though this is asking more thinking (the signature
is =
pure noise, so it could *not* be set ahead of the reveal on the AB-link).
Anyway, I'm thinking that this class of "amnesic" knowl=
edge transfer
to link an off-chain events between 2 contracting protocol=
s rooted in
two distinct UTXOs where contracting parties might have comp=
eting interest
is very interesting. In my mind, a practical solution wou=
ld be valuable
beyond the pure scope of channel jamming.

The oper=
ational model would still rely on the counterparties not hitting
the cha=
in, though in practice the revocation - penalty mechanism of LN
is alrea=
dy working (how many justice txn have seen published on mainnet ?
probab=
ly in the order of 2-digits).

Best,
Antoine
OTS hash: 7f08ea76=
60c86cdbc6f8950782081a46f7daadd668a610d025bbeabb52d8828e
=
Le=C2=A0jeu. 22 janv. 2026 =C3=A0=C2=A006:41, Antoine Riard= <antoine.riard@gmail.com= > a =C3=A9crit=C2=A0:
Hi,

Recently, before the EoY vacation to= be more precise, I gave a talk on the BitVm
flavors and their advances,= which was the opportunity to browse back a bit the
old cryptographic pr= imitive underpinning the claimed advances. One of such primitive
is inde= ed the old idea of "garbled circuits" and how to order knowledge = transfer
among two distrusted parties [0].

What it's interest= ing for this class of cryptographic protocol is the wide class
of secure= multi-party game that can be built from it, and a bit of analysis lets
= you modelize quite easily channel jamming as a multi-party game (Alice, Bob= , Caroll
the next hop and the blockchain). Few years ago, when with Gleb= Naumenko, we studied
the solution design space for jamming, we briefly = mentioned how "smart contract"
(a.k.a something something cov= enant for more expressivity), could be a potential
solution [1] [2].
=
Looking more on "garbled circuits" made me realize that actua= lly we might have already
the primitives to envision "native contra= ct-based" solutions to the channel jamming
problem, and this with n= o consensus change. I.e beyond the known "monetary solutions"
= and "reputation-based" solutions [3]

This is not the inten= t of this short post to discuss the merits of the current
reputation-mea= sured channel mitigation, which still have a lot of good properties
like= local vs global, monadic vs consensus, non-fungible vs fungible and
lig= htning-endogenous vs exogenous on some scarce ressource. Rather than it'= ;s to
bring some prolegomena of a solution to the problem of a channel j= amming, as it has
been said elegantly and succintly:

"The ho= ly grail? is indeed charging fees as a function of the time the HTLC was he= ld.
As for now, we are not aware of a reasonable way to do this. There i= s no universal
clock, and there is no way for me to prove that a message= was sent to you, and you
decided to pretend you didn=E2=80=99t. It can = easily happen that the fee for a two-week
unresolved HTLC is higher than= the fee for a quickly resolving one". [4]

Solving this problem= , in my view, means to reconciliate the off-chain notion
of shared time = among the 2 Lightning state machines with the on-chain imperative
notion= of time. A effective notion of time enabling one to determine objectively<= br>if an event did happen or not (e.g a message exchange) [0]. All the diff= iculty
being that off-chain there is no such notion of shared time.
<= br>Let's start with a strawman protocol, that is moving one step closer= to an
effective notion of shared time among 2 Lightnig state machines.<= br>
One way to solve channel jamming would be to have a (taproot) tree o= f scripts
covering the whole time range for which the funds are locked i= n the offered
HTLC (so `<cltv_expiry>`). I.e for each block belong= ing to the cltv_expiry range,
Bob pays Alice a penalty from his `counter= party_balance` (on Alice's commitment_tx)
where "local channel = time" is ticked by some monotonic counter. This tree of
scripts wou= ld become valid to be spend after some timelock enforced grace delay.
It should be noted, that if the HTLC routing is extending beyond the reac= h of
Bob, Bob has no guarantee that he will get the HTLC secret before t= he upper
bound of Alice's cover penaly script is reached on the Alic= e - Bob channel, e.g
time T + 200

As soon as the offered HTLC has= been committed on both parties commitment
transactions (Alice is the la= test's one to receive the RAA), Alice and Bob
starts to exchange pin= g-pong messages where each message is increasing the
monotonic counter. = Those messages might have as a data payload the preimage
for which the A= lice to Bob offered HTLC is pending.

While Bob might have received t= he HTLC secret from Caroll at absolute blockchain
time T + 100, and give= it to Alice at time T + 110 i.e before the expiration of
the hard `cltv= _expiry`, Alice is always in a position to equivocate and said she
never= received the preimage from Bob ping-pong message.

So this strawman = protocol is obviously broken.

Let's consider the same protocol, = with few differences, the ping-pong messages
between Alice and Bob are s= cheduled on some hearbeat rythm, so message happens
every X, in way that= Alice cannot guess if yes or no, a secret exchange did happen
between B= ob and Caroll about the next hop HTLC secret.

The penalty scripts ar= e also modified where Bob can now prove a ping message
at time T + 110 h= as been viewed by Alice, with the correct HTLC secret. So
Alice would ma= ke a claim by broadcasting a transaction to claim the output,
and Bob wo= uld be able to dismiss the penaly with a valid proof of preimage
transfe= r.

Other modification, all ping-ping messages sent by Bob from Alice= would be
now an oblivious transfer, where Alice would sign all the pong= s and the
incremented counter [6], among those pongs would be a ciphered= HTLC secret.
This mechanism allows Bob to obtain an off-chain proof (e.= g go to unblind the
signed HTLC secret) that Alice has seen a preimage a= t time T + 110, and they
can now update the HTLC commitment txn, back to= the normal flow. If Alice stucks
the channel, she "knows" tha= t she would loss the proving game with Bob.

However, this strawman p= rotocol still present 2 bottlenecks, that are described
in their main li= nes.

One, there is no guarantee that Alice engage in the heartbeat p= rotocol, so
the HTLC commitment transaction should present some scriptin= g path where the
ping-pong messages are numbered, and if this has not re= ach some threshold
before the `cltv_expiry`, she got punished on her loc= al balance. One counterparty
should always engaged in the "amnesic&= quot; knowledge transfer, under the risk of
on-chain punishment.

= Two, Alice and Caroll can always collude to have Bob never getting the HTLC=
secret and as such being penalized with the highest fee on the Alice - = Bob
channel. Somehow, Bob should be able to produce a proof proving that= the
heartbeat protocol has played out in integrality on the Bob-Caroll = channel
and that no HTLC secret was ever learn from Caroll. That's w= here "garbled
circuits" might be useful in minimizing the amou= nt of knowledge leaked from
Bob-Caroll channel to Alice, while still ens= uring fairness [7].

To conclude, this short post is advancing the id= ea that oblivious transfer
class of protocol, might be able to solve the= channel jamming issue where
the messages are exchanged without all the = parties "knowing" what has been
exchanged, and being punished = by on-chain scripts, if the equivocate from
the knowledge transfer they = engage into. I'm not making the claim that this
strawman protocol is= fully sound game-theoretic wise, though I found if a
shared notions of = time can be enforced among 2 Lightning channel counterparties,
the impli= cations are wider than just solving channel jamming.

Anyway, I don&#= 39;t have time to flush more the ideas exposed here [8], though I
was ea= ger to mention them if some people are bored and wish to play with
inter= esting cryptographic primitives actually solving real-world lightning
pr= oblems.

Cheers,
Antoine
OTS hash: 98c12f58d4e39e85427cca156cc5= 48d225b2ecb45296be70a93d3534b77aa1c7

[0] "How to Generate and E= xchange Secrets" - Andrew Yao, 1986.
[1] See "Chapter 4 - Solu= tion Design Space" - "Solving channel jamming
issue of the lig= htning network", Naumenko / Riard, 2022
[2] As the joking goes &quo= t;Oh a workable solution to a bitcoin problem involving
a consensus chan= ge, that's a very ice theoretical paper you've here, sir!".[4] See for more - "Unjamming Lightning: A Systematic Approach",=
Clara Shikhelman and Sergei Tikhomirov, 2022.
[4] https://delvingbitcoin.org/t/fee-based-spam-prevention-for-lig= htning/1524/2
[5] "If a tree falls in the forest and no one is = around to hear it, does it
make a sound ?" "A Network of Micro= payments Channels Can Solve Scalability" -
Lightning Network paper.=
[6] E.g counter could fit in a nSequence field.
[7] I'm wawing a= side the biggest witness trace that Lightning nodes might
have to pay, a= s one downside of this kind of solution compared to the other
ones.
[= 8] Yes, the subject would have deserved a real research paper, but writing = your
own bitcoin full-node it's real work, no kidding.

--
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/bitcoindev/CALZpt%2BHJ-iRD9dZQMwmbVuov8sbk9nSkyzPcBS09U9qzxXpzsQ%40ma= il.gmail.com.
--00000000000007eab50651bd27ce--