summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRusty Russell <rusty@rustcorp.com.au>2023-10-28 15:19:30 +1030
committerbitcoindev <bitcoindev@gnusha.org>2023-10-28 04:50:55 +0000
commit9f11a18367669335d962f56e93c2a9b9431633a4 (patch)
tree4916f32264246fb421531e02a9bcaaeefbeedc05
parentf2fa39e7e613587960f73f2f3835b102293ad1f4 (diff)
downloadpi-bitcoindev-9f11a18367669335d962f56e93c2a9b9431633a4.tar.gz
pi-bitcoindev-9f11a18367669335d962f56e93c2a9b9431633a4.zip
Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
-rw-r--r--c8/ded51cf8a096f4b605311075eeac120fcb1f96190
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.
+