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 43987C0032 for ; Sat, 28 Oct 2023 04:50:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1D2A740593 for ; Sat, 28 Oct 2023 04:50:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1D2A740593 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=rustcorp.com.au header.i=@rustcorp.com.au header.a=rsa-sha256 header.s=202305 header.b=iB+IED+h X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 kDrFsl-6gj8F for ; Sat, 28 Oct 2023 04:50:53 +0000 (UTC) Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by smtp2.osuosl.org (Postfix) with ESMTPS id E88DA40592 for ; Sat, 28 Oct 2023 04:50:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E88DA40592 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rustcorp.com.au; s=202305; t=1698468644; bh=Lx2h83AVWU+edbFn/fGJS0axyqhojeVPoTKTbvRIGjI=; h=From:To:Subject:In-Reply-To:References:Date:From; b=iB+IED+hDrAw0Owek2yn0vFhkK3tY1X9aSZFL8BkSTEShc1vVcsEd/jIlT9hy0mZ6 57zTA4RdgVZH29DknGMlyayWG3TnqPz51CghewqMJ0E1jQgsrU6Y2jz+ul1i57sT6J KjG4CJe02b+zMWK75NQbLRlt2/SvKLr//PcnJNhzt9HNxsilJVwFShSQtXwvRQTgIR 9HtFvXkhiJBadhtnl6Q0Vp9KnOk7kTaXHzpx/5yl/8sANZT2Lt2BxPcID8YZXqT9Vn Bqhlqb0VITIkgIc/iWy7+9xQaLk6FOxW7XtCw6/GQBA3kbU0hJfVC8Q5WdqX+dhJ5F 1/3TK2GfFxihA== Received: by gandalf.ozlabs.org (Postfix, from userid 1011) id 4SHRtX33J3z4wcj; Sat, 28 Oct 2023 15:50:44 +1100 (AEDT) From: Rusty Russell To: Anthony Towns , Bitcoin Protocol Discussion In-Reply-To: References: Date: Sat, 28 Oct 2023 15:19:30 +1030 Message-ID: <87r0lfz6zp.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain 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: Sat, 28 Oct 2023 04:50:55 -0000 Anthony Towns writes: > On Fri, Oct 20, 2023 at 02:10:37PM +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. >> >> https://rusty.ozlabs.org/2023/10/20/examining-scriptpubkey-in-script.html >> >> (If anyone wants to collaborate to produce a prototype, and debug my >> surely-wrong script examples, please ping me!) >> >> 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 think there's two reasons to think about this approach: > > (a) we want to do vault operations specifically, and this approach is > a good balance between being: > - easy to specify and implement correctly, and > - easy to use correctly. > > (b) we want to make bitcoin more programmable, so that we can do > contracting experiments directly in wallet software, without needing > to justify new soft forks for each experiment, and this approach > provides a good balance amongst: > - opening up a wide range of interesting experiments, > - making it easy to understand the scope/consequences of opening up > those experiments, > - being easy to specify and implement correctly, and > - being easy to use correctly. > > Hopefully that's a fair summary? Obviously what balance is "good" > is always a matter of opinion -- if you consider it hard to do soft > forks, then it's perhaps better to err heavily towards being easy to > specify/implement, rather than easy to use, for example. > > For (a) I'm pretty skeptical about this approach for vault operations > -- it's not terribly easy to specify/implement (needing 5 opcodes, one > of which has a dozen or so flags controlling how it behaves, then also > needs to change the way OP_SUCCESS works), and it seems super complicated > to use. But AFAICT there are multiple perfectly reasonable variants of vaults, too. One would be: 1. master key can do anything 2. OR normal key can send back to vault addr without delay 3. OR normal key can do anything else after a delay. Another would be: 1. normal key can send to P2WPKH(master) 2. OR normal key can send to P2WPKH(normal key) after a delay. > By comparison, while the bip 345 OP_VAULT proposal also proposes 3 new > opcodes (OP_CTV, OP_VAULT, OP_VAULT_RECOVER) [0], those opcodes can be > implemented fairly directly (without requiring different semantics for > OP_SUCCESS, eg) and can be used much more easily [1]. I'm interested in vaults because they're a concrete example I can get my head around. Not because I think they'll be widely used! So I feel that anyone who has the ability to protect two distinct keys, and make two transactions per transfer is not a great candidate for optimization or convenience. > I'm not sure, but I think the "deferred check" setup might also > provide additional functionality beyond what you get from cross-input > introspection; that is, with it, you can allow multiple inputs to safely > contribute funds to common outputs, without someone being able to combine > multiple inputs into a tx where the output amount is less than the sum > of all the contributions. Without that feature, you can mimic it, but > only so long as all the input scripts follow known templates that you > can exactly match. Agreed, I don't think you would implement anything but 1:1 unvaulting in bitcoin script, except as a party trick. > So to me, for the vault use case, the > TXHASH/MULTISHA256/KEYADDTWEAK/LESS/CAT/OP_SUCCESS approach just doesn't > really seem very appealing at all in practical terms: lots of complexity, > hard to use, and doesn't really seem like it works very well even after > you put in tonnes of effort to get it to work at all? Well, I found the vault BIP really hard to understand. I think it wants to be a new address format, not script opcodes. I don't think spelling it out in script is actually that much more complex to use, either. "Use these templates". And modulo consolidation, I think it works as well. > I think in the context of (b), ie enabling experimentation more generally, > it's much more interesting. eg, CAT alone would allow for various > interesting constraints on signatures ("you must sign this tx with the > given R value -- so attempting to double spend, eg via a feebump, will > reveal the corresponding private key"), and adding CSFS would allow you > to include authenticated data in a script, eg market data sourced from > a trusted oracle. Oh, oracles like this are the first CSFS use case I've heard of that doesn't seem like abusing signatures to do hashing; nice! (Seems like there should be a way to do this without CSFS, but I can't see it...) > But even then, it still seems fairly crippled -- script is a very > limited programming language, and it just isn't really very helpful > if you want to do things that are novel. It doesn't allow you to (eg) > loop over the inputs and select just the ones you're interested in, you > need the opcode to do the looping for you, and that has to be hardcoded > as a matter of consensus (eg, Steven Roose's TXHASH [2] proposal allows > you to select the first-n inputs/outputs, but not the last-n). Indeed, but I still think there's much room for improvement before a replacement. It's hard to compare the hobbled script we have today with an alternative, since most interesting cases are impossible. Cheers, Rusty.