Market snapshot · ↗Bitcoin price$77,735Network hashrate936 EH/sDifficulty127.45 T

Pools & payouts

Stratum V2 1.13.0 fixes mining-job handling behind the pool connection

Source report: 2026-11-04 · Editorial analysis published: 2026-11-09

The November 4 library release addresses coinbase construction, work credit and message buffers. It is a pool-software update, not a universal ASIC firmware download.

Original explanation: witness-related coinbase fields follow the block template. The contributor’s demonstration used a private regtest network.
Original explanation: witness-related coinbase fields follow the block template. The contributor’s demonstration used a private regtest network. ASIC.tools · original explanation · CC BY 4.0

The pool's work order matters as much as a connection

Stratum V2's reference implementation published version 1.13.0 on November 4 with fixes to the software that prepares mining jobs, checks submitted work and reads network messages. For an ordinary miner, the significance is straightforward: a device being connected and calculating does not by itself prove that the job it received can become an accepted Bitcoin block. The infrastructure preparing and validating that job also has to be correct.

This release is a collection of software libraries used by applications, not a universal firmware image for every ASIC. A pool or software operator must integrate the relevant versions before a customer's route benefits. The notes close three audit trackers covering buffers, encoding and message framing, and make incompatible version changes to the modified published components except the Noise component's added re-export. A release announcement alone is not evidence that a named commercial pool has deployed it.

A block's reward transaction needs the right structure

One fix concerns the coinbase transaction: the first transaction in a Bitcoin block, which creates the subsidy and assigns collected transaction fees. Here, coinbase is a Bitcoin technical term, not the exchange. The library previously could add witness-related fields, carrying extra transaction-verification data, even when the supplied block template did not contain the corresponding witness commitment. The new handling adds those fields only when the template calls for them.

The contributor demonstrates the consequence with Bitcoin Core v29 in regtest, a private testing network: the affected block was rejected with unexpected-witness before the change and accepted with the fix. That is a concrete correctness test, not a disclosure of a measured loss at a live pool. The same change refuses to strip witness data from a coinbase with more than one input. An operator needs the actual template and validation result to diagnose a failure, rather than assuming every rejected job has this cause.

Original explanation of work credit: the network target and job target can differ on test networks; credit is limited to demonstrated work.
Original explanation of work credit: the network target and job target can differ on test networks; credit is limited to demonstrated work. ASIC.tools · original explanation · CC BY 4.0

Work credit must follow what the hash proves

Another change limits the work credited to a block-finding share to the difficulty its hash really demonstrates. A share is a submitted proof of participation; a block-finding share also satisfies the network's block target. On testing networks, the network target can be easier than the job's share target. Crediting the whole job difficulty in that case could overstate the submitted work, according to the linked developer explanation.

The fix caps that credit at the proven amount. The author says blocks whose hashes also meet the job target are unaffected, and block propagation remains unchanged. It is therefore not an announcement that every miner's payout formula changed or that an ordinary accepted share earns less. For a reader checking a pool account, local share counts, credited difficulty and the pool's actual payout rules should be compared as separate quantities.

Read messages within the size they declare

The release also changes how message frames are handled. A frame is the envelope around a piece of network data, carrying information about its size. Encoders now refuse data larger than the header can describe, and reject a message that serializes to fewer bytes than its header declares. The linked change explains that this avoids sending an old tail left in the buffer. Think of checking an envelope's stated contents before handing it onward.

Encrypted messages are now decrypted a header and chunk at a time as the bytes arrive, rather than first holding the whole encrypted payload, which could reach 16 MiB. A chunk that fails authentication causes an error before the rest is read. Buffer changes also keep memory alive while a slice refers to it and distinguish reserving space from confirming bytes written. These are specific implementation repairs; the notes do not establish an attack at a particular pool or a universal bandwidth saving. The same release also checks numeric and length fields earlier: serialized F32 numeric fields (32-bit floating-point numbers) reject NaN, infinity and negative numbers, and values in TLV records (type, length and value) cannot exceed what their length field can declare. These checks stop malformed data at the message boundary. They do not identify who sent a bad message or establish a particular real-world incident.

Original message diagram: encoded length must match the header, while encrypted chunks are authenticated as they arrive.
Original message diagram: encoded length must match the header, while encrypted chunks are authenticated as they arrive. ASIC.tools · original explanation · CC BY 4.0

Applications can supply a prepared job

Server channels can now accept prebuilt mining jobs supplied by an application and activate a future job without a Template Distribution message. In plain terms, the application has another supported route for handing the communication layer an already prepared work order. Standard jobs retain their coinbase bytes. This is a capability for software builders; it does not automatically give every connected home miner a new job-selection control.

Other job fixes prevent duplicated coinbase outputs when standard work comes from a group channel, release replaced job resources when an identifier is reused, and reject a target above the channel's maximum. Field names were also aligned with the specification. The release explicitly says the renaming changes nothing on the wire: code using the library may need adaptation even though that rename does not create a new network-message format. The distinction matters when planning an integration.

The practical question is which software is actually used

A pool operator can follow the relevant library versions through its application, then check a full job cycle: job creation, coinbase construction, share checking, block submission and normal reconnection. The value of a correctness fix appears in those paths, not in an ASIC's advertised terahashes. A miner using a hosted pool can ask which implementation serves the connection and whether the relevant fixes have reached it. Installing an unrelated device firmware does not answer that question.

ASIC.tools reviewed the dated release and the linked source changes; it did not run the libraries or audit a commercial pool. The update provides concrete fixes and developer test evidence, while pool deployment and any effect on an individual account remain separate facts to establish. Preserve a rejected job's timestamp and error with the pool's support record when investigating. No quantified extra Bitcoin income, hardware acceleration or electricity saving is established by version 1.13.0 itself.

Source: Stratum V2 / official source changes ↗ · Coinbase witness fix and regtest result ↗ · Proof-based work-credit fix ↗ · Bounded frames and incremental decryption ↗ · Prebuilt server-channel jobs ↗ · Message-field rename scope ↗

Mining calculator ↗

More in this section