From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Feb 2026 01:11:51 -0800 Received: from mail-oo1-f60.google.com ([209.85.161.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 1vpjmh-0002Qo-3m for bitcoindev@gnusha.org; Tue, 10 Feb 2026 01:11:51 -0800 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-6630d58662asf3054664eaf.0 for ; Tue, 10 Feb 2026 01:11:50 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770714705; cv=pass; d=google.com; s=arc-20240605; b=CdLcJrHlL7UipMEV+8YWBTPdo3IXnorT0onlLQ3l/KWPTBj30t3WqwfrtZo7q+OlK/ BYPR4a8PNSM5sWVS4AEPQZVgj+RcIuZGtBSF6EJbyxyPgOPi9xXIr3f88tO8KaCyMdE6 +6FdSfTudSvuwtpfSqGY9yPYgWDrK5mKXUY9NzGBKWJHaUYiimzbSN2faCvfxCXQ0YxL f5+STNHfQh9s3kmRgqy29qQvZa9oHJzOXPiEaqQWMVKkWs+KYHH8VwLHBUKznpqVlc6/ BHstAskGmD3Vh5qSWS27bIiNr3gOYfg+c8zyWyr2xnnUiSRpCvmXMxrjY3CuWtul+205 bfvw== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=bvEPozlRZA50SXkicSC9b02B6jxoBmWlwTlEQ0RzEvE=; fh=kf/8Pbx1L2mL6Ful3fGK2d++ryFwpXmmVZ1LbbWjVOE=; b=a14vkNSfhxNORpCdKfYjD83FWO0n7WxySndkTtoOIBefTsE75ZcUWWViI3DhCCn2SM hNxE56kUMEWOe6PIZXKS6PWgbjDrXzE2qdbFWad3/zYrLkLMSFb6JpNUZn3bs9TSFtza n3XbLLpXzoRBcViwoo9pEKF3K0RzrBvXRcLKxMkja3Jbe1vG0Cyg5ZUT0wgfDhD54Yun Metfok0zmI8AmSLHnqXFe7XWsopja9487V75FHx/a/ZHUQfpXZ3ilwq4k4IEfTQU8wC/ JmWhdMLIr0GDxcZLoWAI0huMHTP/RzUvAG433V3N+oSR4d5aD+8AILUr42GxX/RyVRUE ksqw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UDS3kVH7; arc=pass (i=1); spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770714705; x=1771319505; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=bvEPozlRZA50SXkicSC9b02B6jxoBmWlwTlEQ0RzEvE=; b=xaMgQzkTuOzOPpck9Hl1D23wmut4E9vhzN8MprF9reBcs+5/o/55pl/MO3JjQAWv3r hHDHJ4VMwDgNYudIk0GHZVtIxqQeUdJKV/9PIZz/ih/oztnC6D6Se1QL/ViASg/deXK+ auZmdph4BqgGrT9NMHavYmvxVCsFyPR1elp1eHR4iZ5fHX5P8yEiceM8knAh655iB1af y6+yQWrhFTc6pm/1xX5RH3evlvo7UWYapV05q8o/Lc273ckKsPInuwKURe2FvVXvTyxr E4dIfoEBwClQKXJctLlA176xog943KwaGdIeYmEwM6lmzDfA6Uk+rzgU/FVNuLBCXEe1 tF7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770714705; x=1771319505; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bvEPozlRZA50SXkicSC9b02B6jxoBmWlwTlEQ0RzEvE=; b=KXF5ZpPp+40NXVvMz4oS9lY1djvMWoxVvYmSsRrYW9KkU23KRiNssQ+cqebbrsUcD7 +uiC6WqG82if7ASZpTlxVCM1Q37aBfDR8t3n+QLDCacpJc0XYgRDOMMZiuoY2YHB4C2v 8+PM2d+iNi+zamtl/nWO28h59gGrU4iu9GpvBRDIdhIP8awxynrflnlByisSWFXjuBn8 bRn9TwGr+FEjn4x6FkrNMMqRb798hxZVKe+1JJUHfV/L1tSFxK9/n2hfdl0W9TaE/Ylx NHne858EUs4DYiDPfhDxfMslgzJBAtFy30SGnEYQQJLGBz2S9xiWoV0z/9nkIU/RuY9B noRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770714705; x=1771319505; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=bvEPozlRZA50SXkicSC9b02B6jxoBmWlwTlEQ0RzEvE=; b=UR1GLNnmLvh+QqUyi8XS+jMpkWsDhq5pf7L6VgzY+1UitNB/nDpE8rDZNMpFL36zKS 53455yGO52egySqN82YT6Ll9hW4krWQRgiMQENvjutGj1Tk1TN796UsR8vXvNnBQejVA pNRqWepypbkFIazpBnK4v1u0LbhXxZAjWrCBEg2a24Mwlv06SX4lWLxD6TQ3z8pMI+bx 2S2By6pWYpiNwWnaVWd9XTsaE0o7s/cqlDiwpEWS9yLXpBBhb7/OgByxcishYAWSo300 2a5peobA/FYg9lzYIpx0xpcJhqeOZRxbI2HHWxEHbnviV7VAmuAN+k1DS8WisajqLy/W Ln4A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUjgy+HMSWxzBDYN4upDkEydkCTAn9J/PNzQJLqOGFtuF8MbHlkf0FYGMGBNFBnbABJo9pode9GDAOR@gnusha.org X-Gm-Message-State: AOJu0Yzfd66vh+LrwNsfaqm5hHhDcIGdBfNYPe2HL8j/JjYDlgrPJ3md 0zkS7XdEscjwrgmCSYlHtAzuD37j8WIJtkUz33dESAdz1EQRGPmOYUCK X-Received: by 2002:a4a:e9e5:0:b0:66e:bf20:28f2 with SMTP id 006d021491bc7-66ebf202b7emr3267829eaf.15.1770714705084; Tue, 10 Feb 2026 01:11:45 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+G5T6002LhsIXdMRMrQ2fqfy/wWWI/9xeNwyt8VwOQuRA==" Received: by 2002:a05:6820:821:b0:66a:18b5:e23e with SMTP id 006d021491bc7-67286b77a6als748422eaf.1.-pod-prod-09-us; Tue, 10 Feb 2026 01:11:33 -0800 (PST) X-Received: by 2002:a05:6808:238e:b0:462:b520:273a with SMTP id 5614622812f47-462fca26889mr7284716b6e.25.1770714693427; Tue, 10 Feb 2026 01:11:33 -0800 (PST) Received: by 2002:a05:6808:31c8:b0:45f:66d:3206 with SMTP id 5614622812f47-462fc4f847bmsb6e; Mon, 9 Feb 2026 21:13:08 -0800 (PST) X-Received: by 2002:a17:903:2449:b0:2a9:5f11:3a34 with SMTP id d9443c01a7336-2a95f113cafmr105811585ad.13.1770700387019; Mon, 09 Feb 2026 21:13:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770700387; cv=pass; d=google.com; s=arc-20240605; b=DmMBFcA1CnRJEBzR5QJA/xnD/0q+BvTpZvvoVRrbfG8uE49ZCm8P/4sLkq2CuQoJHj vWJtKLOE5B0RIfJ1n/NvHP+Kmu52xlbKibxVrpR5O0UqZIKdecsExr3KFbIZR8r720MJ Et0O0pq0Y/6IkYh7fyVgFZVlij6bPKZeRlfnuVWzuadxHa7CB44GgDtFzuIYspx/u5CO qoM/J6g87U6zyyEnB4jWY3zoym3AAWK8EE6PE74HIUoe2ZFLKNxFw7UzH81ytEEVz/ZM 7q/nxUtk7lQMfBjV9PQnkNcbUrglGxOK9jaNJcBy09Oz96UnaD5LsEAefsx5UcytPi7F idMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=KIi+b63vezWI5TStQIlJQ/0ZKDUqsKFNSokJIXUIQ84=; fh=N2Pu5XCHnzvnsultChc+zExBixvv5wRPKr9UF/aBNKU=; b=f/kFLSZDIEnNcp1cGaLyIFVnLVGonVfTvfXmxvnmh8/scWmRATIE7xbr8C53K2H04p VpMHknMZJiS4Ds/53V0x8NJpCT4jygGklgknWAAr0NS7B5jD07gPFr0yAr/4Dln8j2h7 BNw+rl9wPwKyk46wmR9MrmdNYsAjTAlo8MvsjqI9/y30qPA9c1bD2T/dx18/zNymwhOt f6jRsMV9VPg2jAbeGLLldGuBTdrJdQDdYi32fO5t0//jaTlsvZkaG0cXGsFmzOGMicxK QM23ffe+gahqXxbo1J666F/zKqR84NVLHF9hKsf36t4ZnEo7OCnizb3DsmbFp8MIoeAX zGOQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UDS3kVH7; arc=pass (i=1); spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com. [2607:f8b0:4864:20::102b]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2aad1f5078dsi2697705ad.2.2026.02.09.21.13.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Feb 2026 21:13:06 -0800 (PST) Received-SPF: pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) client-ip=2607:f8b0:4864:20::102b; Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-3543b9f60e3so211657a91.3 for ; Mon, 09 Feb 2026 21:13:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770700386; cv=none; d=google.com; s=arc-20240605; b=aMe1B11FBqdkEU/FE1VtaN7k9/a0yXn+0Y2oRDfFfKC5uO3KZYwM3pZ8uNPgLx2nZZ c9WZx1DkWFQxaoioOIGr7/fHtwBmFkNxXyHAov2/UWYIzO2wLGGMYccllL/daFgiX9FA KP6mxNf4guXdCfSYeTYZdCQMfcbzhUKB3fQX+gMyYlDWPLkqqMu4n1hj/wyN3UwE4xhM opljWwX6D5Aaky7z1OwiQ5MiEepl/27RMEYZ+VwjyHKHpnh65ywtjn2kmPPgNbdXr3JY nXZcZUofyhWK/5UNSrUfD44pl6W7OKiYwvC4sCUfywrujVikA8RZsqI33wJvHnmQJj18 cAfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=KIi+b63vezWI5TStQIlJQ/0ZKDUqsKFNSokJIXUIQ84=; fh=N2Pu5XCHnzvnsultChc+zExBixvv5wRPKr9UF/aBNKU=; b=P/qwjuJAkBqWqHnaXkM77mkQQ3j7GXMJ1Vs4/2+cp4CxKLjMHf13mVEWR9BkVhKQ5p 77brG6RNJ09c4kzifSS6eT4JeShvuaEgzagJx0OxADsbzAfewymZMmIedGSvgNWWCSZ1 MSJ5hL9eKb2/v/J84CDoru4ONS4oNNqnHrpTh6/1fbP8kxiyTSvp02sEejOK7BPMPQCq OvD5fAWz6uW1XvH7GseAFKKd00iySyKQ1ByuX72TEamiP2305ykFiYUVcC7QVY7mauUZ QODcv/tuT1M4yNPFj7VYX/M0sxEB0yM4qrjChXnm7xAKT3C1vPegzUgFOzo5QCSUonwo /n1A==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aIxryDNjRxKtSsWl71QV8Szd4Flb2DdM4E13qafwoY2EwY5jWgIAvVM7YonTUm wqP+IqqL25vCqjGCxVetop9+SPx7mqkCQlXdujVSLKamOFFdkqBFp1Y3h2vQKdgeBFcT2ahuoTd KBnpuXVfbsQFOm0Qc1OV52aEXv0LgHnkE29smwSct43oXR+HgbQTgLMehoFvf7BcyGciJD/GSJz u2wY2fSglbB2kseGDEG5PNxAu+UFdhIpUyS5n0H30HmUkTrfOlyh2PWScn7arLlV4YNEtykiu2T 9q8vorA6rrzuOgAXrgPbQrX7S8+0qOtJRAsAwaW1pCM0Mkm8kqD3+Wn/MyOkSRa5TDE= X-Received: by 2002:a17:90b:33cb:b0:34c:c514:ee1f with SMTP id 98e67ed59e1d1-354b3bdb5f7mr13837951a91.11.1770700386402; Mon, 09 Feb 2026 21:13:06 -0800 (PST) MIME-Version: 1.0 References: <1A3B8BFA-41A6-4D0F-BBE6-E791F9785A5E@sprovoost.nl> In-Reply-To: <1A3B8BFA-41A6-4D0F-BBE6-E791F9785A5E@sprovoost.nl> From: Melvin Carvalho Date: Tue, 10 Feb 2026 06:12:55 +0100 X-Gm-Features: AZwV_QhQyuIXPw-ioWptjhodUZJGaArZ9cGRn14KKe5-1yi83Lf6HCjqjp1YB1o Message-ID: Subject: Re: [bitcoindev] Bip54: add sequence, timestamp (and version) to GBT To: Sjors Provoost Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000890713064a714fd5" X-Original-Sender: melvincarvalho@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UDS3kVH7; arc=pass (i=1); spf=pass (google.com: domain of melvincarvalho@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=melvincarvalho@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --000000000000890713064a714fd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable po 9. 2. 2026 v 20:46 odes=C3=ADlatel Sjors Provoost n= apsal: > Dear list, > > BIP54 proposes constraining the coinbase transaction nLockTime and > nSequence fields. Although it's not that difficult for pools to adjust > their software to set the correct values based on the known block height, > it seems appropriate and convenient to have node software provide these > values via the getblocktemplate RPC. > > SegWit had its own BIP for adding fields, but that was a significantly > bigger lift. My preference would be to just extend BIP54, as I've done > below. > > Feel free to respond on the list or here: > https://github.com/bitcoin/bips/pull/2097 BIP54=E2=80=99s consensus fixes are currently uncontroversial. Bundling new getblocktemplate additions into it changes that and expands the policy surface. Those additions should be specified separately, where they belong. > > > Current version of BIP54: > https://github.com/bitcoin/bips/blob/master/bip-0054.md > > Here's the proposed expansion: > > ------- > ## Miner forward compatibility > > [...] > > The coinbase transaction is usually crafted by mining pool software. To > the best of the authors' > knowledge, there does not exist an open source reference broadly in use > today for such software. > We encourage mining pools to update their software to craft coinbase > transactions that are > forward-compatible with the changes proposed in this BIP. This can be don= e > by using the new > `getblocktemplate` fields described below, once node software supports it= . > > ## getblocktemplate changes > > The template Object of the `getblocktemplate` JSON-RPC call > ([bip-0022][BIP22]) is extended with > the following keys: > > | Key | Required | Type | Description | > |-----|----------|------|-------------| > | `coinbase_locktime` | Yes | Number | coinbase `nLockTime` value | > | `coinbase_sequence` | Yes | Number | coinbase `nSequence` value | > | `coinbase_version` | Yes | Number | coinbase `nVersion` value | > > Types are JSON types as defined in [bip-0022][BIP22]. > > The `coinbase_locktime` field specifies the exact value that MUST be used > for the coinbase > transaction's `nLockTime` field. > > The `coinbase_sequence` field specifies a value that SHOULD be used for > the coinbase transaction > input's `nSequence` field. If a different value is used, it MUST NOT be > `0xffffffff`[^12]. > > The `coinbase_version` field specifies the value that SHOULD be used for > the coinbase transaction's > `nVersion` field[^13]. > > ------- > > Footnotes: > > [^12]: **Why SHOULD for `coinbase_sequence`?** > The only consensus constraint on `nSequence` is to disallow `0xffffffff= `. > The server could communicate this via a bit mask, but for simplicity it > provides the entire `nSequence` value. Clients SHOULD use this value, s= o > that future soft forks can safely add additional constraints. > [^13]: **Why is `coinbase_version` included?** > This BIP does not constrain the coinbase transaction's `nVersion`, but > including it means `getblocktemplate` now covers all coinbase transacti= on > fields that could potentially be constrained by a future soft fork. The > coinbase input's prevout txid (32 zero bytes) and vout index > (`0xffffffff`) > are fixed by consensus, so they can be safely hardcoded in mining > software. > At the time of writing, there is no consensus constraint on transaction > versions. Transaction version 2 is the latest version with defined > semantics, as specified in [bip-0068][BIP68], but its relative lock-tim= e > rules do not apply to the coinbase input. Nonetheless, clients SHOULD u= se > this value so that they don't need to be updated if a future soft fork > constrains `nVersion`. > > --- > > - Sjors Provoost > > > > -- > 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/1A3B8BFA-41A6-4D0F-BBE6-E791= F9785A5E%40sprovoost.nl > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAKaEYh%2BcjFBx42vhag3dd1zF0QFbgXHPL0fBUDFcA4aZY63EvQ%40mail.gmail.com. --000000000000890713064a714fd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


po 9. 2. 2026 v= =C2=A020:46 odes=C3=ADlatel Sjors Provoost <sjors@sprovoost.nl> napsal:
Dear list,

BIP54 proposes constraining the coinbase transaction nLockTime and nSequenc= e fields. Although it's not that difficult for pools to adjust their so= ftware to set the correct values based on the known block height, it seems = appropriate and convenient to have node software provide these values via t= he getblocktemplate RPC.

SegWit had its own BIP for adding fields, but that was a significantly bigg= er lift. My preference would be to just extend BIP54, as I've done belo= w.

Feel free to respond on the list or here: https://github.co= m/bitcoin/bips/pull/2097

BIP54=E2=80=99= s consensus fixes are currently uncontroversial.

B= undling new getblocktemplate additions into it changes that and expands the= policy surface. Those additions should be specified separately, where they= belong.
=C2=A0


Current version of BIP54: https://github.com/= bitcoin/bips/blob/master/bip-0054.md

Here's the proposed expansion:

-------
## Miner forward compatibility

[...]

The coinbase transaction is usually crafted by mining pool software. To the= best of the authors'
knowledge, there does not exist an open source reference broadly in use tod= ay for such software.
We encourage mining pools to update their software to craft coinbase transa= ctions that are
forward-compatible with the changes proposed in this BIP. This can be done = by using the new
`getblocktemplate` fields described below, once node software supports it.<= br>
## getblocktemplate changes

The template Object of the `getblocktemplate` JSON-RPC call ([bip-0022][BIP= 22]) is extended with
the following keys:

| Key | Required | Type | Description |
|-----|----------|------|-------------|
| `coinbase_locktime` | Yes | Number | coinbase `nLockTime` value |
| `coinbase_sequence` | Yes | Number | coinbase `nSequence` value |
| `coinbase_version` | Yes | Number | coinbase `nVersion` value |

Types are JSON types as defined in [bip-0022][BIP22].

The `coinbase_locktime` field specifies the exact value that MUST be used f= or the coinbase
transaction's `nLockTime` field.

The `coinbase_sequence` field specifies a value that SHOULD be used for the= coinbase transaction
input's `nSequence` field. If a different value is used, it MUST NOT be= `0xffffffff`[^12].

The `coinbase_version` field specifies the value that SHOULD be used for th= e coinbase transaction's
`nVersion` field[^13].

-------

Footnotes:

[^12]: **Why SHOULD for `coinbase_sequence`?**
=C2=A0 The only consensus constraint on `nSequence` is to disallow `0xfffff= fff`.
=C2=A0 The server could communicate this via a bit mask, but for simplicity= it
=C2=A0 provides the entire `nSequence` value. Clients SHOULD use this value= , so
=C2=A0 that future soft forks can safely add additional constraints.
[^13]: **Why is `coinbase_version` included?**
=C2=A0 This BIP does not constrain the coinbase transaction's `nVersion= `, but
=C2=A0 including it means `getblocktemplate` now covers all coinbase transa= ction
=C2=A0 fields that could potentially be constrained by a future soft fork. = The
=C2=A0 coinbase input's prevout txid (32 zero bytes) and vout index (`0= xffffffff`)
=C2=A0 are fixed by consensus, so they can be safely hardcoded in mining so= ftware.
=C2=A0 At the time of writing, there is no consensus constraint on transact= ion
=C2=A0 versions. Transaction version 2 is the latest version with defined =C2=A0 semantics, as specified in [bip-0068][BIP68], but its relative lock-= time
=C2=A0 rules do not apply to the coinbase input. Nonetheless, clients SHOUL= D use
=C2=A0 this value so that they don't need to be updated if a future sof= t fork
=C2=A0 constrains `nVersion`.

---

- Sjors Provoost



--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1A3B= 8BFA-41A6-4D0F-BBE6-E791F9785A5E%40sprovoost.nl.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAKaEYh%2BcjFBx42vhag3dd1zF0QFbgXHPL0fBUDFcA4aZY63EvQ%40ma= il.gmail.com.
--000000000000890713064a714fd5--