From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 47186C000B for ; Sat, 5 Mar 2022 23:02:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 2CB2E4055A for ; Sat, 5 Mar 2022 23:02:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, 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 3zp2MjNQgtSd for ; Sat, 5 Mar 2022 23:02:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by smtp2.osuosl.org (Postfix) with ESMTPS id 3FBDB40558 for ; Sat, 5 Mar 2022 23:02:50 +0000 (UTC) Date: Sat, 05 Mar 2022 23:02:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646521367; bh=IMwvsSLZndB7k32vCMMwUgkfxcjGHtosP7RgZZ6wBds=; 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=TUEMt1qbX6KjR/XrfoTOAFYXazwJI26g1G80ipRY1dpZUnujBPAKA867F7t5no6QK L+AytOCTrtR4CCBylYP+fieu8gDTL3bSrbKmN4Ds2tiRO3PFOF5GhyoPiyUbuZ6rG+ 4LYppxIcl3QYweZ+aTtBeaZPprItcw/tPTOAYUWuYFFAZEuiKpiK0qF9zxyLvfliza kkDOuFEC/kdarrWOwZLgmcJjoZQmJdJH9wmgLmLrLri9ZJUUboL6CuJXLdb6Uy+mNr Gqw/HV7joQWp5vv+ssYsXeYEl01CYtojawsjXp0zfrsgzuDHc1dot357ADGxuBa1ST oPe3HFKGqgB7g== To: Billy Tetrud From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com> In-Reply-To: References: 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: Sat, 05 Mar 2022 23:02:51 -0000 Good morning Billy, > It sounds like the primary benefit of op_fold is bandwidth savings. Progr= amming as compression. But as you mentioned, any common script could be imp= lemented as a Simplicity jet. In a world where Bitcoin implements jets, op_= fold would really only be useful for scripts that can't use jets, which wou= ld basically be scripts that aren't very often used. But that inherently li= mits the usefulness of the opcode. So in practice, I think it's likely that= jets cover the vast majority of use cases that op fold would otherwise hav= e. I suppose the point would be --- how often *can* we add new jets? Are new jets consensus critical? If a new jet is released but nobody else has upgraded, how bad is my securi= ty if I use the new jet? Do I need to debate `LOT` *again* if I want to propose a new jet? > A potential benefit of op fold is that people could implement smaller scr= ipts without buy-in from a relay level change in Bitcoin. However, even thi= s could be done with jets. For example, you could implement a consensus cha= nge to add a transaction type that declares a new script fragment to keep a= count of, and if the script fragment is used enough within a timeframe (eg= 10000 blocks) then it can thereafter be referenced by an id like a jet cou= ld be. I'm sure someone's thought about this kind of thing before, but such= a thing would really relegate the compression abilities of op fold to just= the most uncommon of scripts.=C2=A0 > > > *=C2=A0We should provide more *general* operations.=C2=A0Users should t= hen combine those operations to their=C2=A0specific needs. > > * We should provide operations that *do more*.=C2=A0Users should identi= fy their most important needs so=C2=A0we can implement them on the blockcha= in layer. > > That's a useful way to frame this kind of problem. I think the answer is,= as it often is, somewhere in between. Generalization future-proofs your sy= stem. But at the same time, the boundary conditions of that generalized fun= ctionality should still be very well understood before being added to Bitco= in. The more general, the harder to understand the boundaries. So imo we sh= ould be implementing the most general opcodes that we are able to reason fu= lly about and come to a consensus on. Following that last constraint might = lead to not choosing very general opcodes. Yes, that latter part is what I am trying to target with `OP_FOLD`. As I point out, given the restrictions I am proposing, `OP_FOLD` (and any b= ounded loop construct with similar restrictions) is implementable in curren= t Bitcoin SCRIPT, so it is not an increase in attack surface. Regards, ZmnSCPxj