From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 12 Jan 2026 18:55:15 -0800 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vfUYs-00028O-6m for bitcoindev@gnusha.org; Mon, 12 Jan 2026 18:55:15 -0800 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-3f0ee9140dbsf11394883fac.1 for ; Mon, 12 Jan 2026 18:55:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768272908; cv=pass; d=google.com; s=arc-20240605; b=iwQWqqgg+tPzhQO7s2MVmvOocVvc2VUs3BuPhk2u8jIT3QcP+ngruTqUXu/BGC4lx7 Y32HES0XV2AJMnDlZtFJr1AO1CZ/gBBsVV660XSJWM+kXDjM/giaJg0DdPLzmESI95tT lnm3nHWEvq0TZiuqiJkFlKrQzFJZGCt0zNhVEbKjWJPeYE0UPp/qszjeQzVzznatyBR+ woUx9KAXmPyEsCcSMuwMoZ78UBbK9M9tEBuZrvrEtWDRrqvnUi458BKz42GOzKe0QzIL NE1dLJnDozrT9yMIm+ip2rbXh+qD26qz3C/ZiCwZu13mP2lCCN6lX42SbKeprQ7PRSIu 1P6g== 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=nhUFKNrE2mVkwhjrabEBDAAiDT1hGwyucUgAkf7KdR0=; fh=axOoX445CDIpuMDBP8g4k0o79IOrq5HK0QQG8DVgAew=; b=UMYWOlFb6TsUJNBdGb3j3wZHXL9LPrTCYPIsYL2izDNSEi1y17MpiigL4kvOeyHFKj C6BhYk1jcU2s61RPTNTDpJKnOyR2D89GytVkHc3ArgqjLvUqQwkyy9jSwKYyAROLlLTK nrqeiYv/VReKwZmILjpvPZUgwfzafJRN12+H4gmZenuELLxFKTKSDDilu2K41NKFcz1v 3ZBLDkHuURwJfbCKWl2so/si/xHnmnSVZ/oGTDBnhtn8YwcLDmkaa/GWOmla4Q6RW8kb 9ZfgvvwjgDzH6glwLkLfROMnLCXEmmBWA/LE/ZLe2Mm1z4JiD4H3mwMeKzm/Z/EBkPQj Jj7w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UBU6p2I5; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 as permitted sender) smtp.mailfrom=antoine.riard@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=1768272908; x=1768877708; 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=nhUFKNrE2mVkwhjrabEBDAAiDT1hGwyucUgAkf7KdR0=; b=V6j9oyakUhwRNekOnCf63QHb6ZbS0l2Io/hvdaU88RBKbxgVOjY3md+wx8xz/Gf6L0 HbRDiCO19hwSjPzS5B2DEOrzLdOOoKdg52Ms8B9PlQAb+fgquKTcm14jpuCL6J6gxyzD WMCxoAvQ+tjFdxrzP2nKUd/FPLyt+La83xwoOco8okAn6Yo7p9iz/8wBl8OpcOTk9yct IN+NDZMBHa5eSc+O8E+ITviaprHPX5DwLn0nkvee47QK09dmJ/1tdohjB+X7uCLbcaV8 l8iiQ0Yo4iItg8VmVN/y5gmKFBUPLGuhdDpUBqrvUnTluOj1ue5CV12XG0dhGLXmROTj 9S8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768272908; x=1768877708; 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=nhUFKNrE2mVkwhjrabEBDAAiDT1hGwyucUgAkf7KdR0=; b=lPPPLk1BZaF3QC7oMLyW0XRdjL7DjFjWUmcrPGFD3cK7M5Jwr9grniT3ML4oO2/pWF AzOs5xAWxXAjDVwHeGBDm4BBVbU4yrQpGq/c8zbJUqJ5JUNocNznQUTqFeJ3/XGO+FHv MT4iuog0gp3biJFndvBV+DhcnaRgjjy+GclJz+pk6vjB5dUmvzyLRsgcE1WroPcOv2Yx 0vV2pUoFli190L+49VGN5paYayo3NhYFO5yHTGlrUD/ZqI9I6CFK5OwCtW526KaFYXcL YC/fYwQQODgRAbgeMFI7c7VxYpS31ngXCjgPpcwPBTiB6PDYAniqNetStJwkvFoyXr7w lF+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768272908; x=1768877708; 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=nhUFKNrE2mVkwhjrabEBDAAiDT1hGwyucUgAkf7KdR0=; b=qpbvUj1UZO/95HO6HABgEBaL12hrtq/SuB7mCHHT2lfl+OV9tUFq7NqzJWnJ56xpGA 4coNFjWEnU2k0s5POUUSQHl8Y2ryl6NWyLnlcrK50BOt0LuIilpo0KPDqYZMjxMQffId QaoFSs4AvMuRbiRokG7wnNidCQySgwMS/REdl1+CR7Xk2ymcOg0KrI9SDehCzh4b2/Yq OzYS7r/tAqS1CHlUYaGFvPjnGgbKktN7Ic8V6KDRm1QyMVWo7/Cs5WvHU1j2aCxpCkFT wi4CdWr1XpEpokRpl2vYK0Gx6py23xLyEhKXEnkH4RsEeeJ1qGcZPI3loVD7x7zhK78f 2eLw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUvDWVZxrKp4ZPdYAeGO3s5QPvTS4FcUVkFuDf9+v9qzjoPSP55D5usKYUHMBn30SSucgfLF8zXprOj@gnusha.org X-Gm-Message-State: AOJu0Yz1R0hKCplwT/veYMuJBiCgRXJmZEshOulVQC8yq6BB1WY89mxy Xn9WR4B7isPI1zMGOZVPqzwaBaLlPT+nApEybz2EW+4ixRhbrwS03hue X-Received: by 2002:a05:6871:2013:b0:3e8:9b72:5cda with SMTP id 586e51a60fabf-4006e417334mr837480fac.11.1768272907301; Mon, 12 Jan 2026 18:55:07 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FlHrGhyK8+HQNjKMrqRMqBghjwPv7XFiU/4BjINRWMhA==" Received: by 2002:a05:6870:934b:b0:3fd:e7af:6a2 with SMTP id 586e51a60fabf-3ffc01eb702ls1706276fac.1.-pod-prod-00-us-canary; Mon, 12 Jan 2026 18:55:00 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVS+bw8M90m8Vri+UcHEieeQyibuI6+ZvqA442voD37Xh9G6PqgEOWDVmIVxt1gBlHpyrRRgH964tEw@googlegroups.com X-Received: by 2002:a05:6808:238c:b0:459:9630:35b7 with SMTP id 5614622812f47-45c6200075fmr812300b6e.0.1768272900892; Mon, 12 Jan 2026 18:55:00 -0800 (PST) Received: by 2002:a05:6808:c25f:b0:455:f49f:e029 with SMTP id 5614622812f47-457b2ab7ac2msb6e; Mon, 12 Jan 2026 18:16:41 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWPkijrw/Q/9yTiPW9oiufAbMFsGBH0tkI/ee8KGYibOw+Pnj/gy79uRyGizrr5rnSyy/Hzw5JYIx4X@googlegroups.com X-Received: by 2002:a05:7022:6185:b0:11e:3e9:3e95 with SMTP id a92af1059eb24-1232b6427c7mr1670348c88.26.1768270600462; Mon, 12 Jan 2026 18:16:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768270600; cv=none; d=google.com; s=arc-20240605; b=TQKgXaJF8dmfPnAXkIFYazsXZgJU3r9CeR4MgrkZxwBYngIi4oTQ/FULBF0jQBKxnG Vmv4uB8gIKivtDTyfuQzWCL1W1dwx26g8laPBe9LTHniPSpAWKwfEP+5Kq1iObLR2uJU 1JFj8/BhkGyhC2Bovqm8iobtwFUcGU+BoSLRAlvnPbmy6ieWZZOSwjA6rffGXg4oAbig 9WkreB39+agLZNy0SNXwJnHvy/u61kPy9Dv8ZgBpo/GO7zKqncT9UvL5BTc/clzDyOPM Rc3ypmk1BAQWyV7ru/s9647FOvQo+QCYdeQ5vcl2ZAZfKzRkr/064mQcQuqin8oZGUiu fBRw== 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=ltNXgCSRv3WsKva+AhREGB880umZ0pmWO4xkZNqlbk0=; fh=CiP8UsUQxBdr2UMZDaaU43Eqk+RW6PQuV86f08s5oJM=; b=bRO1I6BxvfMfrMxn4l7E0tqqNzeXH2+3RABTWYwZ9NTOtMNWjynTkkzIQRA9zyxqd1 wWsXht1vy8yy54epaYlIwCPIupSMycVwPVdazZd1NI2LYAiQBlR4Kk/fBwLiilU13XgL fRW2Y7ct24/4wh9vtGz405hYiLoUFFqumTIuSa38iNPTxcs/OtLwE9EorNMp5n6ahHRS U449nJdV/+gOakI5oc5e+cRcuNI8c51141mRP6OUtP10mC6pLjffSJFwRBzKdlUmHGOt gSRcYN4Yt6JJbgZF4Bm/gArhxSH7X1czYpqml6dXJNHyIq4uavkXDcz7YC1dwArsU0+u vPcQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UBU6p2I5; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dl1-x1231.google.com (mail-dl1-x1231.google.com. [2607:f8b0:4864:20::1231]) by gmr-mx.google.com with ESMTPS id 5a478bee46e88-2b17173a905si652009eec.0.2026.01.12.18.16.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 18:16:40 -0800 (PST) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 as permitted sender) client-ip=2607:f8b0:4864:20::1231; Received: by mail-dl1-x1231.google.com with SMTP id a92af1059eb24-1220154725fso2875114c88.0 for ; Mon, 12 Jan 2026 18:16:40 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVAzIlQzaU0/NYcu8rVaca0SE7ZoPsf8aSf5pHCN1FDL9z8snnDyVmwfavo84heJn4TTTbjtfob8ipz@googlegroups.com X-Gm-Gg: AY/fxX5FkaA610I8+9wLGEYb6lc7DU/efAur1RkiJEjPWLNWvVhl6YnMutQgJYSNVgv xiynTcLzCaL9KSTvpHeYFGd0wUEFiAveyA21OpRJ2n2VYC1VXD+fleulD17oXVzaMflu6Gjb2b/ KEBD1stCwt7pveVhl1x2rwjtssWKT+a74ImD3o8qC49QYyVr7uj62I4QHdHPx6ezwV1D15tLPSe dtES+rR+tkXjWA5uZtD94sWHWXgocZrULd8b33fRJE3JPJmDJTZmH1towhm3f8QfUAJLP52CzsD Gv0+1XA= X-Received: by 2002:a05:7022:491:b0:119:e569:f86a with SMTP id a92af1059eb24-1232b5b6cd3mr1549189c88.7.1768270599077; Mon, 12 Jan 2026 18:16:39 -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: <33ffd6c4-6395-4f6c-a6e8-8b43220cdb00@mattcorallo.com> From: Antoine Riard Date: Tue, 13 Jan 2026 02:16:26 +0000 X-Gm-Features: AZwV_Qg-9VIsHJmbVqaKa-QZ8xinoyaDdgDEF6cSDpQojvph-Di3SnycBtN7wI0 Message-ID: Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 To: Matt Corallo Cc: Sjors Provoost , Bitcoin Development Mailing List , Antoine Poinsot Content-Type: multipart/alternative; boundary="000000000000ecc34206483b94e4" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UBU6p2I5; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::1231 as permitted sender) smtp.mailfrom=antoine.riard@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 (/) --000000000000ecc34206483b94e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 free. This is not like there have been a multitude of pooling protocols deployed 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. As 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: 45f28303770b376e2ae8f9e0072ae236d2b42aa4c84036f87ec9903a74a385b3 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. One > >> 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 as > 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 havin= g > 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 enforce= d > like any other block. So > there's relatively little rolling you can do until you get to the current > 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 this= . > > 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 headroo= m > 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 the= n > 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 an > 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 scriptS= ig > > 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 > parts, as does > > Stratum v2 [3], but presumably that's all done by the control board and > it makes > > sense to want to push rolling functionally into the ASIC silicon, where > even > > simple concatenation might be too involved - but updating bytes at know= n > > 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 advanta= ge > >> from the diminished computational work. I have not looked into CGminer > code > >> or one of its derivative forks, if there is an implemented option to d= o > 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 expect > to observe > > this behaviour in the wild just yet. The combination of rolling nVersio= n > > (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-limit= ations-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.m= d#511-standard-job > > [4] > https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=3Ds= jors > > [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 > > > > --=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/= CALZpt%2BFf_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40mail.gmail.com. --000000000000ecc34206483b94e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Corallo,

> Assuming some future change to str= atum v1/v2 to allow for this (which I think is basically a "never
&= gt; going to happen"), its worth noting that you can't just roll i= t for free.

This is not like there have been a multitude of pooling = protocols deployed in the past, all with
their awful long-polling mechan= isms and other tricks. Saying we should only consider stratum
v1/v2 in m= atters of consensus-design it can be a bit blindsighted imho. As of today b= lock
height, considering the situation where it's height-based lockt= ime, that would be 19-bit
that you could use as an extranonce, if my mea= surements are correct.

On the other hand, making the coinbase transa= ction with an always valid coinbase's nLocktime
transaction, this op= ens the door in terms of off-chain protocols and use-case design (e.g
pr= oof-of-work swap), where now you can use the consensus mandatory check of t= he coinbase
nLocktime's field as a novel building block primitive.
Best,
Antoine
OTS hash: 45f28303770b376e2ae8f9e0072ae236d2b42aa= 4c84036f87ec9903a74a385b3

Le=C2=A0jeu. 8 janv. 2026 = =C3=A0=C2=A016:36, 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://git= hub.com/bitcoin/bitcoin/blob/v30.1/src/consensus/tx_check.cpp#L47-L51 > [1] https://bitcoin.stackexchange.com/questions/= 35455/why-bother-having-limitations-on-bitcoin-coinbase-transaction-scripts= igs
> [2] https://github.com/bitcoin/bi= ps/blob/master/bip-0310.mediawiki
> [3] = https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#= 511-standard-job
> [4] https://delvin= gbitcoin.org/t/great-consensus-cleanup-revival/710/88?u=3Dsjors
> [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 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CALZpt%2BFf_L84d8LssCZWSBM0HPvfc5Z88jCGe0PBvExX7FxZaw%40ma= il.gmail.com.
--000000000000ecc34206483b94e4--