From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Oct 2025 04:46:58 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v5jgA-0000fp-5Z for bitcoindev@gnusha.org; Mon, 06 Oct 2025 04:46:58 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-36ff1f6d245sf1387957fac.0 for ; Mon, 06 Oct 2025 04:46:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759751212; cv=pass; d=google.com; s=arc-20240605; b=keZXCoVsDH1tfrBnYXUpmXRWACR8C4bCs61lHwkUt6V1PcNx9N2fZA3SJ8oLPZeQ0K ghoSvaOEPIEFrWsYGF1sUbUD4H7MVkbBos3lT6op5Qcl+lWHTe7At4KbhSHlY4yfL5O8 qxoYE53YQtgqmomGVt8QEZJEKeXMTvl6gssHrrJkbaCLWdnxyC4+HdZSsP6nHKfJMwUd YMrOr0k2AEa4yc6+unNjKoLrf+tGjFI2U65uon/fb8trtiqmiH0LcwuYcAF8iw+XCzS1 1K8FTaxbTfYauDzxM02nz8LsA1lVCXsXKzXIoxkbWeYLOjVvOBuo6AtK4qDNhrpA1TGu nADA== 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=P5jAsQt82/Scdg8thOtjuVaP/gRbBVopoGPJD9lzF4E=; fh=vCohFKxEQdG42wWC6SRgHeWs4A3xqlvmbxFE2uRprVY=; b=Z1q6IjIFOZzw7r3JtUPrDK2yTD8LQgZ6XoER8Cq1s7ha4JbcyW7sViRRYjDJ9Q/0Gn ilQn5pfSEnr34JzVRkWhZ5VXKkGtovVwQ9+hzZvI4djIqd66WpjpbZM/hRvW8f2LoerQ KyCxQpxA+Pejat6fdA83+a/BBwAY1bTe3gqKV8zgYZ5bnNtKZIxfV2qPXEbdCTmIHkux N3juS5GzYt1RClkrwmcmdhkgIq9nQKzUG8nYPg5tAeZZzUNLZxYsx0UIKkw0dpOP4ur2 FEOkILA3OmU5rVvrdNchqKtSGswc4nXIIBaM5puka5gNQzj+emDi4tvr2RgpcWTvMzoM 82hg==; 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=20230601; t=1759751212; x=1760356012; 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=P5jAsQt82/Scdg8thOtjuVaP/gRbBVopoGPJD9lzF4E=; b=HGfTa4FxPd4AZo6882p3l/w6zc2v+TuGRnyIMtugvlwPiRQsizO03bBTcAEzUrHDsR puQqEnMLkI85Wkef2GybQqNMy8VpgUuZ9p2nCpu0oPWWdk+3yIOeIJ1cYw498jdRIvQl TfjwNbry4b1F7Y2cdK6652sDzuZJjiy1uKkK/zaEv7Xm2HapfiP6FePO4G+60KLCCRv7 Ec8xdolLWqgNAts8fFQPjO5Pn+rpgmYVyGK/6iiT5tQDuY0gNFa7isJd67W1S/WTSZ87 5sqnGEnairpiW2ZpubQayXY0XklIYqI85WtSNUjG7QTE27YKGZfp/KsuWxaSaD9Dl0Pl B+yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759751212; x=1760356012; 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=P5jAsQt82/Scdg8thOtjuVaP/gRbBVopoGPJD9lzF4E=; b=E6gWp1XmyoTvI1pcaZTji8RY53yyq9fH7mc4JMqnaJDYsY9uldRVtP6H1d+1gx6rMz 7mjlZ1Crm30iDqE8Pel6mDGngOCo1bPCS+ONgbCczzC7fd3EOz8CkYs1x8HQ6BPfGRgS IHArpeBYGKvgO2A0IF/tAPx/0NPRegCNI559+ueDPCbjYkBLwccW1L3Bc2cw37NF710P LE387ATpjrpyDUDqPe5IyYmSRl3oeKzDY8/YWdZiv9Hth3Ld8+UZeSHugjgjvq//MhnD LHfEBgIDkmx6VR76MQ9opNzPP+0V32I8r3GjMlzQOxL6C6N/8uBK2GlyV0cZAC/c1bzg IV7Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVwQRrvdzgL3CTkg/MsTYnhmVFZRvMYjSI4wdnZii12YL3Fw94igvWdeMpGm3AAg9oYHaJLViwthRSk@gnusha.org X-Gm-Message-State: AOJu0YymXoZ5cc9vOm4CRLfpOMFTzYOxOoqwY2Qr349zZB/3VMNTmpDz PKDmZKgNR0NL0xoyNhLJTk073yu1uEcyjGUpdD8U/4n9EQ4Ce0jkGIT2 X-Google-Smtp-Source: AGHT+IGrVpD/rRo1k3CSogZJmyWfUBZlfNVXcy+nhuew7oKnGG3nlk9IIIJnZv3OvKsmwgUjWkHYOQ== X-Received: by 2002:a05:6870:8883:b0:34b:cc55:9e85 with SMTP id 586e51a60fabf-3b0f4cdab05mr5828423fac.13.1759751211689; Mon, 06 Oct 2025 04:46:51 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd40Y3aJnVKnR6Q0P76vv1Cwa/mKG2lkA2VcExDh+tL/dw==" Received: by 2002:a4a:d411:0:b0:649:c567:1cc4 with SMTP id 006d021491bc7-64dffb40167ls1103948eaf.0.-pod-prod-04-us; Mon, 06 Oct 2025 04:46:47 -0700 (PDT) X-Received: by 2002:a05:6808:384d:b0:43f:2c69:476b with SMTP id 5614622812f47-43fc1861aafmr5559753b6e.40.1759751207202; Mon, 06 Oct 2025 04:46:47 -0700 (PDT) Received: by 2002:a05:620a:88d:b0:80d:5a8b:a44e with SMTP id af79cd13be357-87a0e521f4cms85a; Mon, 6 Oct 2025 04:41:52 -0700 (PDT) X-Received: by 2002:a05:620a:4610:b0:851:b083:3803 with SMTP id af79cd13be357-87a3677deeemr1591848985a.12.1759750911728; Mon, 06 Oct 2025 04:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759750911; cv=none; d=google.com; s=arc-20240605; b=PxNpa7C0uzxTTHvugYATcjjUbjLCLzpYUD/h5FVLyzS3S/b4ex+HH7fA6XMOzbDiSo VKNgXJH4UuY5KyAoSQsAy1ZGMhgZOotyQXRw/FaWzAxjNCjlTHu3XwiaHRXRwUfSkg1Z ieiYRM2en2GdIHLhcSsyw9sPNu/szBL3p9t7Is4pFsWWfe9f11qjYStIFH0VT1HJXroO 1chD30pdKGYy+62jCh2pogd0n/QP1XClTJb7ReRnmUIczxGLeAWNH8cV6SWJJPBFqZHq 6g+gTcwn5utu7eOeAH7PMUZw1+HcQzeKxpnOeFhomd9EEzf2H9Vd7G2dJDf6V2pLox5T WPQg== 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=Ze8SSLbSi8u9bm/RyKtNN60Do7sxRg3U867okJPQrKY=; fh=2Au7Q+0ofqLEIjZkA5VQCV+WqgBtcq+FeF2FoHbGrJU=; b=B3DL3hDkHnHoBF5ecd3bPRDCTp5yzrc71nqr9XyfdVnHzCXNQajTTmZzJVQN+1vaSY wNSBL5daWXM8BsGMCOWcV2+K6DrB+Cdu4NmaZZaaZLeX/MkU01cjBlgvy+SEgsWLeF4v 4Mf5dGV2SOIR0WYlUoYntqmxEeYMD8T8kfepVv1tMmksCdpzhy3J2Pfp1v30mwLm1GX8 uLhJyY90VtWApYEaKPen3doW/u8nW6LQCyFnNkjWAikrFkcH/YVKfxLRStoitG00TDdL T171gCkZeWT8epgOLL+7J4uljeYEmEQcs+O1nlKCJLLlDj2cwgfg3VnGevAsqp37eMEd xTQg==; 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 af79cd13be357-87776d60b7fsi58602085a.5.2025.10.06.04.41.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Oct 2025 04:41:51 -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 1v5jax-0007kU-2Z; Mon, 06 Oct 2025 21:41:49 +1000 Received: by email (sSMTP sendmail emulation); Mon, 06 Oct 2025 21:41:44 +1000 Date: Mon, 6 Oct 2025 21:41:44 +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> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <87y0q0m8vz.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 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"... > - 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 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") The benefit of this is that you could then turn a relative timelock into an absolute one via script. The idea is that this is useful for eltoo approaches where you may wish to publish a finalisation state to the blockchain, but may need to update that state to the most recent one. In an adversarial scenario that can double the delay -- they abort the off-chain protocol in the middle of updating from state n to n+1, so that they can complete state n+1 but you can't; publish state n to the blockchain (or allow you to do so), wait x blocks, then publish state n+1, and force you to wait another x blocks. With the ability to update script code (ie, part 4 of this series of bips), and a "parent height" query, we could programmatically allow replacing a script's requirement of "X CSV" with a requirement of "[H+X] CLTV", and instead of requring the n+1 state update to preserve "X CSV", require it to preserve "[H+X] CLTV" instead. In that case, if you wait X blocks to publish state n+1, it doesn't cause any additional delay. (To be explicit: the idea here is that if state finalisation is time sensitive to you, you pay for an on-chain transaction replacing the relative timelock with an absolute timelock, so that if your counterparties later update the state in other ways, the finalisation doesn't get delayed further no matter what they do) cf https://delvingbitcoin.org/t/contract-level-relative-timelocks-or-lets-talk-about-ancestry-proofs-and-singletons/1353 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? Cheers, aj -- 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/aOOq-Pw0ht_R0OAK%40erisian.com.au.