From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 13 Jan 2026 16:07:42 -0800 Received: from mail-qt1-f189.google.com ([209.85.160.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vfoQH-0000B5-62 for bitcoindev@gnusha.org; Tue, 13 Jan 2026 16:07:42 -0800 Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-5014b22d678sf22571cf.0 for ; Tue, 13 Jan 2026 16:07:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768349255; cv=pass; d=google.com; s=arc-20240605; b=dEOjklp/auEQhggywVBbWp8SRe+uDLVZQHNF33Uqn4FQBMsd7liOGAXfsIydc8QxLx mOq/otgdtuYiyccNs1g7EKpu6gx5/ri6NUCZPUDHYzATxOq/qwY3d2VMdqienABuwM2E /s3YbFJjtTPoeYscRQ2daz0VYIRN386bKbw+Vc3N1oHy4gquRlzX4ihRyEWn6T8bAHKp 5MHf5IO2y1TKPExQg2GgTnjfFl91AeGSdND+gGOJrO5PcNUNIZqOcHzMgYF8smyl89UA uS2kAhc9WKLHreYuQoqEhy9g/2N+1pl2S/767/hrZyV/ByQV6yQwfdMrkbEsti+QHD2P HiJQ== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=UR4LeOmtbrIMo9eYqfbeLKkuamt3BMeqkE4Wb8hcSGE=; fh=BEyGa75s2tExX/XAe1BaQmIQjK5z2YsK1D4wpVd6lis=; b=khirlAwydZr3l5sRpVekE+hAYWlCEF45jgrirB8Sds5qqb7DIe7ABXvOEAqYFTgwV4 UKkCZ1N7Zzs1q3M3ckdETajPaWlg1XA99YLonOHC1vHI6TDsXawPgaYHMXqGp1SjGmOQ 5UVQRWZdbhWCsShPisqZ4i2iq4QNqjnWrQ6e5ZHltPzRm5Xv2EeYGOtUYk/KUOJy4vnW etUEe60akTvkk7HapbtYbCu3Ql6gtxo8dH3/wg0OmWBkX1iXz8GmSLMLoFKq1w+ku1SO vE+bH/tWx5EqTmUGYwfWsZ+m3NaI0K40J6/+RJYR+uXdI7ImIYNsEJXutSj3TJlxWUbd /hdw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HhDWFikO; spf=pass (google.com: domain of juharmubarek4@gmail.com designates 2a00:1450:4864:20::142 as permitted sender) smtp.mailfrom=juharmubarek4@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=1768349255; x=1768954055; 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=UR4LeOmtbrIMo9eYqfbeLKkuamt3BMeqkE4Wb8hcSGE=; b=CesXQRB7yYFfaP7hcqEmeTho6vXKL24uSMcO26bT/udgQsvJGdqL8ILOS/7VCaCf6K mWYtrHpv4WM2voHXQMWW+XMxJVtJadvIwsECW9q7YRLrbiazWFb9WarVaAAXaG210U41 lOTioZ1J7MT8g7UqIYI167qHVMnuGHc3knkZpdrGeFUt/2LLaHKeWuvWGmAb1IqNpN08 ZpPY36NDpdA2Xk7QmjLmLhFlDfvNgYQpMVzkttXUjF/C44RAgDP9+MES+7tWZ0UnOuPG xcyQejL0b5MaxTnjtrgYM3vHAzqZU5XjlM2Mv6OQ1xD6YHuM3Zz6S/ZyhB+BqARLWjg9 2ZNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768349255; x=1768954055; 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=UR4LeOmtbrIMo9eYqfbeLKkuamt3BMeqkE4Wb8hcSGE=; b=hxqnjNhoA8pJYrzzS0l3K1/xVLV0JSrQKgv656TLxVofiOYg/T5aOFsGx0GqbmAUbC lEkf34f5K41um4qYY1JT1R3Ir27Vqd86SUL675WI7iTux+S5xaSoU/J2TJWxYzikC1eS Btw6KS3nYxLZ+In0wxoQRjVSiYdGv8vcHlQ4IO6/aTn3k9XMLcqomxYMIja8I4o/vcTr Csf9mqn8Gm65/euNL+z+hVCnxLktwsMOHMe6iYG0QtDZ8JnBbldUa06vv+UNw/OUvlJ/ Syfh8mQCcb5mI73YuMN1GYmkSSd+OYRYG4gGHhrOFk40SW4knXqeURdTVYDhU7c7LidQ i04g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768349255; x=1768954055; 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=UR4LeOmtbrIMo9eYqfbeLKkuamt3BMeqkE4Wb8hcSGE=; b=bLg0irHR8tsDl09/kYzNEnVDMtkSgZQk2LbEctDeJ8gNd1jvxx7/ZV0imqgZfNBbTr jn3wxNIyOxgWza9s9Vulp7T9p/ZAAtoA0hx2D1HtQO/YBhGZh27k756p3J0vszXyE84P v/PTlA8zd0JZhiqW/Q4TbZay+tcAlSJ8RIyWLPWjiv6usnnjZ1qXt+sH5nNRuiv6GtJa X313+9UfpIXhFj4632OJJ3uR6CT6GD+DLVG8LiWZLUZAuphABnArVs+DWJmoaofQyQUZ 1hsmCoVOvMrg3IvUjIZPFdhgDscEhLN1PuzkoI3S2RDU9FvtEvbVJ7ZsceFB0UWZwAMm Ik/g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWQs9N814y9KdqHT0tzQ7PlWpueChH4UcI/usv9p0vqi+FRLHzZps98Ptm+cbRn+UOvhnLiwz/p6gdp@gnusha.org X-Gm-Message-State: AOJu0YxUs/87dMWm3LA18tYclxjbBRYibI8gVA6wu6R1qIhDdEwNh3UO K0ItKarmUfYyrDr+L/l0NjnVtQ1wAQQ56ihZA4O589f5Ig+5T/LVpyNn X-Received: by 2002:a05:622a:40cd:b0:4f1:cd0c:80f6 with SMTP id d75a77b69052e-501482643d5mr14941001cf.49.1768349254879; Tue, 13 Jan 2026 16:07:34 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EL+3tIcBcgOnKSSWOReksxx2C6IDRFUd89Bi+7q+cHxw==" Received: by 2002:ac8:580f:0:b0:4eb:7676:b2f with SMTP id d75a77b69052e-4ffa727942fls163012691cf.2.-pod-prod-08-us; Tue, 13 Jan 2026 16:07:27 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCURrJ5+tX//1UOVaDLLCByickHMyTj4148+mePaUNqZAV/yYUnm350XkzFIR8ANuNo02rXrIs7+UyuJ@googlegroups.com X-Received: by 2002:a05:620a:c4b:b0:85d:aabb:47d4 with SMTP id af79cd13be357-8c52fb32892mr140190585a.6.1768349247571; Tue, 13 Jan 2026 16:07:27 -0800 (PST) Received: by 2002:a05:6402:a2d2:20b0:641:45b3:cef8 with SMTP id 4fb4d7f45d1cf-653e8bf3b55msa12; Tue, 13 Jan 2026 09:00:02 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWFGjAODS5TeCXW0bXNhcbwrIKYUjyZhRg2Or6WMPeWr+VgQL2IEYtMKEW3y7g0qE1e0aX8aXJdNiux@googlegroups.com X-Received: by 2002:a17:906:fd84:b0:b83:9751:4334 with SMTP id a640c23a62f3a-b844538b363mr2248434266b.50.1768323600648; Tue, 13 Jan 2026 09:00:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768323600; cv=none; d=google.com; s=arc-20240605; b=cz5pSEF7L2L7WntFpIR0rw3fXMjEQZ6gwWQ+U7vTCs38GWb7Qz/NmivkBw4JEYOpMx L7daJcBPY5wwCbVzTgxijS99tP4iwlJd+lVDLq3u3V7qlmQ/gQNp5GSIPtkhfKwTj10l HuDv+xj5Jie6g0jrSt2yYM1gvtmo96gotdJNhpDyRrz3QLOK8JHfCCoOsvdAsWai+AXZ reya17RD4mJK5sMtyamzqWSHoIwZGJcJpVMnw0MRvRqMBZOQ0IIYpyAGk3v/oS6/diia /7wxpXtDcgbrtQy452DRRVIba3mj6tVjCWRAI8+tNvumf9Nz4X0Sf1nhcfnYp9C2ZUPl 9t5g== 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=qPz/BIZxP0e6vu1wBfC8705JXTvpGS3rlLMV7fegW7s=; fh=dJYLH0tchAyplQzKF4smviFQojM0O8Pp5hfd9Th8fKA=; b=lO3uMDXW0L25ImgpNULSJDcO5AySE0CUMtdqt1e1t+i3Tbrjt97CJN1l4CorqikBp5 wBrGPPJcTKqaFNjs0nsr/PwwZ/wTZj+XaNNY0kxWWU4BHxMII6C0VLuDesFiF53NgCYM JRkz1pQqj+HuFlBfweB7V+f6dBi6e0qINFase6Jb50NPsnqigaThHxP4jdjaMtjqpkxj d9hGArc081poYWoCdovN66Hv0GCumNDZ8cXvxIPSd7Kq3v0qm//htKsLMToSt0OfQWP1 Jdpqdd9qbElXvSEznkWDdqeGlhZQ4JcPcB/KyKexRlL4ziyFz5a6xZF9agrJGTZww6U9 yPgQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HhDWFikO; spf=pass (google.com: domain of juharmubarek4@gmail.com designates 2a00:1450:4864:20::142 as permitted sender) smtp.mailfrom=juharmubarek4@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com. [2a00:1450:4864:20::142]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-b870813a9a1si13530266b.0.2026.01.13.09.00.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 09:00:00 -0800 (PST) Received-SPF: pass (google.com: domain of juharmubarek4@gmail.com designates 2a00:1450:4864:20::142 as permitted sender) client-ip=2a00:1450:4864:20::142; Received: by mail-lf1-x142.google.com with SMTP id 2adb3069b0e04-59b8466b4a8so3261589e87.1 for ; Tue, 13 Jan 2026 09:00:00 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUT0O13uQ24aaHrVYLcUU54dWWzzPbmBZVMns6dd6r/y97Lb33n2AL/CNKOGwnSHYdqZFJ28kmaWD6o@googlegroups.com X-Gm-Gg: AY/fxX5MUIXaCu5EgI775sUt0b7/GiVBUn0ezitaTj0Id2tTqbQXVum3X8iW24rkYjc aOMO4UXpI+V0Xfq7j3uhuu8HlKOfmQCyB5VhPHD00FLmIT8/6NKhULXmfrrqSzNTL8hZ/QueWVT 6CTK5y16Sl3BTh7VYwJIRKjmnLal3oo25IjErcQb1gTplao8B1+DqrUO41d1lBOIJn2lpRg40P6 /o+xh4liEtB0+jp9Q8roek+sAmSoKTnBKQYAfkDXHNWRh5/dg/JD7ArIbv5jjh6Pi3ohxZpdA== X-Received: by 2002:a05:6512:31d3:b0:59b:7da6:24cd with SMTP id 2adb3069b0e04-59b7da6268dmr4473519e87.46.1768323599574; Tue, 13 Jan 2026 08:59:59 -0800 (PST) MIME-Version: 1.0 References: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> <33ffd6c4-6395-4f6c-a6e8-8b43220cdb00@mattcorallo.com> In-Reply-To: From: Mubarek Juhar Date: Tue, 13 Jan 2026 19:59:46 +0300 X-Gm-Features: AZwV_QgfTeAllt-JIf0cvMTRNRi0eMBuoIoMagn-ghGVdfIQq-l585HzwTzYcl8 Message-ID: Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 To: Antoine Riard Cc: Matt Corallo , Sjors Provoost , Bitcoin Development Mailing List , Antoine Poinsot Content-Type: multipart/alternative; boundary="000000000000002be3064847ec77" X-Original-Sender: juharmubarek4@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HhDWFikO; spf=pass (google.com: domain of juharmubarek4@gmail.com designates 2a00:1450:4864:20::142 as permitted sender) smtp.mailfrom=juharmubarek4@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 (/) --000000000000002be3064847ec77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject Re: Coinbase extranonce and nLockTime Hi all, thanks for the clarifications. While the coinbase scriptSig is consensus-limited to 100 bytes, it still provides more than enough entropy when combined with nTime, nVersion (BIP310), and the header nonce, so search space exhaustion is not a practical concern today. Although nLockTime is attractive as a fixed-offset field, it is not free to roll due to its consensus semantics and limited validity window, which likely explains why it hasn=E2=80=99t seen adoption in the wild. In practice, extr= anonce handling already occurs at the controller or proxy level under Stratum v1/v2, meaning serialization complexity exists regardless of which coinbase field is varied. Given that current approaches scale to existing hash rates, this feels less like a performance issue and more like a future-proofing and design-hygiene discussion, where preserving flexibility in the coinbase seems prudent. Best, Mubarek On Tue, Jan 13, 2026, 5:55 AM Antoine Riard wrote= : > Hi Corallo, > > > Assuming some future change to stratum v1/v2 to allow for this (which I > think is basically a "never > > going to happen"), its worth noting that you can't just roll it for fre= e. > > This is not like there have been a multitude of pooling protocols deploye= d > in the past, all with > their awful long-polling mechanisms and other tricks. Saying we should > only consider stratum > v1/v2 in matters of consensus-design it can be a bit blindsighted imho. A= s > of today block > height, considering the situation where it's height-based locktime, that > would be 19-bit > that you could use as an extranonce, if my measurements are correct. > > On the other hand, making the coinbase transaction with an always valid > coinbase's nLocktime > transaction, this opens the door in terms of off-chain protocols and > use-case design (e.g > proof-of-work swap), where now you can use the consensus mandatory check > of the coinbase > nLocktime's field as a novel building block primitive. > > Best, > Antoine > OTS hash: 45f28303770b376e2ae8f9e0072ae236d2b42aa4c84036f87ec9903a74a385b= 3 > > Le jeu. 8 janv. 2026 =C3=A0 16:36, Matt Corallo a > =C3=A9crit : > >> >> >> On 1/8/26 3:30 AM, Sjors Provoost wrote: >> > Hello Riard, >> > >> >> Thanks for the update. If I'm understanding correctly Luke's concern, >> >> currently the coinbase's scriptSig is used to store an extranonce. On= e >> >> has to observe first there is no consensus limit on the size of a >> >> transaction, which holds for the coinbase tx too, a fortiori there is >> >> no limit on the extranonce size a miner could fit in the scriptSig. >> > >> > >> > The coinbase scriptSig is limited to 100 bytes [0]. Some speculation a= s >> to >> > why [1]. >> > >> > The main issue I see is complexity of implementation. The nLockTime is >> always >> > the last 4 bytes of a transaction, so an ASIC can roll it without >> having to >> > understand anything about serialisation. >> >> Assuming some future change to stratum v1/v2 to allow for this (which I >> think is basically a "never >> going to happen"), its worth noting that you can't just roll it for free= . >> Its already the case that >> nLockTime has consensus meaning on the coinbase transaction - its >> enforced like any other block. So >> there's relatively little rolling you can do until you get to the curren= t >> block height and have to >> go do something else (I imagine this is why its not been used for this >> purpose in the past, at least >> in part). So the ASIC actually has to understand quite a bit to roll thi= s. >> >> Instead, in practice, ASICs (or their controllers) roll nTime, which is >> even better cause its in the >> header and you know you can ~always roll it once a second. Then rolling = a >> nonce in the coinbase is >> easy cause you can just do it in the controller and get plenty of >> headroom on the ASIC itself with >> nTime and a few midstates. >> >> > The scriptSig OTOH is variable length, so it needs to read the length >> byte in >> > order to figure out which 4 bytes are at the end. The pool or proxy >> then also >> > needs to ensure those 4 bytes are pre-initialised*. >> > >> > The approach suggested by Towns [4] of appending a 0-sat OP_RETURN >> output with >> > padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk is >> probably >> > better, but not because like nLockTime it has a small hashing midstate >> > benefit. It's easier to implement. >> > >> > Compared to varying the end of the scriptSig, this can be easier for a= n >> ASIC >> > because it can update a fixed 4-byte field at a known offset from the >> end, >> > rather than having to parse variable-length fields (notably the >> scriptSig >> > length) to locate the bytes to roll. >> > >> > I think that extra complexity is doable and justifiable, but I've neve= r >> built an ASIC. >> > >> > Note that today Stratum v1 simply splits the scriptSig [5] into two >> parts, as does >> > Stratum v2 [3], but presumably that's all done by the control board an= d >> it makes >> > sense to want to push rolling functionally into the ASIC silicon, wher= e >> even >> > simple concatenation might be too involved - but updating bytes at kno= wn >> > positions is easy. >> > >> >> The point being made is that the nLocktime field of the coinbase >> >> transaction could be used as a more efficient extra nonce due to >> >> the positional location of nLocktime in a serialized coinbase being >> >> one of the latest message block to be processed [0]. >> >> >> >> Nothing prevent a miner in already doing this and draw a speed >> advantage >> >> from the diminished computational work. I have not looked into CGmine= r >> code >> >> or one of its derivative forks, if there is an implemented option to >> do that, >> >> but yes there could be non-published existing mining firmware doing >> it. IIUC, >> >> BIP54 would nullify this theoretical "speed advantage" for all miners= . >> > >> > I don't think there's currently a speed advantage, so I wouldn't expec= t >> to observe >> > this behaviour in the wild just yet. The combination of rolling nVersi= on >> > (BIP310) [2] and updating nTime every second, works fine up to 280 TH/= s. >> > >> > Beyond that an ASIC will need to touch the coinbase. >> > >> > - Sjors >> > >> > [0] >> https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp= #L47-L51 >> > [1] >> https://bitcoin.stackexchange.com/questions/35455/why-bother-having-limi= tations-on-bitcoin-coinbase-transaction-scriptsigs >> > [2] https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki >> > [3] >> https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.= md#511-standard-job >> > [4] >> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=3D= sjors >> > [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify >> > >> > * =3D otherwise the ASIC needs to know how to extend it, know that it >> can't be >> > more than 100 bytes, and that it can't touch the BIP34 part, or really >> any >> > subsequent bytes that a future soft fork might constrain >> > >> >> -- > 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/CALZpt%2BFf_L84d8LssCZWSBM0H= Pvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com > > . > --=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/= CAOCjFt9QktYQ%2B9Z-peYJHaXSgJuHwCZGZHiWyMbm2LwK5ztUKg%40mail.gmail.com. --000000000000002be3064847ec77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Subject
Re: Coin= base extranonce and nLockTime
Hi all, thanks for the= clarifications. While the coinbase scriptSig is consensus-limited to 100 b= ytes, it still provides more than enough entropy when combined with nTime, = nVersion (BIP310), and the header nonce, so search space exhaustion is not = a practical concern today. Although nLockTime is attractive as a fixed-offs= et field, it is not free to roll due to its consensus semantics and limited= validity window, which likely explains why it hasn=E2=80=99t seen adoption= in the wild. In practice, extranonce handling already occurs at the contro= ller or proxy level under Stratum v1/v2, meaning serialization complexity e= xists regardless of which coinbase field is varied. Given that current appr= oaches scale to existing hash rates, this feels less like a performance iss= ue and more like a future-proofing and design-hygiene discussion, where pre= serving flexibility in the coinbase seems prudent.
B= est,
Mubarek

On Tue, Jan = 13, 2026, 5:55 AM Antoine Riard <antoine.riard@gmail.com> wrote:
Hi Corallo,

> Assuming some future chang= e to stratum v1/v2 to allow for this (which I think is basically a "ne= ver
> going to happen"), its worth noting that you can't jus= t roll it for free.

This is not like there have been a multitude of = pooling protocols deployed in the past, all with
their awful long-pollin= g mechanisms and other tricks. Saying we should only consider stratum
v1= /v2 in matters of consensus-design it can be a bit blindsighted imho. As of= today block
height, considering the situation where it's height-bas= ed locktime, that would be 19-bit
that you could use as an extranonce, i= f my measurements are correct.

On the other hand, making the coinbas= e transaction with an always valid coinbase's nLocktime
transaction,= this opens the door in terms of off-chain protocols and use-case design (e= .g
proof-of-work swap), where now you can use the consensus mandatory ch= eck of the coinbase
nLocktime's field as a novel building block prim= itive.

Best,
Antoine
OTS hash: 45f28303770b376e2ae8f9e0072ae23= 6d2b42aa4c84036f87ec9903a74a385b3

Le=C2=A0jeu. 8 janv. 2026 =C3=A0=C2=A016:3= 6, Matt Corallo <lf-lists@mattcorallo.com> a =C3=A9crit=C2= =A0:


On 1/8/26 3:30 AM, Sjors Provoost wrote:
> Hello Riard,
>
>> Thanks for the update. If I'm understanding correctly Luke'= ;s concern,
>> currently the coinbase's scriptSig is used to store an extrano= nce. One
>> has to observe first there is no consensus limit on the size of a<= br> >> transaction, which holds for the coinbase tx too, a fortiori there= is
>> no limit on the extranonce size a miner could fit in the scriptSig= .
>
>
> The coinbase scriptSig is limited to 100 bytes [0]. Some speculation a= s to
> why [1].
>
> The main issue I see is complexity of implementation. The nLockTime is= always
> the last 4 bytes of a transaction, so an ASIC can roll it without havi= ng to
> understand anything about serialisation.

Assuming some future change to stratum v1/v2 to allow for this (which I thi= nk is basically a "never
going to happen"), its worth noting that you can't just roll it fo= r free. Its already the case that
nLockTime has consensus meaning on the coinbase transaction - its enforced = like any other block. So
there's relatively little rolling you can do until you get to the curre= nt block height and have to
go do something else (I imagine this is why its not been used for this purp= ose in the past, at least
in part). So the ASIC actually has to understand quite a bit to roll this.<= br>
Instead, in practice, ASICs (or their controllers) roll nTime, which is eve= n better cause its in the
header and you know you can ~always roll it once a second. Then rolling a n= once in the coinbase is
easy cause you can just do it in the controller and get plenty of headroom = on the ASIC itself with
nTime and a few midstates.

> The scriptSig OTOH is variable length, so it needs to read the length = byte in
> order to figure out which 4 bytes are at the end. The pool or proxy th= en also
> needs to ensure those 4 bytes are pre-initialised*.
>
> The approach suggested by Towns [4] of appending a 0-sat OP_RETURN out= put with
> padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk is p= robably
> better, but not because like nLockTime it has a small hashing midstate=
> benefit. It's easier to implement.
>
> Compared to varying the end of the scriptSig, this can be easier for a= n ASIC
> because it can update a fixed 4-byte field at a known offset from the = end,
> rather than having to parse variable-length fields (notably the script= Sig
> length) to locate the bytes to roll.
>
> I think that extra complexity is doable and justifiable, but I've = never built an ASIC.
>
> Note that today Stratum v1 simply splits the scriptSig [5] into two pa= rts, as does
> Stratum v2 [3], but presumably that's all done by the control boar= d and it makes
> sense to want to push rolling functionally into the ASIC silicon, wher= e even
> simple concatenation might be too involved - but updating bytes at kno= wn
> positions is easy.
>
>> The point being made is that the nLocktime field of the coinbase >> transaction could be used as a more efficient extra nonce due to >> the positional location of nLocktime in a serialized coinbase bein= g
>> one of the latest message block to be processed [0].
>>
>> Nothing prevent a miner in already doing this and draw a speed adv= antage
>> from the diminished computational work. I have not looked into CGm= iner code
>> or one of its derivative forks, if there is an implemented option = to do that,
>> but yes there could be non-published existing mining firmware doin= g it. IIUC,
>> BIP54 would nullify this theoretical "speed advantage" f= or all miners.
>
> I don't think there's currently a speed advantage, so I wouldn= 't expect to observe
> this behaviour in the wild just yet. The combination of rolling nVersi= on
> (BIP310) [2] and updating nTime every second, works fine up to 280 TH/= s.
>
> Beyond that an ASIC will need to touch the coinbase.
>
> - Sjors
>
> [0] = https://github.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L4= 7-L51
> [1] https://bitcoin.stackexchange.com= /questions/35455/why-bother-having-limitations-on-bitcoin-coinbase-transact= ion-scriptsigs
> [2] https://github.com= /bitcoin/bips/blob/master/bip-0310.mediawiki
> [3] https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-= Protocol.md#511-standard-job
> [4] htt= ps://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=3Dsjors<= /a>
> [5] https://en.bitco= in.it/wiki/Stratum_mining_protocol#mining.notify
>
> * =3D otherwise the ASIC needs to know how to extend it, know that it = can't be
> more than 100 bytes, and that it can't touch the BIP34 part, or re= ally any
> subsequent bytes that a future soft fork might constrain
>

--
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/CALZpt%2BFf_L84d8= LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com.

--
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/CAOCjFt9QktYQ%2B9Z-peYJHaXSgJuHwCZGZHiWyMbm2LwK5ztUKg%40ma= il.gmail.com.
--000000000000002be3064847ec77--