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 C30B9C0032 for ; Fri, 20 Oct 2023 14:26:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A9F6443341 for ; Fri, 20 Oct 2023 14:26:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A9F6443341 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=reardencode.com header.i=@reardencode.com header.a=rsa-sha256 header.s=mail header.b=RJEgqRNh X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.093 X-Spam-Level: X-Spam-Status: No, score=0.093 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 ij2403uEbJfA for ; Fri, 20 Oct 2023 14:26:25 +0000 (UTC) X-Greylist: delayed 404 seconds by postgrey-1.37 at util1.osuosl.org; Fri, 20 Oct 2023 14:26:25 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 01FAA4327D Received: from mail.reardencode.com (unknown [IPv6:2607:f2f8:ad40:ea11::1]) by smtp2.osuosl.org (Postfix) with ESMTPS id 01FAA4327D for ; Fri, 20 Oct 2023 14:26:24 +0000 (UTC) Date: Fri, 20 Oct 2023 07:19:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com; s=mail; t=1697811579; bh=qvqymthnqlURlzQFjbjqMdELyDNZtNpeT0L9fHL+ktA=; h=Date:From:To:Subject:References:In-Reply-To; b=RJEgqRNhe1GGOpge00jrT12mknF/BCr2QR6YHG7OvkSRYsYNv1vFes785XsUBjB1H RPI8H3ZcUGgn/uwkk523fTFJVptw0PUQQVEbFNY8Ra61x1r6xp+v4dxfRIMa0RQWzp RioUI9IrnjPLZL/XMTD3YFlQUcJlInWUI+l3CvQE= From: Brandon Black To: Rusty Russell , Bitcoin Protocol Discussion Message-ID: Mail-Followup-To: Rusty Russell , Bitcoin Protocol Discussion References: <87v8b2vu4q.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v8b2vu4q.fsf@rustcorp.com.au> X-Operating-System: Linux 5.15.110 x86_64 X-Mailman-Approved-At: Fri, 20 Oct 2023 15:11:02 +0000 Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in 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: Fri, 20 Oct 2023 14:26:26 -0000 On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote: > I've done an exploration of what would be required (given > OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the > stack) to usefully validate Taproot outputs in Bitcoin Script. Such > functionality is required for usable vaults, at least. So you're proposing this direction as an alternative to the more constrained OP_UNVAULT that replaces a specific leaf in the taptree in a specific way? I think the benefits of OP_UNVAULT are pretty big vs. a generic construction (e.g. ability to unvault multiple inputs sharing the same scriptPubkey to the same output). > TL;DR: if we have OP_TXHASH/OP_TX, and add OP_MULTISHA256 (or OP_CAT), > OP_KEYADDTWEAK and OP_LESS (or OP_CONDSWAP), and soft-fork weaken the > OP_SUCCESSx rule (or pop-script-from-stack), we can prove a two-leaf > tapscript tree in about 110 bytes of Script. This allows useful > spending constraints based on a template approach. I agree that this is what is needed. I started pondering this in response to some discussion about the benefits of OP_CAT or OP_2SHA256 for BitVM. Personally I'd use OP_TAGGEDCATHASH that pops a tag (empty tag can be special cased to plain sha256) and a number (n) of elements to hash, then tagged-hashes the following 'n' elements from the stack. Best, --Brandon