From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 26 Mar 2026 07:21:37 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w5laa-0005Z5-Ow for bitcoindev@gnusha.org; Thu, 26 Mar 2026 07:21:37 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-41c471678c4sf1090334fac.2 for ; Thu, 26 Mar 2026 07:21:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1774534891; cv=pass; d=google.com; s=arc-20240605; b=NURwQRemmXclaVPCGKSB/Daxkn2m8QW8U1HJ/Xwvyp3ZG0vrLBsAj6RCDsP+U6ldTd TQVZBsCpbVxhg9waHn/lzivEZT/Ahg9rC8rRPdCld/0zLJKgiwm3BtTZzNDTqydhAJNR Pz7wAP9jdAMmDMRP01lxMXjybSRwemjKlZ5EN0gBWXcmhbdlhfY7zVkf6nnk8q/J/SCX ZEpLNxMyAVv/j1RdU0Kp5fq2u7IcPJjVZ3NmuaOOf6RjlX/pUbhQ7EoyjYea4xOT1Shi gIQ5wQLBuSJp0Xy7rEgS5qTrQlf93IHDfS3uccTFiTTlogpIXyZyBfiZyVBK+xhaCRwy ayyg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=zdT8yAho/wNyoUBS9zgn+MBQgMkDYwOD9n3nPsSHye0=; fh=d1FkANDZR/4g3SCmTZkTJSMqErrbi6eGuDMDMFKVZNY=; b=lP8ZaFp/A/3DEoaJ5rJMD43MAqp9H1wpbLcJkDxBafU3XZfpSXWC3NaRnAjxlIhnNT NYXgKSZU7cyLqGfOadS5LduX3TKEO/0takmoRLnyECVN1dUgtRCkBzRWJi58Ji14NgqZ 31Er+5J+TTVS7/Fvxf+xFM4MAqX5+xQAHEZ6JFye5tB0Cc7H0gupemPvJqJoUUMESJiQ QDAb3GYadlqC+Kq6K/dc1/lnswinaZbZTuUJhhJSBZ2mIRGvICluLgqKZ6R/80/Fa3VR 90xpEQmNtrWbW4HOwlPhmW6CLt79TZEzHNJz7LyhzZT3IW6JPPX4lZlBbjgBa7GCC/qp mVng==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774534891; x=1775139691; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to; bh=zdT8yAho/wNyoUBS9zgn+MBQgMkDYwOD9n3nPsSHye0=; b=ZtAbLoPaCiP18mkNrCdAZPqhvo8+t0deYWvMGbY1AhasAkO7UE/5RWwsfHvYZrfZQx iNzWn+bjLwZr5bJF334KtnPeGh+xA3hvsUmnaQ6KPkTfzHjQySWnfxlSAe8dgyT1SesQ LtuXao87FFJXYk1hDYcZlx6q4wAHwfZafpsa3tli7GW6qW5yjbQuiAeqjb1copuEGNo7 sDArBhVZM8dyO/OW1JKL6qvOuTibtfQGYiwddB4thaUMCuIZC3vy3OpTAS5UkjMt3Gfk 1ANDxHd2T5h6qQxjkgjtYfSmkxOcNgfOAt7ou2sHW/Nk2X9e4hLFDvlgO9ynAd6Ecmx0 sGcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774534891; x=1775139691; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=zdT8yAho/wNyoUBS9zgn+MBQgMkDYwOD9n3nPsSHye0=; b=OaCN/L01AWxc8kuSHoAtA77zM6Dpj0iYt/Ao4hiP1FgXso2eyQ1VpPWPfk0Wo3cpZp 9EudsMnGqtT2M+4uuGfy2tVIHt1olBf7jKELr+2HUzoUrh3k778+A0Rj6Yl/GpxmgvdG zrQY32XsEL/E30AOO6eWFB/vedtkJzt1aZEAsOTbgEvPYpz+/zc9jVFK5+A307VJIDDT C0Dx2xe5Q2PTg6RPWWndlHxmH1rDU1tmBT+BvvAfiiYLIh52k6QZ59G0QeqkmrbUHFUt lU2GO00x28+nNOJkgDGT9nWBBLMyfgzXq+pD/E6J5+S6VaVNCjA8R/XsXz+Qqu0gv6Ie dksQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU5CAN+PUUwPp9AGe/LBaJwho9+5+c9U3u6ocgk5rJZV0yrlf3pQ1GVbIAX1r5BleY8X9r5ZliP5dIl@gnusha.org X-Gm-Message-State: AOJu0YwWntg461hqakPpC6Hxsp/V27Hs6W4hUBgMk/Afv/pn9rKRIc4/ G0WYQ8QI13h8gEOrFIm7YkrAPv4qYtulSJbwl2ez8NpVP0UHZueXVNhq X-Received: by 2002:a05:6820:2225:b0:67b:bd89:90ed with SMTP id 006d021491bc7-67dff59d945mr3605336eaf.41.1774534890547; Thu, 26 Mar 2026 07:21:30 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLsOeXcycndAbD4AOgHCvO3l5cYu53WnaPFSkuBc5YDHA==" Received: by 2002:a05:6820:2293:b0:67b:f5b9:99d8 with SMTP id 006d021491bc7-67e0ce837e4ls320124eaf.0.-pod-prod-02-us; Thu, 26 Mar 2026 07:21:25 -0700 (PDT) X-Received: by 2002:a05:6808:16ac:b0:450:5e3a:6f20 with SMTP id 5614622812f47-46a5c59d426mr3318459b6e.10.1774534885444; Thu, 26 Mar 2026 07:21:25 -0700 (PDT) Received: by 2002:a05:690c:6283:b0:79a:37dc:255a with SMTP id 00721157ae682-79ad136a5cams7b3; Thu, 26 Mar 2026 01:30:48 -0700 (PDT) X-Received: by 2002:a05:6122:614f:b0:56c:ca03:b668 with SMTP id 71dfb90a1353d-56d21f3d2bcmr3548305e0c.3.1774513847534; Thu, 26 Mar 2026 01:30:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774513847; cv=none; d=google.com; s=arc-20240605; b=GmJ+JI6fWnuTf/zs4+XjXYn9e/qUBN9bo1oS1oSLYjO+ZucT8mQXFXs596K2ZTc/uQ Cbry4zvg2QxQ5xA0mDGYSj7fPXRLwexjgDYnxl+vaL1Vi6XnWQj9KyBsCPCojIU/Z5Im u7D/gXCybVZVhiuyQFkNxVJBxA2U6F0qv86wUcMiN6FFrJdHR2mqCOCu3yfY+ma9UUwS 2jx4b6pnjfUATKXO0hu6oT0Djba2H9rOGoaCWXiLBEy6OZz3XCZbLzAx12KjB7DF5lsv hsHAmoTTL8LmQ6Q7Da7I16+dWwsox8ufKEOfHXkdPHcVdwTDMeKxI9RQNO3twQORd5Bg VfNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date; bh=j6NhK7rMATCJvWYtbuiLA3nzafBzg9CPZP4eOz6iNIA=; fh=mEs4JlV7p5TG28Lzqtb7nzrDQPY8ywiWRhTScgf2jeE=; b=OeQeeLyCtApsWgZP4wkJ0uJyISWR4FK/4qUIp1roMjRk76l8cpucpYTykXbsTVcsjr 0SWM5r36j9BRinll2/KIpfi3rnz445pzEL+v7ZCJkIhkCZdZMxp11PtYmRZ591SLNNZW NxAJdoeB6SiWgqGTlRXW8y2zFDIBKyBbO8l3j/xubwW2ps/fmja4j5k/iuxzDbVFR3LJ tkaQlGaN4+dq2Ca1lwxuzaDcP+Rur4gShDYz0+DNTH8nRJI/fEiOXX/p6xU0phjDG/UD RK/zNHe3Q7PpD/8HSWQKogJIYuOsmChoG+ALIzGOZ6UItVoQrcsV8N7qwWcEqYZdBCzY Q8tg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-56d31d58838si70713e0c.5.2026.03.26.01.30.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 01:30:47 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5g6m-0003LF-1Q; Thu, 26 Mar 2026 18:30:44 +1000 Received: by email (sSMTP sendmail emulation); Thu, 26 Mar 2026 18:30:39 +1000 Date: Thu, 26 Mar 2026 18:30:39 +1000 From: Anthony Towns To: Rusty Russell Cc: bitcoindev@googlegroups.com, Julian Moik Subject: Re: [bitcoindev] [3/4] OP_TX Message-ID: References: <871pnsnnhh.fsf@rustcorp.com.au> <87y0q0m8vz.fsf@rustcorp.com.au> <871phxaaac.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <871phxaaac.fsf@rustcorp.com.au> X-Spam_score: 0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On Fri, Mar 06, 2026 at 02:17:55PM +1030, Rusty Russell wrote: > Hi Aj, > Sorry for the world's worst email latency, but I *am* replying! This doesn't seem to have made it to the list? Original left quoted below, in case this email makes it to the list. On Fri, Mar 06, 2026 at 02:17:55PM +1030, Rusty Russell wrote: > Anthony Towns writes: > > On Sat, Sep 27, 2025 at 08:59:04PM +0930, Rusty Russell wrote: > > I think it would be good to also have a selector: > > > > TXSELECT_INPUT_OUTPOINT_HEIGHT > > > > which pushes the height of the block at which the coin being spent > > was confirmed. (In order to make that not terrible wrt reorgs, it > > should also imply somewhere between "6 CHECKSEQUENCEVERIFY" and "100 > > CHECKSEQUENCEVERIFY") > > That is a big implementation lift, adding a requirement to reevaluate > on reorgs which I don't think existed before? Having a requirement of a relative locktime of L=6 or 100 prevents needing to re-evaluate it -- if the UTXO was at height H, and you're currently at height H+L+K, then by the time you reorg back to H+L the spend is no longer final and is removed from the mempool [0], so if you continue reorging back to H-1 and then back up to H+L+K+1, you're re-evaluating the entire transaction from scratch. [0] In Bitcoin Core, this happens via the `filter_final_and_mature` function which is passed to `removeForReorg`, and checks `CheckFinalTxAtTip` (for locktime), `CheckSequenceLocksAtTip` (for relative locks) and checks maturity manually. Because it can can cause previously valid spends to be invalid (rather than just requiring a different ordering or later confirmation) after a reorg, I think it's reasonable to apply a comparable sequence delay to coinbase maturity, hence the 6-100 figure. > It also creates the ability to have a kind of "fail after a certain > height" transaction: your output scriptPubkey maps to a script which > always fails if the blockheight of this tx is greater than some number. It means that some of a UTXO's spend-paths can be observed to be invalid at the time the UTXO is confirmed. That's a similar property to what you get with signatures that can be rebound to different transactions -- you might think that the stateN eltoo signature you have is good, but then stateN+1 ends up confirmed, and it's not anymore. It's obviously something you can simulate with multiple transactions: you also can't spend an output that someone else has already spent. So provided it's simple to handle efficiently in the mempool, I think it's worth considering. I think the "timeout is N blocks after commitment tx is published" rather than "timeout is N blocks after the most recent response to the commitment tx being published" is an important thing to be able to be able to express, and so far this is my best idea for how to do that. > I'd rather have a serious discussion on tx expiry, if we head in this > direction. I think tx expiry is largely a bad idea personally; it makes the most sense for time-sensitive auction-like things which on-chain confirmations are terrible at, it's more dangerous/confusing for recipients ("i checked in mempool.space and the payment was on it's way, now it's gone and i can't resubmit it??"), and I don't think it makes for that much of an improvement for the things that it can enable (the HTLC expired, now you can wait indefinitely to claim it, rather than needing to do so immediately in case the other guy somehow gets the secret). I don't think it can solve the "preserve-the-timeout-across-state-updates" problem above. I do think it could be implementable though; if a tx has an easy way to indicate when it expires (specify the value N in the annex for input spending utxo K, and your tx becomes invalid N blocks after K was confirmed?), then when adding to the mempool you calculate max(K.height + N) across each input, and add those values to your mempool index, evicting txs as appropriate when your tip increases, and with a similar relative timelock behaviour to also evict the tx from the mempool if you reorg back close to K.height. I think the TXSELECT_INPUT_OUTPOINT_HEIGHT is both easier to implement (no additional index needed) and more powerful than simple tx expiry though. Cheers, aj On Fri, Mar 06, 2026 at 02:17:55PM +1030, Rusty Russell wrote: > Anthony Towns writes: > > On Sat, Sep 27, 2025 at 08:59:04PM +0930, Rusty Russell wrote: > >> ==OP_TX== > >> > >> OP_TX operates as follows: > >> > >> Examine bits in ''selection_vector'': > >> - For each existing input ''i'' in the range ''first_input'' to ''first_input'' + ''num_inputs'': > >> - If TXSELECT_INPUT_OUTPOINT_HASH is set: > >> - output input ''i''s outpoint hash (32 bytes) > >> - If TXSELECT_INPUT_OUTPOINT_INDEX is set: > >> - output input ''i''s outpoint index (32 bits) > > > >> - If TXSELECT_INPUT_SCRIPT is set: > >> - output input ''i''s script as a variable size object > > > > I think you should be clearer which "script" this is; it could be > > the scriptPubKey (except you have a different selector for that), the > > redeemScript from the scriptSig (except we haven't defined taproot outputs > > for non-empty scriptSigs), or what this presumably is, ie the tapscript > > v2 script from the witness. We have too many things called "script"... > > It is kind of a hand wave, isn't it? We probably *want* to ask "the > script which will be evaluated for the given input". That's the > witnessScript for segwit, the scriptsig for pre-segwit, tapscript for > taproot. > > Ofc this is not defined for future output types (e.g. BIP 360). But I'm > unsure if should fail for those, return empty, or use the second final > witness script and hope that convention survives into the future... > > You can already examine the witness directly, but that's less convenient. > > >> - If TXSELECT_INPUT_AMOUNT is set: > >> - output input ''i''s input amount (64 bits) > >> - If TXSELECT_INPUT_SCRIPTPUBKEY is set: > >> - output input ''i''s scriptPubkey as a variable size object > > > > Shouldn't these be named TXSELECT_INPUT_OUTPOINT_{AMOUNT,SCRIPTPUBKEY} > > (or COIN or UTXO in place of OUTPOINT) since they are obtained from > > outpoint being spent, rather than directly from the input? > > I like adding UTXO here. > > > I think it would be good to also have a selector: > > > > TXSELECT_INPUT_OUTPOINT_HEIGHT > > > > which pushes the height of the block at which the coin being spent > > was confirmed. (In order to make that not terrible wrt reorgs, it > > should also imply somewhere between "6 CHECKSEQUENCEVERIFY" and "100 > > CHECKSEQUENCEVERIFY") > > That is a big implementation lift, adding a requirement to reevaluate > on reorgs which I don't think existed before? > > It also creates the ability to have a kind of "fail after a certain > height" transaction: your output scriptPubkey maps to a script which > always fails if the blockheight of this tx is greater than some number. > > I'd rather have a serious discussion on tx expiry, if we head in this > direction. > > > Providing TXSELECT_INPUT_OUTPOINT_WAS_COINBASE for completeness might > > be worth considering. That could perhaps be useful for allowing things > > like drivechains that give miners influence over coin movements to be > > redesigned to not require additional consensus support? > > Generalizing these gives allows a lightning-style short-channel-id-style location: > BLOCKNUM-TXNUM-OUTNUM. > > But I think this is a good reason to allow extension, which is why the > proposal succeeds for unknown bits... > > Thanks! > Rusty. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/acTurxiSsJCCY2gk%40erisian.com.au.