Foundry polls mining clients on BIP-110 signaling

July 18 (Crypto-News.Net) – Foundry USA Pool is asking its mining clients how the pool should signal on BIP-110, a proposed temporary Bitcoin soft fork that would restrict specified data-carrying transaction forms if activated.

According to Foundry USA Pool’s public resource page, clients who are ready to vote are directed to use a link in their email to access a voting form. The page says the voting window will remain open through the signaling-window close date, ahead of block 961,632.

Foundry Poll Is Pool-Specific

The Foundry poll is a client consultation for one mining pool. It is not a network-wide Bitcoin vote, and it does not show that BIP-110 has been adopted, locked in or activated.

Foundry’s role matters because mining pools coordinate block production for participating miners. Crypto-News.Net’s explainer on Bitcoin mining and mining pools covers how miners and pools participate in block creation.

In a July 18 verification snapshot, mempool.space’s 1-week pool table listed Foundry USA with 294 of 1,001 attributed blocks, or 29.37%. That is observed attributed block share for a moving window, not exact hashrate.

What BIP-110 Would Do

The canonical BIP-110 specification lists the proposal as Status: Complete, Type: Specification and Layer: Consensus. Complete describes the document’s status only. It does not mean the Bitcoin network has accepted the proposal.

BIP-110 would temporarily invalidate several transaction forms during its active period if enforced. The rules would restrict new output scriptPubKeys over 34 bytes and limit OP_RETURN outputs to 83 bytes. They would also restrict large pushdata and witness items. UTXOs created before activation height would be grandfathered.

Under the BIP’s deployment design, the miner-signaling threshold is 1109 of 2016 blocks, or 55%. The mandatory signaling window would run from blocks 961,632 through 963,647, with lock-in no later than block 963,648 if the BIP’s rules apply.

Tradeoffs and Counterpoints

The BIP’s own tradeoff section says the proposal could constrain advanced smart-contracting designs such as BitVM-like uses. It also says other soft-fork upgrade hooks would be unavailable during the temporary period, and some Miniscript or OP_IF cases could be affected.

Jameson Lopp, whose critique is linked by Foundry as a counterpoint, argued that BIP-110 carries chain-split risk and wallet edge-case risk in his guide to the proposal. He also raised governance concerns and future-innovation constraints. Lopp argued that existing block-space limits and fee markets already constrain unwanted transaction data.

A separate July 18 disclosure from Dathon Pwn reported a regtest reproduction of a late-upgrade chainstate validation gap against BIP-110-enforcing Bitcoin Knots v29.3.knots20260508 software. Crypto-News.Net located no maintainer acknowledgement or independent reproduction of the BlockSlop report.

Foundry’s voting result and final signaling position are unknown. The exact boundary remains block 961,632.

Reporting by Zoran Spirkovski. Editing by Crypto-News.Net.

Sources

Foundry USA Pool – Confirms client voting-form access and the block 961,632 boundary language.
https://services.foundrydigital.com/bip-110_resources

BIP-110 specification – Supports the document status, proposed rules, UTXO grandfathering, 55% threshold and signaling-window blocks.
https://bips.dev/110/

mempool.space mining pool API – Supports observed attributed block share for Foundry USA in the 1-week pool table.
https://mempool.space/api/v1/mining/pools/1w

Jameson Lopp – Provides named counterarguments linked by Foundry as a counterpoint.
https://blog.lopp.net/a-laymans-guide-to-bip-110/

BlockSlop – Supports the attributed July 18 Dathon Pwn regtest reproduction report and its stated scope limits.
https://blockslop.dev/