From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 86A20C000B for ; Wed, 16 Mar 2022 15:59:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 756AA611ED for ; Wed, 16 Mar 2022 15:59:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvPxZohaK7uL for ; Wed, 16 Mar 2022 15:59:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by smtp3.osuosl.org (Postfix) with ESMTPS id 7E73C611E5 for ; Wed, 16 Mar 2022 15:59:19 +0000 (UTC) Received: by mail-ej1-x62b.google.com with SMTP id qt6so5107133ejb.11 for ; Wed, 16 Mar 2022 08:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DokksuRk8WVvzpZxZt0n5+qaqzEMK2NbdrCrCpJm2Yo=; b=G8v905iv7+ZN0zXpDQrO9Mx4LVma5YYw3U8yv0vL3L3LcA1ErqNFHAYBlSYbyFQAAS tTZAbtIOyt6FZB+c/gYChln5uGewOomzVyNPIDvG2niZqOfyyJ9gygEx5Tw7elQvH0LB 3zMg++C+0JauAcJ6JdsKjpl+3E2Kx0xPEB39nvXJXy1VgL0Avo57CKkbwEv3W/wjQ+fl xWNlKIO6ksw82s81+wk9DXpFaHVPT+LNhHcpe2ClDyBCNY+CrR1XEd2D99FcpoIrzq5u FtkNqkXMWydK5W/5rTYr5MdCSllPhv/1A4Vk373413joGaeKKR9Uxh8KbVjzFuEqCD/V HObA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DokksuRk8WVvzpZxZt0n5+qaqzEMK2NbdrCrCpJm2Yo=; b=oUU8lS/N5Mp1r3vh5YJ+eeF27eg8+sLDMAFLTPwm3QzopSr0o7zKwFDAlZlLXLsT+4 zf2MLyCBMf7CV2ZHUUrufberEbvlJCe1McEl+zXeZGIIR3QhVCu28nPhKw2w4SaJjgKe FWjSlYiC+VmqBfYG5lDBbBDVVncHxg5vTTBwTwvimPfyL4j4g3iW5AKPCk8uS6FYBkdO esrIP3onfeMyfp21+2c+UZgHK1XB3aYpF7vx9x3tbdoTE6sg3b5wWFhahczfE3gkTTIz Wa3iTw3BtS55GSPRnkTomS2rnvit49x1gVJdcOqccMu3gMLkh3cVLIAReL0uGxrU/Sz3 1ltA== X-Gm-Message-State: AOAM53187EroLmCZWXgOcj4Q3S0+AJRkeVl9t5mdpqmR1IKbgXFrlTxk GZ1m3LuTk3OykHMDWcqurlnkNmk0Wt4wwK6K0vHVZOofMig= X-Google-Smtp-Source: ABdhPJwfn6bgHlHF7i4XXHJ2IwGUY1sX0u2M599kYuRQB7wvQpK2zPASV/IQQqwClPWtQHpj+ztpZhyN+NlzxO0AJvQ= X-Received: by 2002:a17:906:4fc7:b0:6da:92b2:f572 with SMTP id i7-20020a1709064fc700b006da92b2f572mr581175ejw.184.1647446357353; Wed, 16 Mar 2022 08:59:17 -0700 (PDT) MIME-Version: 1.0 References: <8R8D_XAaz7xYHmgWXR-pc3_GVFRzBCNdRT6s3PdKblrnnZPirB0orzLpEUvynBZHNBTiqOM_EteDdUjdqXQ5ZmrGbdlgnnfjIihgFZIXpUM=@protonmail.com> In-Reply-To: From: Billy Tetrud Date: Wed, 16 Mar 2022 10:59:00 -0500 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000eaaba805da57fe38" X-Mailman-Approved-At: Wed, 16 Mar 2022 16:04:24 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Jets (Was: `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: Wed, 16 Mar 2022 15:59:20 -0000 --000000000000eaaba805da57fe38 Content-Type: text/plain; charset="UTF-8" > The constants table would be part of the SCRIPT puzzle Ah I see what you're saying now. You're not talking about referencing inputs from the spender, but rather constants for the script writer to parameterize a jet with. TBH I think both would be useful, and both could potentially be done in the same way (ie reference their position in the script before any evaluation starts). I think your idea is a good one. Cheers On Wed, Mar 16, 2022 at 10:39 AM ZmnSCPxj wrote: > Good morning Billy, > > > > I think we would want to have a cleanstack rule at some point > > > > Ah is this a rule where a script shouldn't validate if more than just a > true is left on the stack? I can see how that would prevent the > non-soft-fork version of what I'm proposing. > > Yes. > There was also an even stronger cleanstack rule where the stack and alt > stack are totally empty. > This is because a SCRIPT really just returns "valid" or "invalid", and > `OP_VERIFY` can be trivially appended to a SCRIPT that leaves a single > stack item to convert to a SCRIPT that leaves no stack items and retains > the same behavior. > > > > > > How large is the critical mass needed? > > > > Well it seems we've agreed that were we going to do this, we would want > to at least do a soft-fork to make known jet scripts lighter weight (and > unknown jet scripts not-heavier) than their non-jet counterparts. So given > a situation where this soft fork happens, and someone wants to implement a > new jet, how much critical mass would be needed for the network to get some > benefit from the jet? Well, the absolute minimum for some benefit to happen > is that two nodes that support that jet are connected. In such a case, one > node can send that jet scripted transaction along without sending the data > of what the jet stands for. The jet itself is pretty small, like 2 or so > bytes. So that does impose a small additional cost on nodes that don't > support a jet. For 100,000 nodes, that means 200,000 bytes of transmission > would need to be saved for a jet to break even. So if the jet stands for a > 22 byte script, it would break even when 10% of the network supported it. > If the jet stood for a 102 byte script, it would break even when 2% of the > network supported it. So how much critical mass is necessary for it to be > worth it depends on what the script is. > > The math seems reasonable. > > > > The question I have is: where would the constants table come from? Would > it reference the original positions of items on the witness stack? > > The constants table would be part of the SCRIPT puzzle, and thus not in > the witness solution. > I imagine the SCRIPT would be divided into two parts: (1) a table of > constants and (2) the actual opcodes to execute. > > > Regards, > ZmnSCPxj > --000000000000eaaba805da57fe38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 The constants table would be part of the SCRIPT puzzle

A= h I see what you're saying now. You're not talking about referencin= g inputs from the spender, but rather constants for the script writer to pa= rameterize a jet with. TBH I think both would be useful, and both could pot= entially be done in the same way (ie reference=C2=A0their position in the s= cript before any evaluation starts). I think your idea is a good one.=C2=A0=

Cheers

=
On Wed, Mar 16, 2022 at 10:39 AM ZmnS= CPxj <ZmnSCPxj@protonmail.com= > wrote:
= Good morning Billy,

> > I think we would want to have a cleanstack rule at some point
>
> Ah is this a rule where a script shouldn't validate if more than j= ust a true is left on the stack? I can see how that would prevent the non-s= oft-fork version of what I'm proposing.=C2=A0

Yes.
There was also an even stronger cleanstack rule where the stack and alt sta= ck are totally empty.
This is because a SCRIPT really just returns "valid" or "inv= alid", and `OP_VERIFY` can be trivially appended to a SCRIPT that leav= es a single stack item to convert to a SCRIPT that leaves no stack items an= d retains the same behavior.

>
> > How large is the critical mass needed?
>
> Well it seems we've agreed that were we going to do this, we would= want to at least do a soft-fork to make known jet scripts lighter weight (= and unknown jet scripts not-heavier) than their=C2=A0non-jet counterparts. = So given a situation where this soft fork happens, and someone wants to imp= lement a new jet, how much critical mass would be needed for the network to= get some benefit from the jet? Well, the absolute minimum for some benefit= to happen is that two nodes that support that jet are connected. In such a= case, one node can send that jet scripted transaction along without sendin= g the data of what the jet stands for. The jet itself is pretty small, like= 2 or so bytes. So that does impose a small additional cost on nodes that d= on't support a jet. For 100,000 nodes, that means 200,000 bytes of tran= smission would need to be saved for a jet to break even. So if the jet stan= ds for a 22 byte script, it would break even when 10% of the network suppor= ted it. If the jet stood for a 102 byte script, it would break even when 2%= of the network supported it. So how much critical mass is necessary for it= to be worth it depends on what the script is.=C2=A0

The math seems reasonable.


> The question I have is: where would the constants table come from? Wou= ld it reference the original positions of items on the witness stack?=C2=A0=

The constants table would be part of the SCRIPT puzzle, and thus not in the= witness solution.
I imagine the SCRIPT would be divided into two parts: (1) a table of consta= nts and (2) the actual opcodes to execute.


Regards,
ZmnSCPxj
--000000000000eaaba805da57fe38--