CHIP 2026-p2p-txok: p2p network message 'accepted'
Title: p2p transaction-OK
Type: Standards
Layer: Network
Author(s): Tom Zander
Status: Draft
Maintainer: Tom Zander
Initial Publication Date: 2026-05-22
Latest Revision Date:
Table of Contents
Summary
We introduce a new p2p message 'accepted' that full nodes can send when the peer both asks for such messages and after the peer send a transaction. This message would be send when the 'reject' message is not applicable. See bip61 which introduced the 'reject' message.
Deployment
P2P messages are ignored by receivers that don't understand them. As such this is a permissionless upgrade.
Motivation
In a decentralized and trustless network like Bitcoin Cash, wallets and point-of-sale terminals are currently severely at a disadvantage when it comes to answering the simple question of: what is the status of my transaction?
Transactions send to random bitcoin cash nodes are in an intermediate state from the moment it is offered to such a node until we receive a block that includes it. When the next block contains the transaction, everyone is happy. But if it does not then there is no way to tell why or why not. Today the network is mostly uniform with relay rules being quite consistent and also the miners manage to mine the entire mempool in the next block in most cases. But when that stops being a fact of life, being able to understand what the status is of your transaction becomes essential to a predictable chain.
One of the interesting problems one may run into is that when a transaction is first seen by a node, it offers it to its peers. Should for any reason a miner not have received that transaction then simply offering it to the peer again has no effect. A transaction is only forwarded when it is first seen. For these and other problems it would be super useful to ask the simple question how much longer the peer expects to hold onto the transaction before it is purged from the mempool. Because after that time it is possible to offer the transaction again and in that way re-try pushing it through the system.
Being able to subscribe to the 'rejected' and 'accepted' messages will make a world of difference to p2p wallets and with some work any middleware (like Fulcrum) will be able to forward those messages to wallets as well.
Technical Specification
We increase the protocol version (as reported by the version message) to 70017, all implementing this protocol version, or later, should support the new messages.
We introduce a new message 'sendaccept'. It has just a header, no body. Receiving this message will set a boolean on the connection and the node will send accepted messages to that peer.
We introduce a new message 'accepted'. This is send as a response to a 'tx' message. when the transaction is either already in the mempool or newly accepted in the mempool.
For example the flow between two peers for a relayed transaction may be:
--> sendaccept
--> tx
<-- accepted
Common payload
Every 'received' message contains the following fields.
| Field Size | Name | Data Type | Comments |
|---|---|---|---|
| 32 | hash | char[32] | Transaction that is accepted |
| 1 | ttl | uint8_t | Number of blocks left to stay in mempool |
This assumes a mempool expire time counted in mined blocks and the message relays the number of blocks mined until the expiry algorithm is set to remove the transaction.
Feedback & Reviews
Changelog
Copyright
Copyright (C) 2024-2026 Tom Zander
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.