From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 21 Jan 2026 23:09:34 -0800 Received: from mail-oi1-f185.google.com ([209.85.167.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vioov-0008Nf-Nq for bitcoindev@gnusha.org; Wed, 21 Jan 2026 23:09:34 -0800 Received: by mail-oi1-f185.google.com with SMTP id 5614622812f47-45c72be7f0dsf1686595b6e.3 for ; Wed, 21 Jan 2026 23:09:33 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1769065767; cv=pass; d=google.com; s=arc-20240605; b=ODxplytFXFrVR8Ra9Mg2Dum0B8/Hr3vKmrWOVSpKuCmkEQgbiYI1kzLMeyu/gpZrdy 4xZH3spGLEgocbSuTIzHPunmAtmJXIcwj2CqRMuTZxWwhJUQLzrTVkKuij+od9Ic7vH6 GZLalZrT/MIsBqufzpvadRvA5YvSQMveGzvVHrrY2aApxZJTlQ62afH5lCI2B9mmLeg5 D38O0j66ZhpiumjbNf5HJptRcVZnCIjGYS4vPRhOYyUcgA8qNhH/aKYrPCzyndavIoGp cpjlsS0O1oSUT3BRbs9nV3qIkukAEPMdBqtIFv7wVya1zCc7oCU6H0aqadAePUP0V70v Kz6Q== 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 :mime-version:sender:dkim-signature:dkim-signature; bh=5ISzlX4u8nZNqsyviLAHr9tlVCjx0gNQuOX6hiZn+S4=; fh=8luvAtUXgNeGL4VrPZzVDBJeMxV/tbRcmMd/FX/cusE=; b=Nw5YZmOiTkxE1mMtIsePJ+/H/ErQktJfRk1FgS0a3xueugvGsWuJ/yin1ab/sV79hM xZPeR4K3qhSYVLIDXqLdbBwjm07m5Kck3WKWCHJkAvaIa7i8WbaGav/kuU+SCmZm0o6r c4vzcyohD1bxMOFSwyMUMSgU/LuefSUDWt59ongeD7wgrWA7Utvx4Elh66ml9b5WgXqf EpAD30Ay2RO0M7m29mekdRxHYUmna43Vqk3zaJBV6RAGlbeyXw0VSJa5rdJZPRDOwnid Jg2nXI3YgqBWnFGx5Stbmrl7uEBfyMfiYy8FsEJ8iWzzJWoOgQnuRYfHP0ZAqLeUsFGZ Cq0g==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RahicdPl; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 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=20230601; t=1769065767; x=1769670567; 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:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=5ISzlX4u8nZNqsyviLAHr9tlVCjx0gNQuOX6hiZn+S4=; b=hj2AunwOJkviuNi3ilgeI8nBlU+E1XenUrTyCxxWt0W3xgJa8sIph4X6RoCn4FeDnS G4q5MJCefUYrTzNlA2jQVNp/yCvWRqvnCuGmw7uXF/av62j7h9I0OkP3YecG4PZtFaR+ xcZqs85ydDdgVffUJW4GoZTj341CqO1DKOotDoRmUuMXo3paDZPp6a4vMA3miYDyTuLW XIVXekCMmq6gnHGR1XTKJavnQkQf6VO0uR8dhP4woLytErdlNko1MumJNGrrwd+tEL0a iI1dVroApo6HM1gUlyIpCQMP0iyZynyrFkY/OM/uUNGzSlTRuxqjs7ENooCGcZNt8fnD r4jg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769065767; x=1769670567; 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:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=5ISzlX4u8nZNqsyviLAHr9tlVCjx0gNQuOX6hiZn+S4=; b=NZDk/rPKFYQHL+hp98JhnldeBXgBilpPzxIjs1dU2j8iOinpaEzYewPNMaSzjlSHxc eyZBw1LbPt3nSCg4IAhE17ufATxfEliFgRe6DIJKTrzLa7Zkt3SUxHOplxT5z7t08f8f b4Ppd5t8C9N3tpNDmfhgUAdMyk7wu/s7IBy/knpy62+w9c9Ik0OmzwD8SG+Mi2mDjuy+ Or1s8vEbpsmLNOkXuiUNea9uk8z+niS0LbZuVQeE8zETFSA0K91AWqK/TKMaT0MVcmLf zcmhEPch1XyHl7UzyzFDqCF+zTGCDy12kNNkcyGVeH0vvQpxTejItT5YDzV/nFpA3CKw wmoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769065767; x=1769670567; 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:mime-version :x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=5ISzlX4u8nZNqsyviLAHr9tlVCjx0gNQuOX6hiZn+S4=; b=LuTQzr0sp2coyCzRph/3BB7YXLhi2r20REEoHHpRfo9kTCzBsi4n2CK8q7chZOoBNU ghTIMv8cT6kk8VArQe4++o1Pk8lAGIiAXL/s8txEKOwNmVLsxqmuRR2S2vRH0ZF/Zy75 ImxBslHSxHNpq9qcrjaMfsYaQP7qfAh9iJ7K2SBtUO/gGdq7tm1D2gCnXGS8sZHlR1/9 D7PtsZZaH7oDtB/mDO4NeiL/Te3g8ICRWIrGrNKjiuB7r0xCXQRWcLo/DSZo5AyOvbgj whyLpefC5YH7tjtvny2vVPH74N0mZAXOGgDFYXXonf5jf8LQn1fz+ncnZFGOxQ608uUV QXDg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCV5WIofCj1YyIQ++72gK76rekl65/mT3zp1P7tvJAGeczAqnXQe0DwL3X72KhLKQPP0tYYoofCO7fII@gnusha.org X-Gm-Message-State: AOJu0YxC65QqKbJP+dXHtv+yokgcQoc3sGzsg70UWOFleW1fs9XJGtzx /2uc4mIoLaOK0+62MlyQEGmd9jkgnPINT43BiwrY+Qa5y4Z3Dd/3Vq+R X-Received: by 2002:a05:6808:1528:b0:45c:95ab:bce3 with SMTP id 5614622812f47-45c9c147e0bmr9472566b6e.46.1769065766615; Wed, 21 Jan 2026 23:09:26 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GAQtSlJp2ZEyTtb61UTfM/aJFDNxtQ7CvG8BwOW6+3Yw==" Received: by 2002:a05:6870:5a9:b0:3ec:401f:488b with SMTP id 586e51a60fabf-4088266ebf3ls313172fac.1.-pod-prod-03-us; Wed, 21 Jan 2026 23:09:22 -0800 (PST) X-Received: by 2002:a05:6808:9b8:b0:45e:5c6d:767e with SMTP id 5614622812f47-45e5c6d7b63mr5694176b6e.40.1769065762275; Wed, 21 Jan 2026 23:09:22 -0800 (PST) Received: by 2002:a05:620a:34b:b0:892:e292:65ef with SMTP id af79cd13be357-8c6dc7cb0ffms85a; Wed, 21 Jan 2026 22:41:27 -0800 (PST) X-Received: by 2002:a05:620a:31a2:b0:8b1:d8f5:6d08 with SMTP id af79cd13be357-8c6a65f3ed3mr2800903585a.0.1769064087059; Wed, 21 Jan 2026 22:41:27 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769064087; cv=pass; d=google.com; s=arc-20240605; b=e+qXLghaaW0+yzQkl8pCqm85ldX26arxSrOdHiFwLRzC6U0/VSrCAGMZALuIEM7sva MQcRybRzQVlvlB8MVUIUAAE09c75psrnuHUeQion+AwLuXD49+WAVIcAMbJ1aIBPrApR jdnj1W7hNjFkeWrSN2pmGQUK2OOsa/nM2Tdn1HxFuZ18zBRH+BajA2F84y9Fi38Qpz2A m2gheL07CrZg8Vayjkwb3g6D2pnA8uoududFbKkFxIJm9XazZhd0UDfbJV/mp/oivY68 zo0RumSFGx2RwU2kjnerHbVddhjHPN5aW4GcnDdgbr4/OVI/xOgcwUYgmMITAaTwHKKZ 1bng== 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:mime-version:dkim-signature; bh=lXKs1MllVgwT53jEEffsI0D75sGzsnhYx0JFYb0BD9Q=; fh=rkm3bHbFkkqaOCEhDYIrUdh+uNF0aEpt1sjHeEyiFh0=; b=WDdxrji9sGfbWkMhzqvJUocsdAqtsxp9ZADcVMjgnpqthRXKP/qEX/t9ItC90DkAL4 IzyvL1P1D6r7TSuLi5YF/zWA0XLk1DiyEjfAIXISfvO8gkKaekE9EtibAOuAgfPnSQZ3 TIkvNmiArTWZEyC1wuBN5XhkJVylJhTgiko/9+rlBkETmNVxKyx59sxIp/+08va06cEd UAXDeU6q+wj6EiPapFqn4ze2qFq4CBMdslQIJhDw8tfdb/iePHOuROzEd9Nut7NGSfa5 xyPcfI4HNfls9Fy4QOZEsJqNeS7WF/rR/SY2OWtGUnZEL7yR5sUKTbsGOCfyD1DgWF/I J6WQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RahicdPl; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 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-x1231.google.com (mail-dl1-x1231.google.com. [2607:f8b0:4864:20::1231]) by gmr-mx.google.com with ESMTPS id af79cd13be357-8c6a7225783si58079285a.4.2026.01.21.22.41.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 22:41:27 -0800 (PST) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 as permitted sender) client-ip=2607:f8b0:4864:20::1231; Received: by mail-dl1-x1231.google.com with SMTP id a92af1059eb24-123320591a4so749908c88.1 for ; Wed, 21 Jan 2026 22:41:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769064085; cv=none; d=google.com; s=arc-20240605; b=CvT/RcF2FiA2Y29/PSS/Bw6LUyBQ6nKdtrGWXvjkoJq+kQHWfCA1fzI6don0wougll 2DsxQCzxDzGMFjsv+YNdfK5JIE6HoV/TnXGdK7N2YKbhe1YTY9+gmqfGkAupFuT3hZ0l F1y8kL/ovGU+bE4nOLl1Nat+aiPdl1l007GW0KXg2R+WfKrI47tLZFKx2ocOCdIEjzkh sEhd+Q1YJVmjjLrm4pY6ngv5VXZUnpe0FYnfSBQG517lwm9FhIUT++L22ryk5Bezcwll Lti0t8O0eHnrS2SKmHY+TDC/Qe1EOlbIjHMLPnnp+nAfs3zG3oGIilQT6OW3lrpOu6d8 CZwQ== 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:mime-version:dkim-signature; bh=lXKs1MllVgwT53jEEffsI0D75sGzsnhYx0JFYb0BD9Q=; fh=rkm3bHbFkkqaOCEhDYIrUdh+uNF0aEpt1sjHeEyiFh0=; b=R1bUj/UsMVuamd7/BiJnA2LAvvaeg+Yq9JbmdZOciNpUPahmKO/3yVqCTsC3ZDmNqe gKYu/kc2k8oS7abBL0i2aAN5NfjdWNjC5FSvXAJgf9cgBcu6B6n5vs+mq938j4bz1i8j y5trrgshGlkIkp0IdfBIz8y3g3ta8T8sUKMiqMdiAavqF55uH+X4Yx2T44654JjwxQ/i xWV60F0iOyB5yCGTFPev2XVZeZfbi4LWxs9lYnC+rG5LiVC+BrE55Ahh2/6dQQt9GUNK oIWsiyg76ivhYBnZsXetvskceFYCKJKFE79zGJqIQGCkH/aLDmKKDcFqmUxyS0gyItAn OvOw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aL/fvCN0d6XSuSBH0jzcyZOCCENaHpb6e2VDf3XZqXLXAFR22bxDX6S8B5ZtTz g5xDkuQbZuAxdMHzRwU/PjESvG7u52tVP8ME4+SP0pEOrq4YTGVkdY26d4fOb09ns3YwPYXK5aE Pu0/d1LTUPtaj/JJPW9eD6/dlw7X9bNWndxHXNHVPP51xp+NO0hTZZLq6B3aNOzFiL7G0/bZvPk ZI5Xh6XMOqx2Q2u04iD02s41aJ5j/gYvNmYGlmS9XWG2zKVkcfKe4wBSrf/n2/ClHKT5GkrVUFW ZMX9 X-Received: by 2002:a05:7022:2394:b0:122:8d:3680 with SMTP id a92af1059eb24-1244a78c9e4mr13201202c88.40.1769064085254; Wed, 21 Jan 2026 22:41:25 -0800 (PST) MIME-Version: 1.0 From: Antoine Riard Date: Thu, 22 Jan 2026 06:41:13 +0000 X-Gm-Features: AZwV_Qi29yrFsiJMQfhuBSaeVJToJOoovqCM_5_U2l6cerb5dEE1F9BMHj2ca-A Message-ID: Subject: [bitcoindev] Garbled Circuit and Channel Jamming To: Bitcoin Development Mailing List Cc: btc@ariard.me Content-Type: multipart/alternative; boundary="00000000000062f4f90648f45450" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RahicdPl; arc=pass (i=1); spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 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 (/) --00000000000062f4f90648f45450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 primitive underpinning the claimed advances. One of such 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 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 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 "monetary 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 fo= r 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 notio= n 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 an 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 offered HTLC (so ``). I.e for each block belonging to the cltv_expiry 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 o= f 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 reach of Bob, Bob has no guarantee that he will get the HTLC secret before the upper 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 Bob starts to exchange ping-pong messages where each message is increasing the monotonic counter. Those messages might have as a data payload the preimage 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 messag= e at time T + 110 has been viewed by Alice, with the correct HTLC secret. So Alice would make a claim by broadcasting a transaction to claim the output, and Bob would be able to dismiss the penaly with a valid proof of preimage transfer. Other modification, all ping-ping messages sent by Bob from Alice would be now an oblivious transfer, where Alice would sign all the pongs 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 at time T + 110, and the= y 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, so the HTLC commitment transaction should present some scripting path where th= e 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 o= f 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 where "garbled circuits" might be useful in minimizing the amount of knowledge leaked from Bob-Caroll channel to Alice, while still ensuring fairness [7]. To conclude, this short post is advancing the idea 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 implications are wider than just solving channel jamming. Anyway, I don't have time to flush more the ideas exposed here [8], though = I was eager to mention them if some people are bored and wish to play with interesting cryptographic primitives actually solving real-world lightning problems. Cheers, Antoine OTS hash: 98c12f58d4e39e85427cca156cc548d225b2ecb45296be70a93d3534b77aa1c7 [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 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. --=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%2BGadRVjaRE%3DP7eVoPBA606-CkWP1erxCVQ%3DkPvN6zNJOg%40mail.gmail.com. --00000000000062f4f90648f45450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

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

What it's interesting for thi= s class of cryptographic protocol is the wide class
of secure multi-part= y game that can be built from it, and a bit of analysis lets
you modeliz= e quite easily channel jamming as a multi-party game (Alice, Bob, Carollthe next hop and the blockchain). Few years ago, when with Gleb Naumenko, = we studied
the solution design space for jamming, we briefly mentioned h= ow "smart contract"
(a.k.a something something covenant for m= ore expressivity), could be a potential
solution [1] [2].

Looking= more on "garbled circuits" made me realize that actually we migh= t have already
the primitives to envision "native contract-based&qu= ot; solutions to the channel jamming
problem, and this with no consensus= change. I.e beyond the known "monetary solutions"
and "r= eputation-based" solutions [3]

This is not the intent of this s= hort post to discuss the merits of the current
reputation-measured chann= el mitigation, which still have a lot of good properties
like local vs g= lobal, monadic vs consensus, non-fungible vs fungible and
lightning-endo= genous vs exogenous on some scarce ressource. Rather than it's to
br= ing some prolegomena of a solution to the problem of a channel jamming, as = it has
been said elegantly and succintly:

"The holy grail? i= s indeed charging fees as a function of the time the HTLC was held.
As f= or now, we are not aware of a reasonable way to do this. There is no univer= sal
clock, and there is no way for me to prove that a message was sent t= o you, and you
decided to pretend you didn=E2=80=99t. It can easily happ= en that the fee for a two-week
unresolved HTLC is higher than the fee fo= r a quickly resolving one". [4]

Solving this problem, in my vie= w, 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 ev= ent did happen or not (e.g a message exchange) [0]. All the difficulty
b= eing 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 an
e= ffective notion of shared time among 2 Lightnig state machines.

One = way to solve channel jamming would be to have a (taproot) tree of scriptscovering the whole time range for which the funds are locked in the offer= ed
HTLC (so `<cltv_expiry>`). I.e for each block belonging to the = cltv_expiry range,
Bob pays Alice a penalty from his `counterparty_balan= ce` (on Alice's commitment_tx)
where "local channel time" = is ticked by some monotonic counter. This tree of
scripts would become v= alid to be spend after some timelock enforced grace delay.

It should= be noted, that if the HTLC routing is extending beyond the reach of
Bob= , Bob has no guarantee that he will get the HTLC secret before the upperbound of Alice's cover penaly script is reached on the Alice - Bob cha= nnel, e.g
time T + 200

As soon as the offered HTLC has been commi= tted on both parties commitment
transactions (Alice is the latest's = one to receive the RAA), Alice and Bob
starts to exchange ping-pong mess= ages where each message is increasing the
monotonic counter. Those messa= ges might have as a data payload the preimage
for which the Alice to Bob= offered HTLC is pending.

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

So this strawman protocol is= obviously broken.

Let's consider the same protocol, with few di= fferences, the ping-pong messages
between Alice and Bob are scheduled on= some hearbeat rythm, so message happens
every X, in way that Alice cann= ot guess if yes or no, a secret exchange did happen
between Bob and Caro= ll about the next hop HTLC secret.

The penalty scripts are also modi= fied where Bob can now prove a ping message
at time T + 110 has been vie= wed by Alice, with the correct HTLC secret. So
Alice would make a claim = by broadcasting a transaction to claim the output,
and Bob would be able= to dismiss the penaly with a valid proof of preimage
transfer.

O= ther modification, all ping-ping messages sent by Bob from Alice would benow an oblivious transfer, where Alice would sign all the pongs and theincremented 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 unb= lind 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 sti= ll present 2 bottlenecks, that are described
in their main lines.
One, there is no guarantee that Alice engage in the heartbeat protocol, so=
the HTLC commitment transaction should present some scripting path wher= e the
ping-pong messages are numbered, and if this has not reach some th= reshold
before the `cltv_expiry`, she got punished on her local balance.= One counterparty
should always engaged in the "amnesic" knowl= edge 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
chan= nel. Somehow, Bob should be able to produce a proof proving that the
hea= rtbeat protocol has played out in integrality on the Bob-Caroll channel
= and that no HTLC secret was ever learn from Caroll. That's where "= garbled
circuits" might be useful in minimizing the amount of knowl= edge leaked from
Bob-Caroll channel to Alice, while still ensuring fairn= ess [7].

To conclude, this short post is advancing the idea that obl= ivious transfer
class of protocol, might be able to solve the channel ja= mming issue where
the messages are exchanged without all the parties &qu= ot;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 soun= d 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 t= ime to flush more the ideas exposed here [8], though I
was eager to ment= ion them if some people are bored and wish to play with
interesting cryp= tographic primitives actually solving real-world lightning
problems.
=
Cheers,
Antoine
OTS hash: 98c12f58d4e39e85427cca156cc548d225b2ecb= 45296be70a93d3534b77aa1c7

[0] "How to Generate and Exchange Sec= rets" - Andrew Yao, 1986.
[1] See "Chapter 4 - Solution Design= Space" - "Solving channel jamming
issue of the lightning netw= ork", Naumenko / Riard, 2022
[2] As the joking goes "Oh a work= able solution to a bitcoin problem involving
a consensus change, that= 9;s a very ice theoretical paper you've here, sir!".
[4] See fo= r more - "Unjamming Lightning: A Systematic Approach",
Clara S= hikhelman and Sergei Tikhomirov, 2022.
[4] https://delvingb= itcoin.org/t/fee-based-spam-prevention-for-lightning/1524/2
[5] &quo= t;If a tree falls in the forest and no one is around to hear it, does itmake a sound ?" "A Network of Micropayments Channels Can Solve S= calability" -
Lightning Network paper.
[6] E.g counter could fit= in a nSequence field.
[7] I'm wawing aside the biggest witness trac= e that Lightning nodes might
have to pay, as one downside of this kind o= f solution compared to the other
ones.
[8] Yes, the subject would hav= e 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.co= m/d/msgid/bitcoindev/CALZpt%2BGadRVjaRE%3DP7eVoPBA606-CkWP1erxCVQ%3DkPvN6zN= JOg%40mail.gmail.com.
--00000000000062f4f90648f45450--