2027 protocol upgrade ideas

#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.