From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 42245C000B for ; Sun, 6 Mar 2022 20:38:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 36F8040436 for ; Sun, 6 Mar 2022 20:38:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fzvSk32cMbM for ; Sun, 6 Mar 2022 20:38:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp2.osuosl.org (Postfix) with ESMTPS id 7751D40377 for ; Sun, 6 Mar 2022 20:38:26 +0000 (UTC) Date: Sun, 06 Mar 2022 20:38:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646599103; bh=YW3+AtI7ZUpAvwAIy4cEqvLiroRtykkU8PYumUIqFO0=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=Q/c51rmR2YPptKb6JPeHxZ3D6wZYj1jogHPsrSivjAd0IefprYPt0Zfr+l5W3EAIe Oq1hbyJd1PG4nV7ICnNoOqJjeKyCwq1EzSPrZkkXVP/XY/mWZf2npIyGn72eFcMoJg m5PcO52V58mX/6lVvdFZZROAtQpljw/74BRse1joyaeF5X2KSzyMZaQ1S9ytRbBfN8 iL6avQkJw6J0b4Kj0phjPhGY+EXHm0dYP3CkWpalJABtwVCuMwokVnciahii1NE8o6 hgpoM9JG63JyXzGBmf1rp+XAyA9ji0CjckZHCNUC7hAnzz0u/gHuBuQ0a04xU4MoBG C/vhaChniHG7A== To: Billy Tetrud From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <-3inEV9Skl4K8wQefM7I0EbYzQc-zWV4QPgJSXKNxx0X_2EbwyTRmVjwooU1a8wFRNU41Cr41hb-Ajno_nV39U9rOge1oaUg9MvKmQ7-v30=@protonmail.com> In-Reply-To: References: <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2022 20:38:28 -0000 Good morning Billy, > Even changing the weight of a transaction using jets (ie making a script = weigh less if it uses a jet) could be done in a similar=C2=A0way to how seg= wit separated=C2=A0the witness out. The way we did this in SegWit was to *hide* the witness from unupgraded nod= es, who are then unable to validate using the upgraded rules (because you a= re hiding the data from them!), which is why I bring up: > > If a new jet is released but nobody else has upgraded, how bad is my se= curity if I use the new jet? > > Security wouldn't be directly affected, only (potentially) cost. If your = security depends on cost (eg if it depends on pre-signed transactions and i= s for some reason not easily CPFPable or RBFable), then security might be a= ffected if the unjetted=C2=A0scripts costs substantially more to mine.= =C2=A0 So if we make a script weigh less if it uses a jet, we have to do that by t= elling unupgraded nodes "this script will always succeed and has weight 0",= just like `scriptPubKey`s with `<0> ` are, to pre-SegWit nodes= , spendable with an empty `scriptSig`. At least, that is how I always thought SegWit worked. Otherwise, a jet would never allow SCRIPT weights to decrease, as unupgrade= d nodes who do not recognize the jet will have to be fed the entire code of= the jet and would consider the weight to be the expanded, uncompressed cod= e. And weight is a consensus parameter, blocks are restricted to 4Mweight. So if a jet would allow SCRIPT weights to decrease, upgraded nodes need to = hide them from unupgraded nodes (else the weight calculations of unupgraded= nodes will hit consensus checks), then if everybody else has not upgraded,= a user of a new jet has no security. Not even the `softfork` form of chialisp that AJ is proposing in the other = thread would help --- unupgraded nodes will simply skip over validation of = the `softfork` form. If the script does not weigh less if it uses a jet, then there is no incent= ive for end-users to use a jet, as they would still pay the same price anyw= ay. Now you might say "okay even if no end-users use a jet, we could have fulln= odes recognize jettable code and insert them automatically on transport". But the lookup table for that could potentially be large once we have a few= hundred jets (and I think Simplicity already *has* a few hundred jets, so = additional common jets would just add to that?), jettable code could start = at arbitrary offsets of the original SCRIPT, and jettable code would likely= have varying size, that makes for a difficult lookup table. In particular that lookup table has to be robust against me feeding it some= section of code that is *almost* jettable but suddenly has a different opc= ode at the last byte, *and* handle jettable code of varying sizes (because = of course some jets are going to e more compressible than others). Consider an attack where I feed you a SCRIPT that validates trivially but i= s filled with almost-but-not-quite-jettable code (and again, note that expa= nded forms of jets are varying sizes), your node has to look up all those j= ets but then fails the last byte of the almost-but-not-quite-jettable code,= so it ends up not doing any jetting. And since the SCRIPT validated your node feels obligated to propagate it to= o, so now you are helping my DDoS. > >=C2=A0 I suppose the point would be --- how often *can* we add new jets? > > A simple jet would be something that's just added to bitcoin software and= used by nodes that recognize it. This would of course require some debate = and review to add it to bitcoin core or whichever bitcoin software you want= to add it to. However, the idea I proposed in my last email would allow an= yone to add a new jet. Then each node can have their own policy to determin= e which jets of the ones registered it wants to keep an index of and use. O= n its own, it wouldn't give any processing power optimization, but it would= be able to do the same kind of script compression you're talking about op_= fold allowing. And a list of registered jets could inform what jets would b= e worth building an optimized function for.=C2=A0This would require a conse= nsus change to implement this mechanism, but thereafter any jet could be re= gistered in userspace. Certainly a neat idea. Again, lookup table tho. Regards, ZmnSCPxj