CHIP-2025-03 Faster Blocks for Bitcoin Cash

#217

This section needs rewriting and clear specifiction: ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab

Chain-Level Floors

Chain-level minimum block size and signature-check floors are not the ABLA limit and are not scaled by the ABLA formula. Where a network defines such a floor, that floor is at least MAX_TX_SIZE and at least the per-transaction signature-check cap, so that no transaction which is valid under the transaction-level rules is unminable. The requirement is stated absolutely rather than as a clamp on a scaled value, because a value scaled below the transaction-level limits is not meaningful. A floor scaled by the ABLA formula would fall below MAX_TX_SIZE on chipnet and testnet4 at the 60-tick target time, making consensus-valid large transactions permanently unminable on those networks.

The above talks about the floor for testnets needing to be MAX_TX_SIZE, and cites that the intention is to make any consensus-valid txn mineable. MAX_TX_SIZE is a miner-only limit of 1MB per txn (and is different than the 100KB per txn for mempool and relay).

Questions:

  • Who cares? It’s a miner only limit. 100KB txns (the relay limit) can still be mined for 200KB 1-min blocks
  • If you do care, you must specify a size that has sufficient margin for coinbase txn + header – and note the coinbase txn is open-ended. Internally BCHN allocates 1000 bytes for this purpose. So minimally you need to specify something like 80 + 1000 + MAX_TX_SIZE = 1001080 bytes as the floor.
  • If that’s the floor WHY ISN’T THIS SPECIFIED EXPLICITLY IN THE CHIP? Why must one infer it from reading this AI generated text?
  • Please consider:
    • What this floor means
    • What it should be
    • If it even should exist
    • And/or how it should be applied
      • Should it be applied after ABLA on chipnet?!
      • Is ABLA ok with being told about a blocksize it is managing having been BEYOND its own internal limits?!?
        • Does the CHIP even talk about this or consider this?!
  • I want to point out that MAX_TX_SIZE has existed in Bitcoin since the BTC days and it was always a theoretical limit and you could never actually even see a txn on-chain that was MAX_TX_SIZE because that size (1MB) was the exact same limit as the block limit (1MB) and you couldn’t even mine a block that contained a header + a txn that is 1MB (with that 1MB blocksize limit in place).
6 Likes
#218

It was an undefined spec gap identified by dagur’s AI, I left that as tripwire so we can discuss it when we get to it, and after some discussion with you: we should not add a special floor and should just let it scale down to 200kB - which can still fit max relay 100kB TXs.

Rationale: chipnet wants limited TPS, so let’s keep the same TPS, even if it means some non-standard TXs can’t fit in a block anymore. Lifting the floor to 1MB@1min would result in 5x TPS over current chipnet 2MB@10min.

Ok, so I’ll just turn that section into clarification that we’re not adding some extra floor and just let ABLA scaling do its 1/10th thing to chipnet’s 2MB base floor.

4 Likes
#219

I’ll just turn that section into clarification that we’re not adding some extra floor and just let ABLA scaling do its 1/10th thing to chipnet’s 2MB base floor.

Sounds good to me!

4 Likes
#220

Chain-Level Floors

No additional floor is introduced: the chain-level minimum block size scales with the target time exactly as every other ABLA output quantity does.
On networks whose base floor is 2 MB per 10-minute block (testnet3, testnet4, chipnet), the post-activation floor is 200 KB, preserving those networks’ designed transaction throughput rather than increasing it.

Consequences, accepted: post-activation usable non-coinbase space on those networks is roughly 199 KB, so at most one maximum-size standard (100 KB) transaction fits per block, and consensus-valid non-standard transactions larger than that — or, in principle, transactions at vm-limits’ maximal structural sigcheck density — cannot be mined there.
This mirrors the situation on Bitcoin prior to 2013, where a consensus-valid maximum-size transaction likewise could not fit a maximum-size block.
The per-block signature-check budget (size/141) scales with block size, so CPU load per second is preserved on every network.
Networks that need higher throughput for testing should adjust ABLA configuration rather than overriding the floor.

3 Likes
#221

How’s this: readme.md · master · ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab

cc @mainnet_pat

based on Calin’s current wip2 implementation branch

3 Likes
#222

The no-ticks alternative is therefore not “the same change minus the abstraction”; it is the same change with the abstraction replaced by N ad-hoc re-derivations of it, each a place to get the rounding wrong and fork.

It’s a good point. The only example I saw of it was coinbase delay. Are there are other cases?

3 Likes
#223

Anything that is evaluated against a block span:

  • nSequence (user-set span)
  • coinbase maturity (span of 100)
  • halving (span of 210k)
  • parking depth (span of 4)
  • finalization depth (span of 10)
  • ASERT (span between anchor and tip)

With ticks, they all smoothly transition through the block time change boundary. No complicated expressions inside individual mechanisms, e.g. nSequcence enforcement is simply "an input is mature in block b if T(b) - T(c) >= 600 * n", where T(b) is the block’s tick value, a pure function of b’s height.

Tick mapper handles T(x) by checking the set tick schedule (just 1 row for our 1st switch 600->60; {H_a, 60}).

2 Likes
#224

FWIW, This comment alone is probably as or more compelling than the current alterntative text in the CHIP. That is to say very compelling.

3 Likes
#225

see updated section :slight_smile:

#226

Just to provide a counterpoint – conceptually to you these are simple because you can unify them with ticks.

To someone that has to implement this – it’s like a NUKE went off in the codebase. Everything got touched.

In practice all that code got hard raped by all the changes. It’s a huge codechange either way. From my perspective as a developer I would have preferred to not rape the following things:

  • Coinbase maturity. Leave it as a height of 100. Scaling it to 1000 is confusing and surprising.
  • Block size. Don’t touch it. Marrying ticks into ABLA feels like incest. Leave it at 32mb blocks every minute. We should be so lucky if we get that much traffic.
  • nLocktime – the height mode should STAY as height. If you meant TiME, you should have used TIME mode, not HEIGHT mode. What the CHIP proposes creates a lot of developer confusion. Good luck calculating nLocktime now if you are a lowly app developer…
  • nSequence – same argument as nLocktime
2 Likes
#227

But my point is that without ticks the same everything would’ve had to be touched – just touched in a different way (inline the arithmetics).

Your list is not an argument against ticks, but argument against touching some places at all – by preserving raw height instead of another invariant (e.g. TPS, target wall clock time).

1 Like
#228

You didn’t read my point.

My point is you touched more than needed to be touched. See my list above where I would have been ok with not touching.

You define the list of things that needed to be touched but that’s a matter of opinion, really, not a hard requirement.

My list was smaller and didn’t need ticks.

What you did was marry lots of stuff now to PoW in a way where it wasn’t explicitly married before. Including block size! Including nLocktime/nSequence!

Is that a good idea? Debatable. Not a given. You think it’s a given, I get it.

We don’t all think that way.

2 Likes
#229

I get your point, just saying it’s orthogonal to ticks. But yeah, you just cutting the list shorter would have reduced the surface and thus reduce relative payoff from ticks.

But should we cut the list? CHIP defends the list. e.g. 2q_x’s apps have >1k BCH TVL and they depend on NOT having height locks unlock earlier than expected.

1 Like
#230

The payoff for ticks would be if we anticipate adjusting the blocktime further in the future. And if we want to marry as much as got married to PoW as you are marrying in this chip.

Minimally I think nLocktime and nSequence should be left alone and still mean height in height mode.

If some contract was using height as a proxy for real world time, when there already is a TIME mode, that’s on the contract.

I think it makes it incredibly hard to reason about things as an app developer to redefine nLocktime the way you have to be some “abstract height in some abstract space where blocks were still 10 mins”.

I get the motivation behind it – you can repeat it to me autistically… but my argument holds.

It’s confusing and makes nLocktime/nSequence very difficult to work with.

Of all the things in this chip – the modification of nLocktime to have a changed meaning is the one I like the least.

3 Likes
#231

He should fix his contracts then. If he cares about time he should use time mode.

#232

Don’t we? Removing the obstacle to further reduction was actually a big thing that helped the CHIP get through.

Me too, because it’s one place where you can’t have it both ways.

Our contract developers don’t seem to have a problem with it. CashScript can abstract this nicely.

2 Likes
#233

I never said we didn’t. Just clarifying that ticks buys us that.

I still think it doesn’t need to be married to blocksize at all. But we have small pee-pees and are afraid to do 32MB blocks every minute… so what can we do?

We marry ticks (and thus PoW) to blocksize, lol.

3 Likes
#234

I mean we had this simple thing – if you care about height, you get height. If you care about time, you can use time.

Now it’s both time. Just weird gay time and normal unix time.

Meh.

3 Likes
#235

The semantics of nLocktime and nSequence are actually the most annoying part of consensus spec. I wish to clean this up one day if we change TX format. Imagine an alternative input field: 2-bit bitfiled + 62-bit integer. You say exactly what you want:

  • block count (or index)
  • tick span
  • real time (MTP)
  • relative or absolute? (since genesis or since coin creation)

and put the number in the 62-bit part.

2 Likes
#236

Even if you do that – Some smarty pants comes along and locks 1K BCH in some contract that uses that as a proxy for wall-clock-time WHEN TIME ALREADY EXISTS AS A THING IT CAN EXPRESS (he just likes height).

And so we want to change blocktime again – do we rescale it then too?

You see what I’m getting at here?

We are making nLocktime hostile to devs now. What nLocktime should I use if I care about fee sniping in the year 2040 when subsidy is very low and fees pay for everything?

I guess I have to calculate it – it’s not obvious. (height - SOME_CONSTANT) / 10 + SOME_CONSTANT.

Not an impossible formula. Just confusing.

1 Like