From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 08 Jan 2026 10:19:52 -0800 Received: from mail-ot1-f61.google.com ([209.85.210.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vdubv-0001Gc-VG for bitcoindev@gnusha.org; Thu, 08 Jan 2026 10:19:52 -0800 Received: by mail-ot1-f61.google.com with SMTP id 46e09a7af769-7cdaa241243sf251908a34.1 for ; Thu, 08 Jan 2026 10:19:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1767896386; cv=pass; d=google.com; s=arc-20240605; b=aYXmEqNZkeWnpnZrJ+aRG54GIvTU6xeK6Xmvm/V+hwrMv+EvDWxXRehB1+D1sxvLkQ pMc89oL/YLdueUtHHha6G26BvSZtE+5mKZux4z+wBmzjZd3fPYGg0UbnrTOmyIHxXOM+ Vw5LRr22TaUKu4oMi/MYnAl9yUuICEjYkMCTIqAfPc/wckIHT5DzdNbD4N2DYWWEAdpu aEcW79OBkEYlxuCkIJifHv8eEQ9Fazsy2mNTR95PgFrOvqPHb1Ou63g4eLOqtW1EG9li XkgcKLeB7uOIQzGMLPRn/mi5BJMG29Rn0VLx6uDjJFQ/3Ijc+lgS4SxLNyA+Dj3bG42W OYJg== 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:from:content-language :references:cc:to:subject:mime-version:date:message-id:sender :dkim-signature; bh=WjBz6iMD8JirGZapw11H4ywJCSWLnRJI4t1XQhfG66Y=; fh=2Pib1bKSYK+qUWJ0a8odyEbgBJ+SEJjPr2XjU6Dn348=; b=Yx+/0/c5PGOfNXDoePjynWDcAR+rls8LZcFDqUWSx8HjUWHIXw3TK+6Fed897jjGNg DLXXY4cSs1IqnTYiuzcE9WrdVz4p/XBwyAzumPFzP+vagHmcrVnHBKcvXvwwHYW82Z2H pdbAA7AKGdbEUuSyJANB0GxcpEX+ScQ+skegimzxV8isdz6tvDPEi62hLhyxZxQkAHwW nCv8OhBSZF7HnKb+drzHpnSq8qmgDKuLPdvjzbNDLAdm82zKPjqjl++VtQPewkLR9JHn kjnKOx01v8ssvzZaSEu6tWPf/7XAPZS5JIm6dXZs3cqwZ2TrwCVzdz9qQczYSiw5+FYw 6O8Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1767888062 header.b=Cxpscy7R; dkim=pass header.i=@clients.mail.as397444.net header.s=1767888064 header.b=UhTJfb8D; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767896386; x=1768501186; 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:from:content-language:references:cc :to:subject:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=WjBz6iMD8JirGZapw11H4ywJCSWLnRJI4t1XQhfG66Y=; b=wqKUYKjvLkJeqQjC2L+NjWOaRQ3unmFxIJbuVFcCdaWvikXZNg6LOOl8pexO6ucjRD q5T5r0PoRrCgJVWGOAKWMnWwhdOUprkIMGs8BskxA+h3rHHxIr71oI7LkSRtf0KIecZ6 JBU+nP+su6M4NCCjBKZD8UujAEheg+O03GRRu9INT4cB2K6h3cJ9aO/OH1HFjt14ezvq 8IVP6tiCxY+IGGwTBBuz7ZF/4nt17kZjIbyQs5ok30KakAzYCmnZaUGiO+sllBzbXRtT M9dWeujobM+7yaP9DAUxXr9IFWniIJP+nzWGR1DpljoIRyoI144O0aPBfs/FKfYRx1pB R97g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767896386; x=1768501186; 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:from:content-language:references:cc :to:subject:mime-version:date:message-id:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=WjBz6iMD8JirGZapw11H4ywJCSWLnRJI4t1XQhfG66Y=; b=n96bMNImDDt+TsWLB/qA5eXP8F8uhtk1QvwACtMwqmLJS/SShNlNWhZ+rNhDd3mbu2 bv6ZJ3LmpKjSf8q8f98T4cLSlMcXiHPMSfRB/QT6cFcC0gW+qegYbG5GrTFSr1vyLpXk YnMYeINz/gFWVgi84pGPF9Cow6rHiN9P6sfllZzSYJPGZACF8EJmBhE/xVYMfOJnoSWi vVHs9z0ZHynk1ffOrmLlKVTnt/Ehc5L8AHgCT9YLzBTfMjoR9GG+QLqudCO80ESg15h5 42igX8cWseap4ViFJ9SxNW5ShuGriw82M4Bj/FZxZnNE/EmjfGIalTbTuXwOVrhr4nRe eNUA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXrGd1x+NIaGUPQEJhmOV64k2Bf0U909dpXyEXMGK8lf5DA7KacI/ZgcnXJjtKbctP3dT7PRqqKECh0@gnusha.org X-Gm-Message-State: AOJu0YwzwVYgZJ2xdf5PlK95/Is8Vw6GiLvefYUH7MkkhFXo2JmXPeBb Z774Vxo28etQJMdnfzsZJ712xXLjN0KXKhdmlFeZmJTe73Zs261gbWmc X-Google-Smtp-Source: AGHT+IEouPrfL1/Vf/nKq2Sr6oj+LeU9Urs73CHyKDbzxC916Dl06OjgOxNWSQTaj4V2NtbSK/1IpA== X-Received: by 2002:a05:6870:9122:b0:3e7:d329:aca1 with SMTP id 586e51a60fabf-3ffc091875bmr3247832fac.2.1767896385405; Thu, 08 Jan 2026 10:19:45 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWajEwHlfbamGrJ8+r5Zx65EFdRHUl49gf0J27c+ORnkfQ==" Received: by 2002:a05:6870:b28a:b0:3ff:9e43:57c1 with SMTP id 586e51a60fabf-3ff9e436773ls2184067fac.2.-pod-prod-09-us; Thu, 08 Jan 2026 10:19:41 -0800 (PST) X-Received: by 2002:a05:6808:1b1f:b0:442:1d6:dfc3 with SMTP id 5614622812f47-45a6bcd42d6mr3152217b6e.10.1767896381690; Thu, 08 Jan 2026 10:19:41 -0800 (PST) Received: by 2002:a05:6808:4a59:20b0:44f:fe66:38a2 with SMTP id 5614622812f47-457b2896d33msb6e; Thu, 8 Jan 2026 08:36:57 -0800 (PST) X-Received: by 2002:a05:6a21:9990:b0:32d:b925:4a8 with SMTP id adf61e73a8af0-3898f8f56d5mr6416862637.3.1767890213819; Thu, 08 Jan 2026 08:36:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1767890213; cv=none; d=google.com; s=arc-20240605; b=ToqlBz36XqqtY89fWeQzmaHeJAaxU2O7a9lotvGrBgpFjjRSEJ3jrNntHhT2urDA4H t1Cj/P0zItESDqntRUKb7vAcVCCICEuuIeRzS1Odp2WW2EQZfUP8GlzSTMTyNFqhbG5L mHb/pAYSHH2ueRnxb3XGI/hcz0MuxygPG1ACEqc47JkZsr0rGEgYOeUve1lJRY7PuEnR v4b51WhCg/9U3SLCC8blhKf1cGIMIQ7pNNYu6pi/JH33sJer0qSYI9Wv2QjrVxvNBdP/ 767rGjI+f5rEvyqe/jQBQJkoqzTPgQTNPKW401JNWI86Lnohe6/NvboYSaGeYCfT57mc rbbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=OEJp4s7DrAysTLqHPMSqhslnpMWW60iuAyaGhJDx7p8=; fh=eIAf69PAcuxoniiYNg0EwnK1wa22u01kpHv8GcVL1I8=; b=BawAI7UjYp/VdgKYDeqAg+eq8drjrlka0spbuNxjla1n5NXAFE2iU4xETHExCcKOrk g0ujcy3Jt8VHVHgmjb+OzwNy61CceMX27Ot9rcX6CY/SbgiHp4cORQSV21TfTL/7j+L/ 1zHk+nrW5OpfjpUPvPpzMGLwlcdvPXxderqTyGZMX90RJ3u+VS0W8PGvWt32RmQJxwG6 A+SV374BZJy3rTKIp/F3qVIWvWLHbk9aGMCbkdpnRsAcqkS4UyHdNudHDn3/N353TRZn 6Cmol1w93axmcIrJqeRoGtQGZiEBtKuxDSfovwqe3Gsm64P3wBQEM43/OVe9pWuSjQyg pEVA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1767888062 header.b=Cxpscy7R; dkim=pass header.i=@clients.mail.as397444.net header.s=1767888064 header.b=UhTJfb8D; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c4d93b595bfsi211713a12.4.2026.01.08.08.36.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jan 2026 08:36:53 -0800 (PST) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1vdt0E-00000001uXR-35RQ; Thu, 08 Jan 2026 16:36:51 +0000 Message-ID: <33ffd6c4-6395-4f6c-a6e8-8b43220cdb00@mattcorallo.com> Date: Thu, 8 Jan 2026 11:36:50 -0500 MIME-Version: 1.0 Subject: Re: [bitcoindev] Addressing remaining points on BIP 54 To: Sjors Provoost , Antoine Riard Cc: Bitcoin Development Mailing List , Antoine Poinsot References: <05f5b0ee-b487-4733-9860-ac0705b6b901n@googlegroups.com> <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> Content-Language: en-US From: Matt Corallo In-Reply-To: <9C946151-D6DD-4CB7-B524-15FD9F625D9D@sprovoost.nl> Content-Type: text/plain; charset="UTF-8"; format=flowed X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1767888062 header.b=Cxpscy7R; dkim=pass header.i=@clients.mail.as397444.net header.s=1767888064 header.b=UhTJfb8D; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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.8 (/) 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 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 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 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 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 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 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 advantage >> 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 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.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-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=sjors > [5] https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.notify > > * = 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/33ffd6c4-6395-4f6c-a6e8-8b43220cdb00%40mattcorallo.com.