Bitcoin miners sporadically produce stale blocks: valid blocks or valid block\nheaders that do not become part of the node's active chain. This BIP defines a\nnew optional peer-to-peer (P2P) staletip message for announcing recent stale\nchain tips to peers. The announcement includes the stale branch headers and\nwhether the sender is willing to serve corresponding stale block data.
Stale blocks are a potentially useful signal about the health of the network's\nblock-relay layer. The rate at which they occur tracks how quickly new blocks\nreach the rest of the miners, and an elevated rate can be a symptom of a range\nof network-related problems – degraded or congested propagation, network\npartitions, or adversarial mining behavior such as selfish mining.
\nAn added benefit is that when a stale block has the same cumulative proof of\nwork as the active tip, the current active tip may be re-orged out in favor of a\nchild of the stale block; having the block already downloaded (and possibly already\nvalidated) makes the reorg faster. The contents of stale blocks additionally\nreveal differences in block-creation policy between mining pools.
\nThese benefits are not essential to the operation of the Bitcoin network, so\nthis is proposed as an optional feature, with low performance demands and strict\nresource limits.
\nThe key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",\n"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as\ndescribed in RFC 2119.
\nFor the purposes of this document, "active chain" means the chain that a node\nhas selected as its current best chain. A "stale branch" is a sequence of valid\nheaders that descends from a known block but whose tip is not on the node's\nactive chain. The "stale tip" is the last header in that branch.
\nstaletip MessageThe staletip P2P message has the ASCII message type staletip and the\nfollowing payload:
| Type | \nName | \nDescription | \n
|---|---|---|
uint256 | \nfork_point | \nThe block hash used as the previous block hash of the first compressed header | \n
vector of CompressedHeader | \nheaders | \nThe headers forming a single stale branch after fork_point, in chain order | \n
bool | \nhave_block | \nWhether the sender is willing to serve block data for the stale branch | \n
The fork_point MUST be known by the receiver and MUST be the predecessor of\nthe first reconstructed header. In the common case, it is the last common block\nbefore the stale branch diverges from the receiver's active chain. It MAY be a\nlater known stale-branch header if both peers are expected to already know that\nheader; in that case the headers vector only contains the unknown suffix.
The headers field MUST describe a single linear branch. The first header\nimmediately follows fork_point, and each subsequent header immediately\nfollows the preceding header. The final header is the stale tip. A separate\nstaletip message is required for each competing branch that the sender\nchooses to announce.
The headers vector is serialized as normal: encode the length of the vector as\na 1, 3, 5 or 9 byte CompactSize, then serialize each member of the vector.\nOnly minimally-encoded CompactSize values are supported.
The bool serialization is a single byte \\x00 for false, and a single byte\n\\x01 for true. Other encodings are malformed.
have_block set to true means the sender currently has, and is willing to\nserve through normal block download mechanisms, the full block data for the\nstale tip, which is the final header in this staletip message. A sender that\nsets have_block to true SHOULD additionally be willing to serve earlier\nblocks on the announced stale branch that it has. have_block set to false\nmakes no claim about stale-branch block-data availability. A sender SHOULD NOT\nset have_block to true unless it expects a request for the stale tip block to\nsucceed.
Because stale tips are very rare, this BIP does not reserve a 1-byte BIP\n324 message type ID for the staletip message.
CompressedHeader FormatThe CompressedHeader is a 48 byte structure equivalent to regular block header\nserialization, but omits the previous block's hash[^rat-compressedheader]. The\nfields are serialized exactly as the corresponding fields are serialized in a\nBitcoin block header:
| Size | \nName | \nType | \nDescription | \n
|---|---|---|---|
| 4 | \nversion | \nint32_t | \nBlock version information | \n
| 32 | \nmerkle_root | \nuint256 | \nThe Merkle root of the block's transactions | \n
| 4 | \ntime | \nuint32_t | \nThe block's timestamp | \n
| 4 | \nbits | \nuint32_t | \nThe calculated difficulty target being used for this block | \n
| 4 | \nnonce | \nuint32_t | \nThe nonce used to generate this block | \n
Implementations of this BIP use the following limits unless otherwise noted:
\n| Name | \nValue | \nMeaning | \n
|---|---|---|
MAX_STALETIP_HEADERS | \n20 | \nRecommended maximum number of CompressedHeader entries in one staletip message | \n
STALETIP_RECENT_WINDOW | \n1000 blocks | \nRecommended maximum distance from the receiver's active tip | \n
MAX_ADVERTISED_STALETIPS | \n10 | \nRecommended maximum number of previously known stale tips advertised to a peer | \n
MAX_STALETIP_HEADERS is a resource-management limit[^rat-maxforklen]. The\nvalue of 20 is intended to cover the short stale branches useful for reorg\ndetection while avoiding long-term tracking of persistent chain splits.
STALETIP_RECENT_WINDOW is a resource-management limit[^rat-maxheight]. The\n1000-block window is about seven days and balances limiting resource usage with\nallowing stale tips to propagate.
MAX_ADVERTISED_STALETIPS is a bandwidth limit[^rat-denialofservice]. Advertising\nup to 10 previously known stale tips, combined with the 20-header branch limit,\nkeeps informing a new peer of known stale tips under 10kB. It does not limit\nhow many stale tips a node retains, or how many newly learned tips it relays\nover the lifetime of a connection. Implementations MAY use stricter limits. A\npeer SHOULD NOT be punished solely because a single announcement exceeds local\npolicy limits.
This BIP defines a new BIP 434 feature id ("the staletip feature"):
BIP332The staletip feature data MUST contain exactly one byte. This byte is a\nboolean, prefers_blocks, indicating whether the node advertising the feature\nprefers to collect the full block data associated with stale tips:
\\x00: the node prefers header-only announcements and does not request that\nannouncements be delayed until block data is available.\\x01: the node prefers announcements that include availability of block\ndata where practical.Nodes receiving staletip feature data whose length is not exactly one byte,\nor whose byte is not \\x00 or \\x01, MUST ignore that peer's staletip\nfeature advertisement. They SHOULD NOT disconnect solely because the feature\ndata is not understood.
Nodes implementing this specification MUST use BIP 434 to negotiate support\nbefore sending any staletip messages.
Nodes MUST NOT send a staletip message to a peer unless that peer advertised a\nvalid staletip feature during BIP 434 feature negotiation. Nodes SHOULD ignore\nstaletip messages received from peers that did not advertise a valid\nstaletip feature. Nodes MAY disconnect peers that repeatedly send such\nmessages without negotiation.
Advertising the feature only signals willingness to receive staletip messages.\nIt does not oblige a node to send them or to serve block data. A node MAY\nadvertise the feature to receive stale tips while never sending any itself, for\nexample a node that only collects stale tips for research.
staletip MessagesNodes implementing this BIP MAY send staletip messages to advertise recent\nstale tips they are aware of. If so:
staletip messages advertising recent stale tips\nthat they are aware of to peers that support the staletip feature.staletip messages if they are not sure that the\nfork_point is a block that their peer is aware of. This can be\nestimated by tracking the highest work blocks announced by the peer,\nand assuming the peer is treating that block as its active tip. Provided\nthe fork_point is an ancestor of that highest work block, the peer\nwill be aware of the fork_point.fork_point SHOULD be chosen to minimise the number of entries\nin the headers vector, while still being a block that the peer already\nhas header information for.fork_point based on their own active chain,\neven if that results in the headers vector repeating some headers\nthat the peer already knows.STALETIP_RECENT_WINDOW blocks behind the sender's active tip.MAX_STALETIP_HEADERS\nheaders.MAX_ADVERTISED_STALETIPS eligible tips. If more tips are eligible, nodes\nSHOULD select those with the greatest chainwork, preferring the most recently\nlearned tip when chainwork is equal. Implementations MAY instead select a\ndifferent subset, for example by sampling independently for each peer to\nincrease the diversity of stale tips available across the network. This limit\ndoes not prevent relaying newly learned stale tips to an existing peer.staletip messages.prefers_blocks setting. If a peer sets\nprefers_blocks to \\x00, stale tips SHOULD be relayed to that peer\npromptly, without waiting to obtain block data. Conversely, for a peer that\nsets prefers_blocks to \\x01, a node that does attempt to obtain block\ndata SHOULD defer sending the staletip message to that peer until it has\nobtained the relevant block data, unless doing so would substantially delay\npropagation.have_block\nas true. A sender that sets have_block to true SHOULD additionally be\nwilling to serve earlier blocks on the announced stale branch that it has.\nNodes without the full tip block data, or that are unwilling to relay the data\nto peers, SHOULD set have_block as false.staletip MessagesNodes implementing this BIP MAY process staletip messages from peers to gain\nmore knowledge about stale tips. If so:
staletip payload, including non-minimally encoded CompactSize values,\ntruncated data, invalid boolean values, or trailing bytes. Nodes MAY\ndisconnect peers for malformed payloads.staletip messages where the fork_point is\nnot known, and MAY disconnect peers that repeatedly send unknown fork points. \nSending such a message violates the requirement above that senders MUST NOT \nsend staletip messages unless they are sure the receiver knows the\nfork_point block.headers vector is empty, and MAY\ndisconnect the sending peer if this occurs.staletip message, nodes MUST bound the resources they\ndevote to it so that a denial-of-service vector is not\ncreated[^rat-denialofservice]. Enforcing the MAX_STALETIP_HEADERS and\nSTALETIP_RECENT_WINDOW limits, together with implementation-specific storage\nlimits, is one way to satisfy this requirement; nodes MAY apply stricter\nlimits.headers vector contains more than\nMAX_STALETIP_HEADERS entries, or MAY partially process headers until local\nlimits are reached.STALETIP_RECENT_WINDOW blocks behind the\nreceiver's active tip.staletip message that passes local denial-of-service\nchecks, nodes SHOULD reconstruct the block headers from the CompressedHeader\nencoding and validate the headers.have_block is true, nodes that prefer to collect the full block data\nSHOULD request missing block data for the announced stale branch in the normal\nway, for example by walking back from the reconstructed stale tip toward a\nknown block and sending getdata messages for missing blocks.staletip feature, subject to local relay policy.\nNodes SHOULD NOT announce the same stale tip to the same peer more than\nonce, and SHOULD NOT announce a stale tip to a peer from which they have\nalready received an announcement of that tip.Nodes in initial block download SHOULD NOT announce stale tips, and MAY ignore\nreceived staletip messages, until they are close enough to the active network\ntip for stale-tip recency checks to be meaningful.
If a received staletip branch has more cumulative proof of work than the\nreceiver's current active chain, the receiver SHOULD process the reconstructed\nheaders through its normal header-processing logic. Such a branch may cease to\nbe stale from the receiver's perspective.
In order for peers to send useful staletip messages, they must be able to\ntrack which block is your active tip in order to deduce whether you already know\nthe fork point corresponding to new stale tips.
Currently, many node implementations make a small optimisation in their block\nannouncement handling that conflicts with this requirement: they will not\nannounce a block to a peer if they have already processed an announcement for\nthe same block from that peer at the time they validate the block. That said,\ndue to delays in obtaining block data and validating the block, it is usually\nthe case that two well-connected peers will announce the same new block to each\nother.
\nNodes implementing this BIP SHOULD always announce their new active tip to all\npeers. To minimise additional bandwidth, they MAY do so via an inv message\nrather than a headers or compact block message.
Headers may be reconstructed from a staletip message via the following\nalgorithm:
prev_hash = staletip.fork_point\n\n for compressed_header in staletip.headers:\n header = BlockHeader(\n version = compressed_header.version,\n previous_block_hash = prev_hash,\n merkle_root = compressed_header.merkle_root,\n time = compressed_header.time,\n bits = compressed_header.bits,\n nonce = compressed_header.nonce\n )\n prev_hash = hash(header)\nHeaders are reconstructed in chain order, beginning with the header immediately\nfollowing fork_point and ending with the stale tip.
Node software implementing this BIP SHOULD provide a configuration option to\ndisable it entirely. Implementations MAY provide separate options for relaying\nstale headers and for requesting or serving stale block data.
\nThis proposal treats stale-tip relay as a negotiated peer service because stale\ntips are useful but not required for normal participation in the Bitcoin network.\nA node can fully validate the active chain, relay blocks, and serve peers without\never learning about stale branches that did not become part of its active chain.\nNegotiating support avoids imposing bandwidth, storage, privacy, or\nimplementation complexity on nodes that do not use this information.
\nThe feature uses BIP 434 negotiation instead of a protocol-version bump or\nopportunistic transmission of a new message. A protocol-version bump would\nunnecessarily coordinate this feature with unrelated P2P changes and would imply\nbroader capability than is actually needed. Sending a new post-handshake message\nwithout feature-specific negotiation would rely on every peer safely ignoring\nunknown messages. BIP 434 provides a narrower capability signal: peers only send\nstaletip messages after the receiver has advertised support for this specific\nfeature.
A separate staletip message is used instead of reusing headers, inv, or\nblock relay. Existing relay messages are primarily active-chain mechanisms and\ndo not communicate the extra information needed here: that the branch is believed\nto be stale, which known block should be used as the reconstruction base, and\nwhether the sender expects stale branch block data to be available. Reusing\nexisting messages would either overload their meaning or require receivers to\ninfer stale-tip intent from context. A dedicated message keeps the behavior\nexplicit and allows implementations to apply separate resource, privacy, and\nrelay policies.
The protocol is announcement-based rather than request-based. An alternative\nwould be to define messages for requesting known stale tips from a peer, but that\nwould add more state, more peer-specific behavior, and a possible query\namplification surface for a feature whose events are expected to be rare. Simple\nannouncements are sufficient for the main use cases: faster preparation for\nnear-tip reorgs and passive measurement of stale-block propagation.
\nThe message includes a fork_point followed by compressed headers because the\nprevious-block hash in each header is redundant once the fork point is known.\nThis saves 32 bytes per header while preserving the normal block-header fields\nneeded for validation. More aggressive compression of nVersion, nTime,\nnBits, or nonce was not chosen because those fields are consensus-relevant\nand chain-dependent. Compressing them would add implementation complexity and\nincrease the risk of divergent reconstruction behavior for relatively small\nadditional savings.
The fork_point is required to be known by the receiver so that the message can\nbe processed without an extra round trip. Allowing the fork point to be either an\nactive-chain block or an already-known stale-branch header lets senders avoid\nresending headers the peer is expected to know. Requiring the fork point to be\nthe exact divergence point from the active chain would be simpler conceptually,\nbut less efficient when both peers already know part of the stale branch.
The branch length limit of 20 headers is a deliberate resource bound. Stale\nbranches relevant to near-tip reorg handling are expected to be short, and longer\nbranches can be handled by normal header synchronization if they become important.\nThe limit keeps each message small, bounds validation work, and prevents\nstaletip from becoming a cheap bulk-header relay mechanism.
The recency and advertised-tip limits are recommendations rather than strict wire\nrequirements because different nodes have different goals. A monitoring node may\nadvertise more stale tips for measurement, while a resource-constrained node may\nadvertise fewer or ignore them entirely. Selecting the greatest-chainwork tips\nprioritizes branches most likely to become relevant to a reorganization, while\nrandomizing the selection independently for each peer can improve network-wide\navailability when more tips are eligible than can be advertised. Treating these\nlimits as local policy allows implementations to differ without making honest\npeers appear malformed or misbehaving.
\nInvalid or locally unacceptable stale-tip announcements are generally ignored\nrather than punished. Stale-tip relay is inherently race-prone: peers may have\ndifferent active tips, different retained stale headers, or different local\nresource policies. Disconnecting peers for these cases would risk penalizing\nhonest nodes during exactly the network conditions where stale tips are most\nlikely to appear.
\nThe have_block flag is a compact signal that block data for the announced stale\nbranch may be available from the sender. The tip block is the minimum object\ndescribed by have_block, because it is the final header in the announcement and\nthe block most immediately useful for reorg preparation and block-policy\nanalysis. Receivers may also request earlier missing blocks on the announced\nbranch. Describing availability for every block in the branch would make the\nmessage larger and more complex; peers can instead request missing blocks through\nnormal block download and retry with other announcers if requests fail.
No one-byte BIP 324 message type is assigned for staletip. BIP 324 short\nmessage identifiers save the 12-byte ASCII command overhead for messages that are\nsent frequently. Stale-tip announcements are expected to be rare, and each\nannouncement already carries at least a 32-byte fork point and one 48-byte\ncompressed header, so the bandwidth saved by replacing the staletip command\nname with a one-byte identifier would be negligible. Since the one-byte identifier\nspace is limited, it is better reserved for messages that are common enough for\nthe per-message saving to matter.
The test-network guidance is stricter because test networks have weaker\nanti-spam properties than mainnet. Signet headers cannot be fully validated\nwithout the block data containing the signature, and testnet difficulty rules can\nmake low-work stale headers cheap to produce. The specification therefore leaves\nroom for implementations to disable the feature on test networks or apply\nstronger relay policy there than they would on mainnet.
\nMaking this feature available on test networks raises additional concerns, as\nthey are less protected by proof of work, and thus may have a larger attack\nsurface for denial of service issues. As a result, node software implementing\nthis BIP MAY choose to do so only for mainnet.
\nThe default signet is expected to reorg roughly once per day, with a branch of\nrandom length. Stale tips are therefore common on signet rather than rare, and a\nstale branch may be longer than MAX_STALETIP_HEADERS. Such a branch will not be\nrelayed via staletip; nodes fall back to normal header synchronisation for it,\nand implementations MAY raise the limit on signet.
The signet network is designed around the assumption that all valid blocks are\nsigned, and thus much lower proof of work is needed. However, because the block\nsignatures are included in the coinbase transaction, they cannot be verified if\nonly the block's headers are available. As such, when implementing this BIP for\nsignet:
\nstaletip messages when they do not have the\ncorresponding block data needed to verify the signet signature.staletip message with have_block\nset to false.prefers_blocks to \\x01 when negotiating the feature, as\nthey will always need to download the full block data for a stale tip to\nvalidate the signature.In addition, when the difficulty is low, it is possible that varying the nBits\nfield of a valid block will generate another valid block (see #33266).\nAs such:
While nodes MAY also deduplicate such variant headers when receiving them via\nstaletip messages, if they do not perform the same deduplication logic when\nreceiving such headers via standard headers or block relay, that provides\nlittle protection. Deduplicating when sending staletip messages is primarily\naimed at avoiding nodes implementing this BIP from being used to amplify\nattacks.
Only variant tips need to be deduplicated: it is possible, though unlikely, that\nvalid signed blocks may be descendants of variant blocks. These blocks will not\nthemselves be variants, as they will have different previous blocks.
\nWhile testnet3 and testnet4 blocks are proof-of-work based like mainnet, they\nboth allow for low difficulty blocks:
\nAs a result, nodes could see many valid stale tips with minimum difficulty,\neither due to such tips being created with long timestamps, or, on testnet3,\nbecause the difficulty has been reset. To avoid this scenario, when implementing\nthis BIP on testnet3 or testnet4:
\nThis BIP introduces a new P2P message (staletip) and relies on BIP 434\nfor feature negotiation to avoid impacting nodes that do not support this BIP.\nNodes MUST NOT send staletip messages to peers that have not negotiated the\nstaletip feature.
Nodes that do not support this BIP may still see more frequent notifications of\nwhen their peers update to a new active tip, if implementations choose to make\nactive-tip inv announcements to all peers rather than only to peers that\nnegotiated the staletip feature.
Sharing stale tips raises several potential privacy concerns.
\nThe first concern is fingerprinting. A node's behaviour when negotiating and\nsharing stale tips may make it easier for peers to distinguish that node from\nothers on the network, perhaps allowing attackers to relate a node's onion\naddress with its IPv4 address. The BIP 434 feature advertisement itself, the\nprefers_blocks value, active-tip announcement behaviour, and stale-tip relay\ntiming are all potentially fingerprintable. Since stale tips are expected to\npropagate fairly efficiently and consistently, and to remain rare, this is not\nexpected to be a significant problem in practice. For users that remain\nconcerned, disabling stale tip relay entirely is probably the best approach.
The second concern is for miners with private transaction pools. In that case,\nminers have a selection of transactions that they wish to mine themselves\nwithout giving other miners the opportunity to compete with them, only\npublishing them when they construct a block with valid proof-of-work that\nincludes them. Relaying those transactions via staletip announcements will\nlargely be harmful to a private transaction pool operator, as it will not help\nthem win the stale block race. It will only allow nodes to reorg slightly faster\nif they do win, but if they lose the stale block race it will make their private\ntransactions available to competing miners. This is a particular concern if the\nreason for the block being stale is due to inefficiencies in updating ASIC\nminers to a new work target, in which case there is almost no chance of winning\nthe stale block race. As such, miners operating private transaction pools should\nprobably disable stale tip relay entirely on the nodes they use for processing\ntheir mined blocks.
A prototype implementation is available at:
\nThis serialization test vector is from signet, where a 19-block stale branch\noccurred at height 287767-287785. Because this vector has have_block set to\nfalse, it is not an example of a Signet staletip message that conforming\nnodes should relay under the Signet-specific rules above.
| Field | \nValue | \n
|---|---|
| Network | \nSignet | \n
| Fork point height | \n287766 | \n
| Fork point hash | \n00000012602fde2eaf33a90523f42fb07ca854c1d26108782dc4592a80507e1c | \n
| Stale tip height | \n287785 | \n
| Stale tip hash | \n0000000024ff924ff932668d497bba7da9157559a68d9c87d2f28d22e5e4a001 | \n
| Branch length | \n19 | \n
have_block | \nfalse | \n
Serialized staletip payload (946 bytes):
1c7e50802a59c42d780861d2c154a87cb02ff42305a933af2ede2f60120000001300000020\n67aa2937b235e209f1ad40f37b17dcad8ca02d1fb9cf4c4928902eab3ff853a6cda16e6916\n58151d81ad7b0400000020721ab6f36042842bab4583f98e15181b646c47c7b9dfb07a204c\n4e5152e54e97fda46e691658151dd2dcec1800000020ddc6b628101b404f78d446591a623e\n12bb7e7cd2ae1593d0cc6ef082e19fa81014a66e691658151d46070e10000000208be5b960\n7b20ac0163b885881aa6018ef60a5637b93a9cd85981515a169a31c36aab6e691658151de4\ne10600000000206c974ef806b2e6a21cc9a53fedcbd5d5e203b4929a1bd7c5859ec77d0a75\n5c1d64ae6e691658151d2a2e130e0000002039505fa2ee91f5e5b2540b4a9a7f02ed58d79f\nc387412cf2520a39ee16bf435f6eb16e691658151db29c830a00000020411bce69cda2b239\nc74faea1f0cfaceabd90377114dc0ace14e2a58858cd4f9a91b46e691658151d4c2d3f0500\n00002096464a2ec42fea8419a5c6adcc41ca7dc3f53461cd0afc880f76498aa8eedbf993b5\n6e691658151d5e99700b00000020c3cad611ee3c7bffec3f80fc83f68192ca0a86e8c89050\nf8353480310d080caf08b76e691658151dbc61a6150000002079e36b5a06bb5a524a2f5bad\n6725451613c354cbf64f9a0283f77fe90782d59fcbba6e691658151d6c669300000000204c\n69fd467818994e7ff885181e7451d23869a7fd19447dad7a95398077ed7774dcba6e691658\n151dc9c7ff02000000208ea9a871b12cd45226ab6df280ec46b8c9ca196b98dc8adc27718c\nab333e19a50abc6e691658151df6bae902000000209c182979424a5c85d55d5bddbf3b9421\nb01b7810edf95ad2529552dd2eec80848ebd6e691658151d439e5c0000000020cfb9f6d164\n3613dfdd23a6e1eabadac38c392f985f5dc05b00ef682c428922c96cbe6e691658151d278b\n4d1400000020eea983b8d64947368de4f7626531a3134d18f20a8d87462ba011a4f56a53b6\nac4fbf6e691658151ddae8640800000020140bc70b1a3282fbebf9d48ff40a9b73ab7c76ad\n522799cee73315e9c21aab50dcc06e691658151dedaae90f000000209b91a056fe089429f2\nba4298e764acb4177249ce7d68e6883836f70d1d9218b355c16e691658151d28a432060000\n0020b26e80c6a12cc4595556d2318fda564ced5d2a526c7b77f57a9897a56c10539056c16e\n691658151dc64fb50000000020369d36495749c96d36260d839abfa703a611aad7b3016342\nef05d0412f42221e6ac56e691658151d8f8bfb0f00\nPayload breakdown:
\nfork_point (uint256, little-endian)0x13 = 19)CompressedHeader entries (48 bytes each)have_block (0x00 = false)This test vector uses mainnet headers from the BCH fork. Blocks 478559-478576\nhave valid Bitcoin headers meeting proof-of-work requirements, but are invalid\nBitcoin blocks because block 478559 exceeds the 1MB block size limit. Block\n478577 changed difficulty under BCH's Emergency Difficulty Adjustment rules,\nmaking it an invalid Bitcoin header as well.
\n| Field | \nValue | \n
|---|---|
| Network | \nMainnet | \n
| Fork point height | \n478558 | \n
| Fork point hash | \n0000000000000000011865af4122fe3b144e2cbeea86142e8ff2fb4107352d43 | \n
| Stale tip height | \n478576 | \n
| Stale tip hash | \n000000000000000001416af072f8989829f4c60a1a9658e1cec08411798e4ffa | \n
| Branch length | \n18 | \n
have_block | \nfalse | \n
Serialized staletip payload (898 bytes):
432d350741fbf28f2e1486eabe2c4e143bfe2241af65180100000000000000001200000020\nabaa4bd8a48c1c6bc08ee39b66065e5e9484304cab8b56d5eed3e40b1ac996c899c4805935\n47011822ca4ae80000002082afc8ef7eb41a4ecac1fea46983742e491f804ad662e3745ab9\nc6c4297d8a0862c980593547011840a772cb0200002058874e50628fdf83aeea4e8cbc7ade\n946e9ba14bcb1d8ffb28c3daf8ade84df65fca805935470118e2f5100300000020111b85f9\nd3b969a1f7ff3d50af08893c500edfc5623b96dbeab6daf16a5164a40ace805935470118c4\nf4240a0000002040a045063b551b61d6a1c9db6d3231e2d7403185bbb2332ae1f66db24aac\n7fa288d8805935470118f15dd76b0000002070cb14529e8757c359c2e8b1e987f6eee6fbc4\n472ee9ad4a2e5df6905c19d6d70bed80593547011885ae00d0000000209653314c1d73e463\n0bb485fb25ce7a2583cec7c3ccfc27a6d24163be1e9fb19530f4805935470118f17ad2c500\n000020cdf48b8e7ac6bf3a51d1878ee3ff7e6fd0022926dd69cc5cc8d9126e77c4dba809f5\n8059354701188114e83600000020890cf1dc60edbf0fd4fb667f28ac785849c031d8b24d5e\n5a0af56ee2bd8a739bf51081593547011812f32a9600000020ff5244613ad20fdc39b7ee6f\n4fbc7016432d2dbf45c2a950c59665b39c3954b5b525815935470118aa790d6600000020ae\ned520e7c1693de5cfe7531e7d3e73dff7858b09cb6e1ec29229a75c3da2b92453e81593547\n011830a4314d000000202e4a4054e64c3f5810c23ec0144d9793aab2d5a7d77d1660eee24d\n3d55e8b715b543815935470118da1c00e00000002073152af68778a98fd984a158aeb29d28\ne094e23c3a7dff02260c345791e52498c3fb8159354701188d5abed90000002022606e744a\n29f9d4a67ff1fcd2f0e31300ddbd145f8f1db8a68270bfbde77dd88fff8159354701186af1\n75f8000000209f5db27969fecc0ef71503279069b2df981ba545592a7b425f353b5060e77f\n3e7e13825935470118da70378e000000202f0d316b08350f5cd998c6a11762d10adb9f951b\n5f79ce2a073f8187c05f561f1b1c8259354701184834c62300000020cf8fc3bad8dad139a3\ndd6a30481d87e1f760122573168002cc9ef7a58fc53ad387848259354701188a3b54f70000\n00200eae92d9b46d81a011a79726a802d4eb195a7af8b70a09b0e115c391968c50d51c8a82\n5935470118cd786d1300\nPayload breakdown:
\nfork_point (uint256, little-endian)0x12 = 18)CompressedHeader entries (48 bytes each)have_block (0x00 = false)This BIP is licensed under the 3-clause BSD license.
\n[^rat-compressedheader]: Omitting the previous block hash from each header saves\n 32 bytes per header (40%), as this field can be reconstructed from the\n preceding headers in the message. This does not apply to the first header,\n which is why the fork point must be included explicitly. This BIP does not\n attempt to omit nBits or compress nTime or nVersion, because\n reconstructing those fields is significantly more complicated for\n comparatively much less potential gain.
[^rat-maxheight]: A window of 1000 blocks (about 7 days) provides a\n reasonable balance between limiting resource usage, and maximising\n propagation potential. By limiting the distance to the tip to being no\n older than the previous retarget period, we ensure that the difficulty\n of creating a stale block is comparable to creating a new tip, making\n it uneconomical to use this as a spamming mechanism. By choosing\n a longer period, we provide the opportunity for nodes interested in\n stale block data for research purposes plenty of opportunity to obtain\n the data. In particular, many nodes will tend to discover it through\n the periodic blocks-only connections (see Bitcoin Core PR #19858).
\n[^rat-maxforklen]: Limiting the branch length to 20 headers avoids nodes\n being burdened with tracking deliberate chain splits. When\n incompatible consensus rules are enforced, the majority chain need not\n continue sharing the minority's fork beyond a short window. Twenty\n blocks is sufficient to capture the short-term stale blocks useful\n for reorg detection, while avoiding long-term tracking of persistent\n chain splits.
\n[^rat-denialofservice]: Limiting stale branches to 20 headers bounds the\n per-message size to under 1kB. Combining this with a default limit of 10\n previously known stale tips advertised to a peer ensures that the initial\n relay bandwidth is under 10kB. Restricting relay to recent tips whose proof\n of work is comparable to the active chain makes stale-tip spam costly on\n mainnet.
\n[^rat-ignoreinvalid]: Ignoring rather than punishing allows nodes to apply\n different limits for what stale tips they accept. If one node uses stricter\n limits than its peers, this avoids the risk that honest announcements from\n those peers will cause disconnection and potentially network partitions.\n This is also consistent with how invalid headers are handled.
\n","toc":[{"id":"abstract","title":"Abstract","level":2},{"id":"motivation","title":"Motivation","level":2},{"id":"specification","title":"Specification","level":2},{"id":"the-staletip-message","title":"The staletip Message","level":3},{"id":"compressedheader-format","title":"CompressedHeader Format","level":4},{"id":"protocol-constants","title":"Protocol Constants","level":3},{"id":"staletip-feature-definition","title":"Staletip Feature Definition","level":3},{"id":"bip-434-negotiation","title":"BIP 434 Negotiation","level":3},{"id":"sending-staletip-messages","title":"Sending staletip Messages","level":3},{"id":"receiving-staletip-messages","title":"Receiving staletip Messages","level":3},{"id":"active-tip-announcements","title":"Active Tip Announcements","level":4},{"id":"reconstructing-headers","title":"Reconstructing Headers","level":4},{"id":"optionality","title":"Optionality","level":3},{"id":"rationale","title":"Rationale","level":2},{"id":"test-networks","title":"Test Networks","level":2},{"id":"signet","title":"Signet","level":3},{"id":"testnet3-and-testnet4","title":"Testnet3 and Testnet4","level":3},{"id":"backward-compatibility","title":"Backward Compatibility","level":2},{"id":"privacy-impact","title":"Privacy Impact","level":2},{"id":"reference-implementation","title":"Reference Implementation","level":2},{"id":"test-vectors","title":"Test Vectors","level":2},{"id":"signet-stale-branch-19-blocks","title":"Signet Stale Branch (19 blocks)","level":3},{"id":"bch-fork-headers-18-blocks","title":"BCH Fork Headers (18 blocks)","level":3},{"id":"copyright","title":"Copyright","level":2}],"history":{"totalCommits":1,"firstCommit":"2026-08-21T15:49:20-07:00","lastUpdated":"2026-08-21T15:49:20-07:00","events":[{"sha":"8aacefed1882e37e2e4daabedf721f1298a62530","date":"2026-08-21T15:49:20-07:00","author":"pseudoramdom","message":"Add BIP-332: Stale Tip Relay","url":"https://github.com/bitcoin/bips/commit/8aacefed1882e37e2e4daabedf721f1298a62530","kind":"edit"}]}}