diff options
author | Rusty Russell <rusty@rustcorp.com.au> | 2023-10-28 15:19:30 +1030 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2023-10-28 04:50:55 +0000 |
commit | 9f11a18367669335d962f56e93c2a9b9431633a4 (patch) | |
tree | 4916f32264246fb421531e02a9bcaaeefbeedc05 | |
parent | f2fa39e7e613587960f73f2f3835b102293ad1f4 (diff) | |
download | pi-bitcoindev-9f11a18367669335d962f56e93c2a9b9431633a4.tar.gz pi-bitcoindev-9f11a18367669335d962f56e93c2a9b9431633a4.zip |
Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
-rw-r--r-- | c8/ded51cf8a096f4b605311075eeac120fcb1f96 | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/c8/ded51cf8a096f4b605311075eeac120fcb1f96 b/c8/ded51cf8a096f4b605311075eeac120fcb1f96 new file mode 100644 index 000000000..e3b1c8cd1 --- /dev/null +++ b/c8/ded51cf8a096f4b605311075eeac120fcb1f96 @@ -0,0 +1,190 @@ +Return-Path: <rusty@gandalf.ozlabs.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 43987C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <rusty@rustcorp.com.au> +To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion + <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <ZTtgFPG4tTeZMnYn@erisian.com.au> +References: <ZTtgFPG4tTeZMnYn@erisian.com.au> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sat, 28 Oct 2023 04:50:55 -0000 + +Anthony Towns <aj@erisian.com.au> 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. + |