From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 12 Jan 2026 17:50:47 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vfTYU-0001gA-7J for bitcoindev@gnusha.org; Mon, 12 Jan 2026 17:50:47 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-3f9e3c7de14sf13805547fac.3 for ; Mon, 12 Jan 2026 17:50:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1768269040; cv=pass; d=google.com; s=arc-20240605; b=LTKPhhmbrUJ+XohqvjSifn9VkhKSS2J+j1Czc55sRS+5GvRA1TJZ3/pJbx3HfZnK/p 7M+PlgGQGlgXuaI+MF8q6AhLQvBD4ZqjuWJj33LAC9fumN0KYTjUfS2+/JbH6iPAL22/ GFLvXno8/+CNvLU8huyfUyBuD3TTiVUXe/nTVyPB8sInNV4Jz7qaxKG3rvs8d2o69dRg ezGRQp/v6nih1WPgUXPt+kXzc9UZNlFwc7fGp+/9NvTLbKnrQRPUEe30wYZX4Fe6KT22 1VdVhlDv8X/8V0FS5t9vS0apQkYyXx9I/pCnEwAjYs8/FTcGubaayeWVQj0hwcgkUMYN SnYw== 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=brPPdAY6FkjqBSYb6tAH85gWSUgGOQfq3Bm2uGGllqU=; fh=VlAKtdiGzSp38n2t8V7dc8QoHjiOYIzEJskX9Um438k=; b=QP4KlkxMXxBbY6Bho1i/6ek0J8WtEOlTFmvSFLJtoH/wvyAx04MOr0LZDqOZZNCVeO KKSdtbRAMGCerSvuXu5w7ywdJ+X22ecvdbi4LXQX3lFIQeRrFePXO6tp/nz9DivdELUl ob/Fh0lWXnIFf7L3ql+tyZc9hav0cl1NToRQKnt2V1lurZ3TmsrnLsi9hWShC7nbE7Zn SGM6thJOaVGfMnHlk6B4+rL0G2lMKbke4AuscBlohOifrq/Xw86n6dHtHgL7LsEKbGLo lGiyhGJdfp7/SAW1JPLonT01zfhgft/psthRYH48QPRo1HQSxDKaZ24PHddp7jSRH8TF qS0Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e475AXNA; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e 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=1768269040; x=1768873840; 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=brPPdAY6FkjqBSYb6tAH85gWSUgGOQfq3Bm2uGGllqU=; b=D5uJuU+lVy++8zlTRf9Id/tJ4i3JK79rytqJBkxBxbtMEPKvB7Qny1ZXKZIzAm95QB jWloJL69vLdTUpKfmmm3FfenkgPYGEVsXm0llJ5CH/cCrlD65RM1q8tnwk0KEVdKRWr5 nfgrGXj75kG7KAbOKZ8I7bMkZSl2hRs7wO7NlVCS/eB3OEj8MjN9HsQ4K+72GfrPaHSR ceiwpAQSNasAcBIRsfRU0jB3P2qM2KthxKMzKIEpJuHNFflDm5z1nNAATkpkjwJA6P59 BvHwFGFmwDA4AFwpYON475uXaI3nvtyqN2Psu24G/pR5svRHNicoeX3fImargkDwrb23 FaHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768269040; x=1768873840; 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=brPPdAY6FkjqBSYb6tAH85gWSUgGOQfq3Bm2uGGllqU=; b=CkhC8+K9e3NETJiS9Aq7ySbm/0XCpKwcEkhYt+pfF2sJWNzEk1LCYQ8Ctbqkr7xePS BlVlmT9hjmxv0nYa0bl44bkc/Dlv16m06QET6ZTFUXsBPodNfcspWmmFjJnikFKLfgtU W+Q5vWTeKmcpCpH4boXdhe2z9hziyHqEqOrMj8gN6mT43YMGSFRxymQYKxtGkLDxM70b peJkVojrQuU0/4bzjfdLPZoWdbm7XNf8D+VnZqCqW9dAwDY8xzPOacQ4LBPJem8wZv4M SFEhmI3QbluxmCba88VVsW+OKIKhWIAZhvdJABbGqvjR5U/3J91lytXTr0TnBhLZeoR1 /K7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768269040; x=1768873840; 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=brPPdAY6FkjqBSYb6tAH85gWSUgGOQfq3Bm2uGGllqU=; b=pphO382pIT+WcRGVXlXwRbeEneYR4R59fV3ncLM1oW5R2jcozNGBnWplRiNNKzlA4A hLctCF0efB71qbr6lxfGcrpJiD70cVIE8wvsO4Yi6Cl5tR5wLEePjqMzFXhhO/QKvUQK iG/4ErCK7Tf9/FN1YqQn0NPy7NAu2wA6Vc4Vi/dwNrxK3D5SsergaR0J7rF98y063Xsq ojEK3ONrJKicQyfnBQS6dmwG54it1y6WmO4q8kRwlx9L+nTrUqiT/MoBG3AKRILXFgLA ud+gnEIlqMclKjwGKnR6EOmVHed1tT0xXrL5EwvCCf2ivNoLGwDPmElk7Rd+RdXt0hK3 J6cg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXHsPLi9lCVwtmGIQyQ4NrsQBv9I3T6H9ReyVWzvGhns7jxq2ofYGUwhsCl6KZEJgAQpaItuXRnByzP@gnusha.org X-Gm-Message-State: AOJu0Yx1abTJUsYpXBwseb4cVdV9FLBnj+QKpdx9jViPPvZZBIFbjaCS 9ZaLiGajA2hmBLsuSSB0cmax6IEJYnEcFn2dAjGZfJjbQprq9zef5xha X-Google-Smtp-Source: AGHT+IHBtnA3RUGdBQ8/f6YwvmGSL7mPBZr4932OS+AIMcd6uNU6UPsPqM4ZVh90W7wuYspt3NRr6w== X-Received: by 2002:a05:6820:f032:b0:659:9a49:8faf with SMTP id 006d021491bc7-65f54f73be8mr10020960eaf.40.1768269039129; Mon, 12 Jan 2026 17:50:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GaVeeEnBsq5OoYgrkuFzx5eGJ0OQjdBsIJoZaXQOIrrg==" Received: by 2002:a4a:a7c8:0:b0:657:5773:7b1d with SMTP id 006d021491bc7-65f64e64945ls1453116eaf.2.-pod-prod-05-us; Mon, 12 Jan 2026 17:50:34 -0800 (PST) X-Received: by 2002:a05:6808:c1aa:b0:441:d05b:abbe with SMTP id 5614622812f47-45a6bd39162mr9900729b6e.5.1768269034660; Mon, 12 Jan 2026 17:50:34 -0800 (PST) Received: by 2002:a05:6808:8188:10b0:450:c180:fd79 with SMTP id 5614622812f47-457b2bb0fcfmsb6e; Mon, 12 Jan 2026 17:49:41 -0800 (PST) X-Received: by 2002:a05:6a20:7f9c:b0:364:134a:2bc1 with SMTP id adf61e73a8af0-3898f8cb991mr17971984637.18.1768268979886; Mon, 12 Jan 2026 17:49:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768268979; cv=none; d=google.com; s=arc-20240605; b=gBRqVgm3sB149iYFcCQLVvXYEeQKPjvI3XHCR6cmTy4g62XbzG/VUPxGVOi5zaXUzi 08Q6Iq0D/eU+td2btDTOkZ4+1dBn3DPm3AL0xE43WZ17QPM6AY1PZamF9X+TFocnxczg epvTFry/nYpQe1eQSW1nP+/rMGHGCXHaDNaAhaRNOUIGX+lAKAIjL/2SCKd4OFrMWQOf 0m4cdiCjMMSfX6xi8QAWNjEjM4mgf66jah6rTw1RQQJ9ACTaUrn7iYwCd6uL+YcvKlyu QO25fXkJqxZB9z3O1aSAtqjzP6x2LC9YbfwnLj12DZa6XjccGvXAcixOHHwvuRzEpXEg koEg== 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=SwaGreV2xgw3BT1NxyWZ84iyNYOIhb1Kj6l/xwUu8fI=; fh=QJiw3ONYfCvwxwKGd3QvmI4L+ATTnjhAo7b02tnArGw=; b=g9CX6AM0ZuxieXmBDAnyNczFMcdAkgjiN/GQndu6W+ucyKEim4ooudjP9UaWNshg0D 9ZQfjooyshV4JjLFAoO/mJdaUbLWCbzj3EMjxkBszyGk970BULJLQzTm9m8e/B6xTvqK sAtlhHbFtDag7+HoBs/u7vGKz2gnzUxKVHQH9qxaAO1JD/flCHGV/c3qYFSsVwvXYMCG ONkXN2ZgC/tuZalbqRXNtjqSCc3WvFNKQodpwFU9la1Uh+oxdDf/wrI8H48nvncG+t6Y c4TanaYfjMKvCJTd/PZRIhTtfUc8qpl15iB9pfUcWs3IZ97AdI79/Z73nEa/r3EejGOK SqNQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e475AXNA; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e 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-x122e.google.com (mail-dl1-x122e.google.com. [2607:f8b0:4864:20::122e]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c4d8ce6c0dfsi562109a12.1.2026.01.12.17.49.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 17:49:39 -0800 (PST) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e as permitted sender) client-ip=2607:f8b0:4864:20::122e; Received: by mail-dl1-x122e.google.com with SMTP id a92af1059eb24-11f1fb91996so11562179c88.1 for ; Mon, 12 Jan 2026 17:49:39 -0800 (PST) X-Gm-Gg: AY/fxX48U4IJPwIEAmsCckhKmjNxVkjLq6TTA4GjOd49LOVyut9XOHC+FudwTDeQxx2 3eToJfYzSbbCkQi7Hplw1A+T2+yomYCOXFtnSKei6nhEHrAR+KAfwPHV6Qf2u0oQBJ2BNvGk4ER dmkvHbfU2Vqk/WnyfKkPsdyZXb+sSm7nWAdJx11b3kZD30jWKeZotspI0NQG8vCwPiZYhS5grtz z/cAqmACHC2pwFzJXSrRpyFpqVWIvvh0r4c72XeuzNREF0jUtugGUQY8SsKbWlyx6Fnyc2u X-Received: by 2002:a05:7022:6983:b0:11d:f890:6751 with SMTP id a92af1059eb24-121f8ab9ce0mr19777463c88.10.1768268978913; Mon, 12 Jan 2026 17:49:38 -0800 (PST) MIME-Version: 1.0 References: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> In-Reply-To: <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> From: Antoine Riard Date: Tue, 13 Jan 2026 01:49:26 +0000 X-Gm-Features: AZwV_Qi7LHSx3ouVi41ahpxvLPgoQq8K_fucHFVcJsJf4ToDFfF5iIC_AgDOp-Q Message-ID: Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 To: Sjors Provoost Cc: Bitcoin Development Mailing List , Antoine Poinsot Content-Type: multipart/alternative; boundary="0000000000005b075a06483b3465" 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=e475AXNA; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::122e 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 (/) --0000000000005b075a06483b3465 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sjors, Thanks for the reminder that the coinbase transaction has a 100 bytes limit, checked IsCoinbase(), but I didn't CheckTransaction() again. So with a 100 bytes limit, there are still 2^100 extra permutations in addition to the 128 bits already available from the nonce, and the bits from the version fields. It is true that the coinbase nLocktime is a fixed-size field, so an ASIC ca= n roll it without having it ot understand anything about serialization, while on the other hand the scriptSig is as you're noting variable-length (well you can make assumptions on the var_int fixed-size). I don't think that that whatever your ASIC design, the chip has to be aware of the serialization subtleties, this can be done at the proxy-level, and you just feed an unified iterable bits field (version + scriptSig + coinbase, whatever you use as an extranonce). I see the idea of appending a 0-sat OP_RETURN output with padding so a 4-byte nonce is fitting in the data payload of the OP_RETURN. But I don't see how you avoid the unserialization problem for the proxy of knowing the OP_RETUR= N data payload selected size (--I guess register loads and CPU cycles saved at the architecture levels for the unser buffer mem allocation can be wins for the proxy). So it might be easier to implement, but not necessarily faster. Never built an ASIC, but to have studied instruction level architecture, if you wish optimal performance the question starts to be the size of you're high-level cache (the ones the nearest of your roll-and-hash-logic) and what is the byte-length words those caches are working on. Unless you're iterating on 4 MB words fractional power of 2 of it, but I don't think so. I'm not aware this behaviour is done in the wild, but in theory if you can serialize / unserialize on fixed-size data fields for the proxy, it's faste= r (just one less one memory allocator call...). Without digging more on the necessities for current 280 TH/s, this can be fine for now to just roll the nVersion header field which is a fixed-size too, though I do think Luke's concern of letting the coinbase as a reserved field for now is not without ground (of course the nLocktime can be valid today, but what is the worthiness as the nSequence can be set to disable it, i.e IsFinal()'s semantic). Best, Antoine OTS hash: 6c1f83a60642ef43c911dd57b4b9aaf084cf80445d0af72b1f92f910581f6ead Le jeu. 8 janv. 2026 =C3=A0 08:30, Sjors Provoost a = =C3=A9crit : > 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 t= o > 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. > > The scriptSig OTOH is variable length, so it needs to read the length byt= e > 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 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 scriptSig > 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 i= t > makes > sense to want to push rolling functionally into the ASIC silicon, where > even > simple concatenation might be too involved - but updating bytes at known > 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 advantag= e > > 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 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 expect t= o > observe > this behaviour in the wild just yet. The combination of rolling nVersion > (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 an= y > 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%2BFyPWsbvNOo3jpSoBR08a-LXoZi40yaP5VFEaKm%3DNYRPw%40mail.gmail.com. --0000000000005b075a06483b3465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sjors,

Thanks for the reminder that the coinbase= transaction has a 100 bytes
limit, checked IsCoinbase(), but I didn'= ;t CheckTransaction() again. So with
a 100 bytes limit, there are still = 2^100 extra permutations in addition to the
128 bits already available f= rom the nonce, and the bits from the version fields.

It is true that= the coinbase nLocktime is a fixed-size field, so an ASIC can
roll it wi= thout having it ot understand anything about serialization, while on
the= other hand the scriptSig is as you're noting variable-length (well you= can
make assumptions on the var_int fixed-size). I don't think that= that whatever
your ASIC design, the chip has to be aware of the seriali= zation subtleties,
this can be done at the proxy-level, and you just fee= d an unified iterable
bits field (version + scriptSig + coinbase, whatev= er you use as an extranonce).

I see the idea of appending a 0-sat OP= _RETURN output with padding so a 4-byte
nonce is fitting in the data pay= load of the OP_RETURN. But I don't see how
you avoid the unserializa= tion problem for the proxy of knowing the OP_RETURN
data payload selecte= d size (--I guess register loads and CPU cycles saved
at the architectur= e levels for the unser buffer mem allocation can be wins
for the proxy).= So it might be easier to implement, but not necessarily faster.

Nev= er built an ASIC, but to have studied instruction level architecture, if yo= u
wish optimal performance the question starts to be the size of you'= ;re high-level
cache (the ones the nearest of your roll-and-hash-logic) = and what is the byte-length
words those caches are working on. Unless yo= u're iterating on 4 MB words fractional
power of 2 of it, but I don&= #39;t think so.

I'm not aware this behaviour is done in the wild= , but in theory if you can
serialize / unserialize on fixed-size data fi= elds for the proxy, it's faster
(just one less one memory allocator = call...).

Without digging more on the necessities for current 280 TH= /s, this can be fine for
now to just roll the nVersion header field whic= h is a fixed-size too, though I do think
Luke's concern of letting t= he coinbase as a reserved field for now is not without ground
(of course= the nLocktime can be valid today, but what is the worthiness as the nSeque= nce
can be set to disable it, i.e IsFinal()'s semantic).

Best= ,
Antoine
OTS hash: 6c1f83a60642ef43c911dd57b4b9aaf084cf80445d0af72b1= f92f910581f6ead

<= div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 8 janv. 2026 =C3=A0=C2=A0= 08:30, Sjors Provoost <sjors@sprov= oost.nl> a =C3=A9crit=C2=A0:
Hello Riard,

> Thanks for the update. If I'm understanding correctly Luke's c= oncern,
> 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<= br> > 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<= br> why [1].

The main issue I see is complexity of implementation. The nLockTime is alwa= ys
the last 4 bytes of a transaction, so an ASIC can roll it without having to=
understand anything about serialisation.

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 al= so
needs to ensure those 4 bytes are pre-initialised*.

The approach suggested by Towns [4] of appending a 0-sat OP_RETURN output w= ith
padding so a 4-byte nonce lands in the final 64-byte SHA256 chunk is probab= ly
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 ASI= C
because it can update a fixed 4-byte field at a known offset from the end,<= br> 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 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 eve= n
simple concatenation might be too involved - but updating bytes at known 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 a= ll 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 nVersion (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.c= om/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-scriptsigs
[2] https://github.com/bitcoin/bips/bl= ob/master/bip-0310.mediawiki
[3] https= ://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#511-s= tandard-job
[4] https://delvingbitc= oin.org/t/great-consensus-cleanup-revival/710/88?u=3Dsjors
[5] https://en.bitcoin.it/wiki/Strat= um_mining_protocol#mining.notify

* =3D otherwise the ASIC needs to know how to extend it, know that it can&#= 39;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 &= 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%2BFyPWsbvNOo3jpSoBR08a-LXoZi40yaP5VFEaKm%3DNYRPw%= 40mail.gmail.com.
--0000000000005b075a06483b3465--