The longer post I wrote yesterday addresses that in multiple ways.
But the idea is basically identical what I started out with in the p2p lib on flowee, I had it in place for a couple of months until it turned out it was causing more problems than it solved. Which is why in around 2021 I had to change it to what you see now.
Tl;Dr: Was the first idea of mine too. Turned out to be naive and had to improve it to balance the whole better.
I think I must have missed something in that post. Do you think you could do a solid writeup in the actual CHIP thread expressing your concerns, purely from a technical perspective, without inserting opinions about the metadiscussion?
There are a few things in the CHIP thread that @rnbrady had mentioned as well regarding SPV. I intuitively share some of those concerns in regards to SPV over NFC, but as I reason through it I’m not sure if it’s a real problem in the modern reality where tech like Starlink and ubiquitous 5G connectivity exist.
I would appreciate your input there considering you seem to have concerns of a similar class. I’d very much like to evaluate the proposal on concrete, measurable technical merit.
Don’t confuse bandwidth and latency. It is the latency that gets you.
Grandstanding with 15 yeears of experience, and you still didn’t hear about batching? There is no fundamental reason why 1-min blocks should hamper SPV. Even P2P protocol as-is has enough batching support, which you tried to handwave yet again. Maybe you could use your years of experience to come up with even better P2P protocol for SPV wallets, like merkleblockbatch response.
PS interesting that your commit doesn’t give any reason for changing the number from 100 to 9. In 2021 you made your wallet 10x slower for no reason.
Fix merkleblock download as bloom filters change.
In HD wallets we get an issue where not-yet-generated keys are needed in the merkle-block request and we notice this as a chunk of blocks is being downloaded. This is solved with some extra code. Also avoid re-uploading the bloom filter during initial sync.
https://codeberg.org/Flowee/thehub/commit/701698d6e12fc0e34a73bf136f0845cfcdb17337
bwahahaha 
good luck with that 
I’m struggling to make the connection. I re-read your long post again and the tl;dr is what you just said here, but I’m failing to see where latency becomes a factor for SPV with 1-minute blocks. If you could make it crystal-clear for me, I would appreciate it… sorry.
Why would we round-trip a request for each individual block/address/filter? Why not just do a single request, which would mean latency is the same regardless of payload size?
Edit: I see you did write in the Fablous thread, so I will read that and continue there.
We now have just over 90 days until the November 15, 2026 lock-in date. My, how time flies!
To my knowledge, these are the CHIPs that are being realistically discussed for the 2027 upgrade cycle:
Per the suggested CHIP schedule, any serious and non-controversial contender should now be starting to seek full node implementation and preliminary stakeholder statements.
I am not aware of unanimous consensus for any of these three proposals, nor unanimous rejection. I think that EC ops and OP_SIGHASH could make it into this upgrade cycle with a strong proponent to carry it across the finish line.
I personally think that Faster Blocks needs more time to simmer. There are clear benefits, but I do not think the problem space is fully explored, nor do I think the community at large has had enough time to fully digest the proposal.
Importantly, I am not expressing this opinion as a “pro-ossification” signal. I just think there needs to be more time, discussion, and evaluation of alternatives. Imagine if we settled on OP_GROUP or PMv3 and never got CashTokens 
If Faster blocks (or any of the others) sit a year, then keep in mind that will mean they won’t activate until May 2028 at the earliest, which is the far flung reaches of spacetime in today’s world.
But also, I guess it’ll come around faster than we expect like always.
I do hope we can get to a solid lock in, but you’re right it’s getting down to it and I do still see some debate and people that are ambivalent rather than excited.
Which part of the problem space do you think is underexplored? Nice thing is it doesn’t conflict with other improvements (Tailstorm, Sunlight, w/e, they can all work fine, or even better, with faster base blocks). Unlike Group vs CashTokens we’re not really building a new subsystem, we’re just tuning the parameter of an existing system, so it doesn’t really conflict with any hypothetical future thing.
Which part of the community do you think didn’t yet digest it? I think it’s pretty much digested, what new thing could surface? I think postponing would just create opportunity for detractors to try throw a wrench.
You will never get unanimous. Best we can do is some loose and overwhelming agreement. There will always be those who disagree, can’t hold the horse just for them. Activation is the ultimate test of how well we built and estimated the support, every activation is a vote of confidence.
I don’t think we’ve adequately explored the impact to SPV; we’ve only discussed potential mitigations but haven’t actually assessed viability of those mitigations from a practical/implementation standpoint.
I’m not confident that there are not still unknowns to explore. That’s part of what I mean by digestion. The CHIP as written is indeed quite thorough, and by no means do I want to discount that or claim that the work has not been valuable.
I’m hesitant to strongly endorse November 2026 lock-in without having a better understanding of alternatives like Tailstorm, weak blocks, Sunlight, etc. That’s more on me than on the CHIP author, but still points to the social and cognitive costs that come with such an impactful upgrade. I cannot in good faith offer a strong endorsement without thoroughly understanding it from every angle.
I think that changing blocktime naively could have unwanted second order effects on the economics of the network. One example: we’re simply assuming that exchanges will either 10x their confirmations to compensate, or be ignorant and change nothing. Without actually talking to some exchanges, we have no clue what they’re going to do, and I think that should partially inform what tradeoffs we ultimately find acceptable in pursuing this proposal.
Now, I will openly admit that I don’t know what I don’t know - and that’s a huge contributing factor to my concern that “the problem space has not been fully explored.”
In terms of the community at large digesting the proposal - frankly, I think there are many people with opinions who still haven’t even read the CHIP. It could be the best written CHIP ever, but if the community has not had time to actually read it and properly understand all of its implications, we can’t really say that we’re making an informed decision in aggregate. Right now I see enough contention (or at least lack of knowledge) on the CHIP that I think it would be rather hasty to lock in a mere 90 days from now.
This is more than just a technical issue, it’s also a social issue. I am definitely not saying that we should never adjust the blocktime or that we should stop pursuing innovation on BCH. I do think that it would be wise to target the 2028 upgrade cycle in order to ensure that we are not missing any footguns and to allow the community to demonstrate a stronger consensus.
On that note, I do think that consensus is slowly building - I don’t think that waiting will cause a roadblock. We are after all evaluating the CHIP on its technical merits, not on emotions. I don’t really anticipate a BIP-119 type scenario where we stall out on good ideas for years on end. In fact, I’d actively campaign against that outcome.
I think there’s also a strong point to be made that despite many “small wins” that combine to demonstrate benefit from the Faster Blocks CHIP, those small wins still may not outweigh the overall social and technical costs at this time. We’re talking about an effective architectural refactor for the entire ecosystem. The “YAGNI” mantra comes to mind with the whole tick system. There is in fact a lower bound to how fast we can confirm a transaction. If we use Solana as an example, they claim transaction finality with times measured in milliseconds, which indicates to me that the time is almost entirely taken by network propagation. So in effect, their security is similar to ours with 0-conf.
And of course, we can’t gloss over the fact that faster blocks are in fact addressing a symptom, and not a root issue. The issue that I think has unanimous agreement is that waiting for the 1-conf failure mode sucks in instances where 0-conf is not accepted. Discussion around the CHIP has steered away from the idea of trying to educate the ecosystem about 0-conf. I understand the sentiment, given that we can’t even get Coinbase or Binance to use Cashaddr. But we also should think about all of the other misinformation and propaganda we’ve dispelled over the years. What would make this different?
Overall, I am suggesting a cautious pause - I do not think it is necessary to rush for 2027 lock-in, and I think we would all benefit from having more time for everyone to actually grok the proposal. If “detractors throwing a wrench” is a concern, we should address those wrenches on their merit the same way we do the proposal itself. We can all recognize hand-waving bullshit and call that out - and we routinely do.
Main concern has always been those pesky headers.
On the SPV front, here’s what’s already been done, in case you hadn’t seen these:
What more do you expect me to do?
As for the other “issue” being thrown as an obstacle, that is specific to BIP-37 and is solvable by batching, if one wants to solve it. But to me it looks like they prefer to maintain that obstacle.
After all the CHIP’s been through, really?
Zcash didn’t seem to have any trouble there, why should we?
Not everyone is expected to read it in full. CHIP is like a dossier of the process and a point of reference. Some people may be convinced by 2nd-hand information or discussions on other channels, and that’s fine, they don’t ever need to read the CHIP body.
This kills motivation, you know, I feel we’re near the finish line and you’d have me suffer the CHIP-bearer burden for 1 more year. For what exactly? 90 days should be enough to complete the implementation and torture some testnet/scalenet network confirm it all behaves as expected, and finally in November do the victory dance of collecting statements.
Ah, the “unknown unknowns” problem. Every upgrade carries those, if we waited until all future unknowns were known, we’d never activate anything. That’s what testnet and scalenet are for: to surface the concrete, measurable issues before mainnet. But look at the broader picture: faster block times have been discussed on and off since 2014, and in all those years no new fundamental obstacle has surfaced. Dogecoin has been running 1-minute blocks the entire time (since 2014) without breaking SPV or exchanges or anything else. Zcash moved to 75s blocks in 2019 without catastrophe, and is now proposing a further cut to 25s. We’re not charting unknown territory; we’re following a well-trodden path where the unknown-unknowns have already had over a decade to show up and haven’t.
Ticks are kinda orthogonal to actual consensus change of block frequency. API will expose it, you don’t have to use it. Zcash just stuck with block height and their ecosystem managed. Under the hood, in BCHN, it’s a refactor. One could implement it all without using ticks and be in consensus, but then they’d have to do double work later, in case we ever wanted to change block time again.
I expect many wallets to not care about ticks. If they don’t do SPV why would they care? Take Cashonize, why would it need to change anything for faster blocks? It can just continue to use height.
For an entity like Thorswap, ticks should be very useful because they can fit right into their formula for required number of confirmations: delay = delayCalc(outboundValue - (cloutScore - cloutUsed))
We needed faster blocks since 2014, we’re 12 years late, here’s Gavin Andresen arguing for it in 2014:
Copy/pasted from #bitcoin IRC:
Jeepers creepers, I can’t have a half-baked opinion on ANYTHING anymore, can I?
I do think 1-minute blocks would pass a cost/benefit analysis; benefits would be less variance in confirmations-for-whatever-level-of-security (e.g. wait 60 1-minute confirmations has much lower variance than wait 6 10-minute confirmations).
I think it would probably encourage mining decentralization. Easier to solo mine if you’re competing for 1.25 BTC 1-minute block instead of a 12.5 BTC 10-minute block.
… that might not be true, would have to run the numbers for disadvantage due to higher orphan rates…
I have no opinion on whether or not the adjust-difficulty-every-2-weeks should be changed if the block time was changed, but that’s something else to think about.
Disadvantage is that SPV nodes would have to download more headers, but that’s not a huge disadvantage and I think the benefits of an SPV node finding out about a re-org / double-spend quicker probably outweigh them.
One minute is not fast enough for real-time payments, so that’s neither an advantage or disadvantage.
Whether or not to change the 10-minute block time is a separate issue (with its own pros and cons) from whether or not the max block size should change. Status-quo with a faster block time would be 100K max blocks, each with one-tenth the current mining reward.
Yes, bounded by speed of light and planet size. On Earth, I think a lower bound is some 6-10s. We don’t have to be instant, we just need to be fast enough for fallback 1-conf UX not to suck, maybe we’ll settle at something between 10s and 60s later on, and for instant UX we will depend on 0-conf like we do now, and maybe improve it with ZCEs or something.
It’s not a matter of education. Once educated, you will understand that it’s risky to accept 0-conf with DSP score 0, and you will ask for 1-conf (e.g. Bitgree - “What happens if a double-spend attempt is detected?”). I think some proponents of 0-conf, who think of it as the panacea, are really the uneducated, because they think it can just work in all contexts and without risks/trade-offs.
There are contexts for which 0-conf is not good, and 1-conf or N-conf will always be required, and faster blocks will help smooth out those experiences. Education won’t make these contexts go away, they will always be there, and be a nuisance as long as we have 10-minute block time.
Thank you for reintroducing me to the SHV/MMR work, and I apologize if my response came off as undermining your hard work as that was not my intent at all.
After reacquainting myself with that work, I can appreciate that the storage burden is managed by SHV. But it does not address my primary concern, to which I have still not found a satisfactory answer:
A NFC card-based tap-to-pay method of payment is desirable for BCH. I can imagine many scenarios where I may wish to have access to my funds but do not want to carry a smartphone or smartwatch. The NFC card is a highly familiar and portable medium for payments that currently has no comparable alternative.
It’s not enough to simply trust a SHV checkpoint from a merchant terminal. In any kind of adversarial chain split scenario, that would open the payer to potential replay attacks if they need to sync their card and the merchant lies about which UTXOs are spendable and gathers a signed transaction that can be broadcast on a competing chaintip.
Most NFC cards can transfer data at ~53 kilobytes per second, with a future spec potentially doubling that to ~106 kilobytes/sec. Even if we double the throughput, with 1 minute blocks a week worth of headers still approaches ~8 seconds of sync time, which renders any NFC card solution for BCH completely uncompetitive when compared to existing fiat solutions.
Batching is also orthogonal to this issue.
I can accept a minor change in the SPV trust model in the case where we can assume a reasonable amount of connectivity - even an NFC handshake that opened up a Bluetooth channel would be better, but we don’t have that option with just a card. In such a case we can reasonably trust a handful of servers corroborated with our locally stored checkpoints in order to verify the latest valid chaintip. As soon as we introduce the bandwidth constraint, the trust issue becomes much more critical due to UX; and ironically UX is what this CHIP is aiming to improve overall.
This issue alone is enough to give me pause on Faster Blocks. I am highly interested in developing such novel payment solutions for BCH as it is a directly relevant line of business for Selene and other wallet providers.
This issue IMHO compromises the strength of censorship-resistance and the trust of small confirmation counts in a regime where reorgs are significantly cheaper. Is this mitigated by the reduced variance of a faster blocktime? Maybe, but I don’t know. Is it measurable? I think they should be considered independently, as I don’t think they’re strictly inversely correlated.
To the social points:
While I highly respect the effort and research you’ve put into the proposal, and by no means do I intend to disparage that, I still think that it’s important that the obvious majority of the community is in favor of the proposal as written. I am not suggesting that we abandon the CHIP, I am merely suggesting that it might be worth pushing to 2028.
That’s also not to say that there can’t be a substantial push to tie up the loose ends within the next two months. We did it last year and to my knowledge nobody has any regrets about the 2025 or 2026 upgrades. But I’d like to maintain this “no-regret” status.
I understand the “unknown unknowns” argument is frustrating which is why I tried to hedge against it in the first place. If we have to chalk that up to a “skill issue” on my part, so be it I guess. But I empathize with other community members who might not be as close to the discussion as I am, taking on information via 2nd-hand channels, and also potentially walking away feeling like the proposal wasn’t fully explored.
By the same token, I can completely understand feeling demotivated, thinking that the finish line is right around the corner. But in reality please consider that the November 2026 “finish line” is arbitrary. It was never guaranteed that we would activate this CHIP this year, and moreover my objections alone should not be enough to completely hamper all progress on it. The CHIP process is specifically written as such to avoid emotional appeals. That applies equally to me - just because I “feel” like the problem space hasn’t been fully explored doesn’t mean that’s true.
Please however do not insinuate that I’m advocating for indefinite postponement. I was careful to specifically say that’s not my intent multiple times.
In regards to Dogecoin and Zcash:
To my knowledge, neither of those coins have attempted to target the payments usecase I’ve described either. I don’t know how Zcash wallets work, but if they’re anything like Monero wallets, then I hope you can see the UX problem that comes with the examples you cited. The issue itself it not faster blocks alone. I am not arguing that the network catastrophically breaks by decreasing the blocktime.
On ticks:
One of the major secondary benefits of the CHIP is increased granularity for chain-authoritative time. Right now if you want to measure any kind of time interval using the blockchain, you would use blockheight. Having 10 subdivisions would allow us to have locktimes that span only a few minutes with smaller variance. Obvious win. But that’s why downstream would want to care. There is actual development cost for everybody in the ecosystem and we have to decide if we’re okay with that tradeoff right now.
As I understand, Calin does have some 80%-ready implementation ready for BCHN. So like I said above, I don’t think it’s impossible for it to lock in this year. My post earlier simply reflects my current thoughts, which are malleable.
I bring up the “lower bound” because I wonder if ticks are the correct abstraction or if it’s better to just do some kind of one-time migration. The tick system “sounds” elegant but I can’t imagine reducing the block time more than once, possibly twice, doubtfully more than that.
I can concede the points about 0-conf education - that wasn’t my main focus anyway. It was more to highlight the idea that we are treating a symptom. Again, I’m not 100% opposed to treating the symptom, because it does come with many benefits. I’d just like to see more affirmative discussion from everybody acknowledging which set of tradeoffs we want to be taking here, and that we all agree the problems have been fully explored.
It is a tough thing, that we’re all trying to make the best decision.
It is a real factor that a one year delay has secondary impacts on the momentum of the proposal (another year of discussing 1 minute blocks? Motivation of BCHA as CHIP author? The world moves on and things change? Just like how now we’d be actually quite disadvantaged if Functions HADN’T shipped this year, which was borderline at around the same time during discussions in 2025.)
As we discussed on the Podcast episode last night, it sounds like the technical aspect is within reach. 3 months isn’t a long time, but it isn’t a short time either - and if the code is mostly written that’s enough time to host it up and test it. And CHIP comes with 6 months to test it on Chipnet and prep the infrastructure as well.
So really it comes down to the social aspect. Is there a strong enough conviction & appetite for action vs letting things play out another year in the community? For this, I really think we just need some better data (like a https://consensus.health clone for 1 minute blocks) - and that would be very very informative to everyone. At the moment we’re still a little blind and uncertain, but that shouldn’t be super hard to shed some light on. Suddenly it might become visible that the silent majority is actually in favour, or are ambivalent, or even against - and that would make the path forward a lot clearer.
One final important point is that @bitcoincashautist, it is a big burden to get a CHIP over the line so I understand it would be frustrating to miss the window. But I think I would continue to champion the proposal in your stead (and maybe allocate more of my time and resources towards it) to keep it moving for the following year anyway. So it doesn’t all have to fall on you, it’s not an all or nothing for this year otherwise the proposal dies from exhaustion. A strong proposal will find a new champion if required, and I’m happy to be that person if it doesn’t lock in this year and you aren’t excited to push through for another year on it.
have to admit, this is actually a VERY good idea 
that site was surprisingly effective at cutting through most of the BIP-110 noise – it gave a clear, visual snapshot of where different stakeholders actually stood, rather than letting the loudest voices on either side dominate the narrative. a BCH equivalent could do the same
perhaps /someone with some tokens to spare could ask Kimi to clone the existing site – i’d highly encourage this new platform to apply to ALL current and future CHIPs, not just Faster Blocks
right now there are at least three CHIPs in play for 2027 (EC ops, OP_SIGHASH, Faster Blocks), and it would be valuable to see where the community stands on each of them in a structured way
a VISUAL signal like this could really help in a few ways:
one additional thing i’d suggest (but totally optional, or maybe v2) is that it should allow for nuanced positions (e.g. “support with reservations”, “oppose unless X is addressed”, “need more information”) rather than just for/against – the reality is that many people’s positions on Faster Blocks (and other CHIPs) are conditional, and a binary vote wouldn’t capture that
just my 2 sats 
This is a good point, but raises a concern I had a few years ago.
We do not currently have a documented process for rolling back a change that is live on chipnet but not on mainnet yet; i.e. no process for handling any kind of dispute that arises between November and May. We only have a documented resolution process for between May and October.
From a practical standpoint, it’s simply a matter of not updating the node in May if I disagree with the November changes. But from a social standpoint, we have no measurement or process that would increase confidence that I will not fork myself off of the network by doing so.
Ideally we never need to deal with that scenario, but it’s probably worth flagging since we’re already on the subject.
Because that’s not the window for disputes. Only some critical/unfixable bug would require a rollback during that window. Or it could just get fixed in the window and activation would go through smoothly.
Well in a way, if there’s no current literature or decision making around it, maybe it will take that kind of situation for everyone to be forced to reckon with it.
Not saying that’s ideal, it’s just the way things often are - people don’t have a solid answer to a problem until they’ve had the problem. Many such cases.
But maybe it’s worth starting to create literature around that and using this as a test case? I hope it doesn’t come to that.
I’m glad to see enthusiasm for my consensus site idea. I’m working on trying to get something for that up and running, I think it will make a big difference one way or another.
What if we gave the network more intelligence and flexibility, allowing it to periodically elect a number of master servers that would serve for, say, 24 hours? Their addresses would be known only to the network, with no human intervention.
During those 24 hours, these servers would act as priority servers . Once their term expired, they would cease to have priority, and the addresses of the priority servers would change. The network itself would select and elect a new set of machines in advance, according to some randomized and protocol-defined rule.
In Brazil, they managed to create PIX , an extremely fast payment and transfer system, but it relies on centralized infrastructure. I understand that introducing privileged servers goes against the principle of decentralization, and that is not what we want. However, what if the network itself had a fair mechanism for electing servers to act as temporary leaders , with a clearly defined term — a beginning, a duration, and an end?
The network itself could then manage these fast transactions. The elected servers would have a very specific role during their 24-hour term, or whatever duration proved appropriate.
The other servers on the network would continue processing ordinary, smaller transactions and synchronizing normally. However, during the elected servers’ term, heavier workloads could be routed directly to them.
I am suggesting 24 hours merely as an example; the “reign” could be considerably shorter.
This way, the system could remain democratic: there would be no permanently privileged servers, and the network itself would manage the rotation of the machines that temporarily assume these roles — effectively taking the “throne” for a limited period.
A machine would also be prohibited from serving two consecutive terms within a predefined time interval , preventing the same servers from repeatedly occupying these priority positions.
Title: Rotating Priority Relay Set for Bitcoin Cash
Short Name: RPRS
Type: Technical / Peer Services
Layers: P2P Networking, Transaction Relay, Block Relay
Status: Draft / Research
Author: Paulo + Contributors
Consensus Dependency: Preferably none in the initial version
Compatibility: Nodes that do not implement RPRS must continue to operate normally.
This Proto-CHIP proposes an optional, distributed, and rotating priority relay layer for Bitcoin Cash called the Rotating Priority Relay Set (RPRS).
Periodically, the protocol would select a temporary set of participating nodes that demonstrate adequate processing capacity, connectivity, and availability.
These nodes would temporarily operate as Priority Relay Nodes (PRNs).
Their purpose would not be to decide which transactions are valid, produce consensus, replace miners, or modify the blockchain.
Their sole purpose would be to accelerate:
The priority set would have a limited term.
An initial value proposed for research purposes is:
6 hours per term (epoch).
At the end of each epoch, another set would be automatically selected.
No PRN would have authority over Bitcoin Cash consensus.
The fundamental property of this proposal is:
If all Priority Relay Nodes disappear simultaneously, Bitcoin Cash must continue to operate normally.
Therefore, RPRS is an optimization of the P2P communication layer, not a new consensus authority.
Bitcoin Cash aims to provide fast peer-to-peer electronic cash while preserving decentralization and Proof of Work.
Proposals such as Faster Blocks investigate reducing the target block interval from approximately 10 minutes to approximately 1 minute.
As the block interval decreases, however, propagation latency becomes proportionally more important.
Consider:
10-minute blocks
A 2-second propagation delay represents approximately:
2 / 600 = 0.33% of the target interval.
1-minute blocks
The same 2 seconds represent:
2 / 60 = 3.33% of the target interval.
Therefore, reducing the block interval increases the relative importance of:
RPRS proposes addressing this problem at the communication layer rather than introducing a central authority.
RPRS must preserve the following property:
Priority ≠ Authority
A Priority Relay Node has communication priority.
It does not have consensus priority.
A PRN MUST NOT be able to:
Every node continues to independently validate all information it receives.
The network would maintain two simultaneous communication paths.
Node → Node → Node → Node → Miner
This path continues to operate normally.
Node
↓
Regional PRN
↓
RPRS
↓
PRN close to miner
↓
Miner
Both routes operate simultaneously.
Conceptually:
TRANSACTION
|
+---------+---------+
| |
v v
Conventional P2P RPRS
| |
| Priority Relay
| |
+---------+---------+
|
v
MINER
Whichever path delivers the information first wins.
A node may voluntarily announce its availability to participate in RPRS.
Participation does not guarantee selection.
To become eligible, a node may be required to demonstrate minimum characteristics.
Examples include:
These characteristics should be measurable by the network itself whenever possible.
The main danger of this concept is that only large data centers could become selected.
This could produce:
RPRS
↓
professional servers
↓
large infrastructure providers
↓
centralization
Therefore, absolute performance must not be the sole selection criterion.
Selection should consider multiple factors through an Eligibility Score, potentially combining:
Capacity should determine whether a node is eligible.
It should not directly determine its probability of dominating the system.
All nodes must be able to independently determine the members of the next RPRS.
There must be no:
The election should be reproducible using information already known to the blockchain and network.
Conceptually:
ElectionSeed =
HASH(
previous_chain_state
|| epoch_number
|| eligibility_data
)
Each candidate calculates:
ElectionScore =
HASH(
ElectionSeed
|| NodeIdentity
)
Eligible candidates whose scores satisfy the defined selection rules become PRNs.
The selection should not be known too far in advance.
If attackers can determine weeks in advance which nodes will become PRNs, they could prepare targeted DDoS attacks.
Ideally:
Epoch N
↓
Current PRNs operate
↓
Near the end of Epoch N
↓
Sufficient cryptographic information becomes available
↓
Epoch N+1 PRNs become determinable
This minimizes the window available for preparing targeted attacks.
This is one of the most difficult aspects of the proposal.
An attacker could create:
10,000 virtual nodes
and artificially increase the probability of election.
This is a Sybil attack.
RPRS therefore requires some form of Sybil resistance.
Possible approaches to investigate include:
A candidate demonstrates computational work to register its candidacy.
Nodes must build a verifiable reputation over time.
A participant temporarily locks BCH.
A more robust solution may combine several independent signals.
None of these mechanisms should grant consensus authority.
As an initial research value, this proposal suggests:
Epoch = 6 hours
rather than 24 hours.
The reason is straightforward:
24 hours may be a relatively long period if a selected set experiences operational or security problems.
With six-hour epochs:
4 sets/day
With one-hour epochs:
24 sets/day
The optimal duration should be determined experimentally.
A PRN should not remain continuously within the priority set.
For example:
If a node participates in Epoch N:
it cannot participate in Epoch N+1.
Optionally:
it may be excluded from the following K epochs.
This enforces rotation.
For example:
Epoch 100
A B C D E
Epoch 101
F G H I J
Epoch 102
K L M N O
Node A may become eligible again later.
RPRS must never select only one server.
It must select a set.
For example:
64 global PRNs
The selection process should seek network diversity and avoid excessive concentration within a single ASN, provider, or network region.
The exact number must be experimentally determined.
A larger set provides:
However, it also produces:
A serious design failure would be selecting:
64 servers
of which:
50 are hosted by the same cloud provider.
That would provide only nominal decentralization.
The selection mechanism should seek diversity across characteristics such as:
Exact geographic location should not be required.
The original idea of keeping PRN addresses completely secret is difficult to achieve in an open P2P network.
If other participants must connect to a PRN, its address will eventually become observable.
Therefore, the realistic objective should not be:
Secret PRNs.
Instead, it should be:
PRNs that are difficult to predict before election and that can be rapidly replaced.
This distinction is important.
When a node receives a new valid transaction:
No confirmation is created by this process.
It is only relay acceleration.
When a miner discovers a block:
Miner
|
+→ conventional peers
|
+→ PRNs
|
+→ global PRNs
|
+→ miners
+→ full nodes
The primary objective is to reduce:
Time To Mining Majority (TTMM)
That is, the time between discovery of a block and the point at which a majority of relevant hashpower can begin mining on top of that block.
For Faster Blocks, this metric may be more relevant than simply measuring when 50% of all full nodes have received the block.
RPRS should primarily operate with Compact Block Relay.
Rather than retransmitting all transactions:
BLOCK
TX1
TX2
TX3
...
TX10000
the system can transmit substantially smaller block reconstruction information:
HEADER
TX-ID
TX-ID
TX-ID
...
If mempools are sufficiently synchronized, the receiver already possesses most transactions required to reconstruct the block.
This can dramatically reduce the amount of data required for propagation.
RPRS could optionally improve synchronization between mempools.
This is particularly relevant to Compact Block Relay.
The larger the intersection:
Mempool A ∩ Mempool B
the fewer missing transactions need to be requested during block reconstruction.
Therefore:
better synchronization
↓
fewer missing transactions
↓
fewer network round trips
↓
faster block propagation
RPRS does not depend on Faster Blocks.
It can be implemented and tested while Bitcoin Cash still uses a 10-minute target interval.
This property is important.
A safe development sequence could be:
PHASE 1
Experimental RPRS
10-minute blocks
PHASE 2
Measure propagation
PHASE 3
Optimize RPRS
PHASE 4
Faster Blocks on test network
PHASE 5
Compare:
60-second blocks without RPRS
vs.
60-second blocks with RPRS
Only after these experiments should consensus changes be considered.
The project should publish objective measurements.
Simulate simultaneous loss of:
10% of PRNs
25%
50%
75%
100%
The final test is mandatory.
With:
100% OF RPRS OFFLINE
the Bitcoin Cash blockchain must continue operating.
An attacker creates thousands of candidate nodes.
Possible mitigation:
eligibility requirements combined with a Sybil-resistance mechanism.
An attacker identifies PRNs and attempts to disable them.
Possible mitigations:
An attacker attempts to control the peers of a PRN.
Possible mitigations:
Several PRNs cooperate maliciously.
Their impact remains limited because PRNs have no consensus authority.
Full nodes continue validating everything independently.
PRNs refuse to relay a particular transaction.
The transaction can still propagate through the conventional P2P network.
Therefore:
RPRS censors TX
|
X
|
Conventional P2P
|
v
Miner
RPRS cannot guarantee censorship.
A PRN relays an invalid transaction.
Every receiving node independently validates the transaction.
Result:
normal rejection.
Initially, RPRS should not introduce a new token, block reward, or protocol-level payment.
Participation should be voluntary.
Possible motivations include:
Only if voluntary participation proves insufficient should protocol-level economic incentives be investigated.
Legacy nodes:
continue to operate normally.
RPRS-capable nodes may enable:
RPRS_ENABLED=1
and use the additional relay layer.
If a node does not recognize RPRS messages, it simply ignores them.
No rule governing transaction or block validity should depend on RPRS.
The following expression must remain true:
Consensus(BCH | RPRS=OFF)
=
Consensus(BCH | RPRS=ON)
In other words:
the valid final state of the blockchain must be independent of the existence of RPRS.
RPRS changes only:
latency
not:
truth.
Brazil’s PIX payment system achieves very low latency through coordinated and centralized financial infrastructure.
RPRS attempts to obtain some of the communication advantages of coordinated infrastructure without transferring monetary or consensus authority to priority relay servers.
Conceptually:
PIX
Central institution
|
Coordinated infrastructure
|
Settlement / authoritative system
|
Transaction
RPRS:
Bitcoin Cash
|
+------+------+
| |
P2P RPRS
| |
+------+------+
|
Nakamoto
Consensus
|
PoW
The fast layer helps transport information.
It does not determine which information constitutes consensus.
RPRS is not Proof of Stake.
PRNs:
Even if an economic mechanism is eventually used for Sybil resistance, this does not convert Bitcoin Cash consensus into Proof of Stake.
Consensus remains Proof of Work.
RPRS should follow this principle:
Optimization must fail open.
If the optimization fails, the network automatically falls back to conventional P2P operation.
Never:
RPRS unavailable
↓
BCH unavailable
Always:
RPRS unavailable
↓
BCH loses only the acceleration
↓
normal P2P operation continues
Create a simulator with, for example:
1,000 virtual nodes
Vary:
For example:
100 nodes
distributed across multiple regions and infrastructure providers.
Measure conventional relay against RPRS.
Implement RPRS as an optional protocol.
No consensus changes.
Simulate:
Experiment with target intervals such as:
600 s
300 s
120 s
90 s
60 s
30 s
Measure stale rate and propagation performance both with and without RPRS.
RPRS should advance only if it simultaneously demonstrates:
significant reduction in propagation time;
no additional consensus authority;
no mandatory dependency on RPRS;
reasonable Sybil resistance;
sufficient participant diversity;
automatic failover;
measurable benefit to Faster Blocks;
no permanent structural advantage for specific participants.
Before a final specification can be proposed, the following questions must be answered:
How can a Sybil-resistant identity mechanism be built without introducing an authority?
How many PRNs should exist?
What should the epoch duration be?
How can node capacity be measured without allowing manipulation?
How can concentration within a single ASN or cloud provider be prevented?
How can non-manipulable election randomness be generated?
How far in advance should the next PRN set become known?
How can malicious behavior be discouraged without creating a governance authority?
Should there be an economic incentive?
How should the system measure its actual effect on relevant mining hashpower?
What level of propagation improvement would justify the additional complexity?
This Proto-CHIP proposes testing the following hypothesis:
An optional P2P layer composed of rotating, automatically selected, non-authoritative, high-performance relay nodes can significantly reduce Bitcoin Cash propagation latency without modifying its consensus model or creating permanently privileged network participants.
This proposal is not intended to create rulers within Bitcoin Cash.
Using the analogy of temporary “thrones,” these participants do not govern.
They are better understood as:
Temporary messengers positioned on the fastest roads of the network.
Proof of Work continues to determine the chain.
Full nodes continue to independently determine what they consider valid under the consensus rules.
Any participant must remain able to use Bitcoin Cash without RPRS.
RPRS accelerates communication; it does not alter authority over the money.
Concept NACK…
Did you actually think about this at all or did you just tell AI to generate a CHIP for you?