2027 protocol upgrade ideas

#47

it’s bs strawman “arguments” like this that hold back progress, smh – and i’d really LOVE to see 1min (or even 2min) BCH blocks; so i’d like to point out “the obvious”

tl;dr – you’re criticizing a protocol (BIP37) that is already being superseded by a design that specifically solves the batch‑request and privacy problems :point_down:

main points of bips 157 & 158:

  • the full node pre‑computes a small (~20 KB) deterministic filter for each block; essentially a compressed list of all relevant scripts
  • the wallet can request ranges of these filters in a single request, download them in one go, and scan them locally to decide which blocks it actually needs
  • there’s no “search n, wait, search n+1” nonsense; the wallet just says “give me filters for blocks [500 000–520 000]” and processes the stream at its own pace

the overhead you identified, round‑trips multiplied by block count, nearly disappears!

so for example, even with half a million blocks a year (a 1‑minute block time), syncing a month’s catch‑up would involve downloading ~800MB of filters – a modern 5G connection handles that in under a minute, and the local scan can run in parallel and entirely OFFLINE!

bottom line, imho, YOUR wallet is just too f’n slow – so please don’t blame the network for advancing past your limited capabilities :unamused:

cheers!
:beers:

5 Likes
CHIP-2025-03 Faster Blocks for Bitcoin Cash
#48

It can do the same with BIP-37. Wallet can request multiple merkleblocks in a single request, node responds with a stream of responses, no round-trips for each response. So, increasing number of requests in the batch speeds things up.

Yes. I tested with Tom’s codebase, he can get a ~10x speed-up by changing 1 lline of code, which he refuses to do.

I changed this one line from 9 to 99 and recompiled:

m_merkleDownloadTo = std::min(m_merkleDownloadFrom + 99,

And who could’ve guessed, the wallet jumped from syncing about 5 blocks / second to 50 blocks / second!

Can’t believe that this simple speedup eluded Tom for 15 years :roll_eyes:

When I told him about it in a Telegram group chat, this was the reaction:

[5/21/26 7:37 PM] bitcoincashautist in reply to Tom Zander:
> ‎⁨The wallet wants the server to examine "all transactions since...
just change this one line of code man, change this number from 10 to 100
https://codeberg.org/Flowee/thehub/src/branch/master/libs/p2p/Peer.cpp#L373
[5/21/26 7:38 PM] Tom Zander in reply to bitcoincashautist:
> ‎⁨just change this one line of code man,...
Can you please not be so super amazingly denigrating to someone that actually built that code for years and has been building tech in this space for more than 10 years.

"just change the number, man!".

It is not helpful.

Anyone can change the same line, recompile, and test for themselves.

“SPV can’t handle 1‑minute blocks” claim is based on a self‑imposed bottleneck, not a protocol limit.

4 Likes
#49

First principles and a decade of experience, with a significant amount of experimentation and testing on figuring out how hard you can push one lever before another starts biting you in the ass.

It is a tad more than theory in that way.

#50

What say you to this, @tom? The chat log that BCA posted doesn’t explain what’s wrong with that solution.

2 Likes
#51

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.

#52

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.

2 Likes
#53

Don’t confuse bandwidth and latency. It is the latency that gets you.

#54

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

3 Likes
#55

bwahahaha :rofl:

good luck with that :pray:

2 Likes
#56

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.

4 Likes
#57

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 :slight_smile:

2 Likes
#58

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.

1 Like
#59

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.

3 Likes
#60

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.

#61

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.

source

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.

5 Likes
#62

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.

2 Likes
#63

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.

1 Like
#64

have to admit, this is actually a VERY good idea :clap: :+1:

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:

  • it would surface the “silent majority” – people who have an opinion but haven’t spoken up in the threads
  • it would give CHIP authors concrete data on whether they have enough support to push for lock-in, or whether more work is needed
  • it would help distinguish between genuine contention and mere lack of visibility/awareness

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 :smirk:

#65

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.

#66

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.