This is to verify my understanding of Sunlight, before I write a section in faster block’s CHIP “Evaluation of Alternatives”, and to help other interested parties understand it.
Sunlight is a proposal for Bitcoin Cash that takes information the network already produces but currently throws away, and publishes it. The premise is simple: Nakamoto consensus works by making everyone converge on the same chain, but for most of a block interval the network is effectively blind. Sunlight turns on the lights.
This post explains the idea, why it matters, and why it pairs especially well with the move from 10-minute to 1-minute blocks described in CHIP-2025-03.
Basis: “Just a Bunch of Blocks,” presented by Jack at BLISS — BLISS Day Three Live Stream.
The blindness problem
Nakamoto consensus is a self-fulfilling prophecy: everyone sees the winning tip, jumps on it, and expects everyone else to, so it wins. But that convergence only happens between blocks. For almost the whole block interval:
- You don’t know if a competing tip exists.
- You can’t tell which tip has more hash rate.
- You can’t tell whether you’re mining on a losing fork.
- You can’t see a double spend until one version wins.
This is why “one confirmation” is weaker than people assume — it only works because these competitions are rare, not because the network can actually see them. Bitcoin Cash added “parking” in 2018 to reject small reorgs, but that’s a workaround for the blindness, not a cure.
The proposal, in one line
Publish the three things miners already produce but don’t broadcast:
- Relay all blocks, including competing or slightly-shorter tips. Small, easy, small benefit.
- Broadcast work-only weak shares — the headers and PoW of near-blocks (e.g. 1/60 difficulty), with no transactions. This is the cheap layer: it tells you which tip is winning.
- Broadcast templates (tx-level weak blocks) — the transaction list a miner is building on. This is the heavier layer: it tells you what is being mined, syncing mempools and exposing conflicts.
The design principles from the talk are worth keeping in mind:
- Unordered is good. Shares don’t form a chain, so broadcasting them can’t fracture consensus the way faster blocks would.
- More information is good. A share reveals within seconds which tip is winning — and a template reveals which version of a competing transaction is winning.
- Reward publishing, punish hiding. Reorg resistance isn’t only block depth — it’s visible work piled on a tip. A miner who publishes shares on his chosen tip makes that tip look more supported, which attracts other miners and locks in its lead. A secret tip has no visible weight on it, so it looks weaker, fails to attract coordination, and is more likely to be orphaned. And a miner whose shares suddenly vanish from the public tip is itself a visible early-warning signal of a possible withheld reorg. Publishing raises your odds of winning; hiding lowers them.
What you get
- The winning tip becomes visible in ~10–15 seconds, so you can switch early and reject the losing side.
- Early double-spend visibility. Baseline: we already have Double Spend Proofs (DSPs), but they only cover a narrow class — single-key P2PKH conflicts that hit the public mempool. Sunlight widens this: a miner either publishes his templates, which reveals conflicts regardless of script type, or he mines in secret — and secret mining puts him at a reorg disadvantage, because his hidden work adds no visible reorg resistance, and the drop in the public share rate is itself a tell.
- Effective confirmation on the order of seconds, instead of waiting out a ten-minute interval.
Compared to the alternatives
- Faster blocks reduce the wait per confirmation, but they can’t reach second-scale, and they don’t add information — you still can’t see competing work or tx conflicts. (Nervos, for instance, runs 10s blocks at ~3.3% orphan rate, so plain interval reduction still has some headroom — just not down to seconds.)
- DS proof removes blindness only for a specific kind of double spend: single-key P2PKH attempts visible in the public mempool.
- Avalanche picks winners too, but via a new validator set — works, but introduces an unfamiliar consensus layer.
Sunlight is the option that works with the tools Nakamoto consensus already has.
The synergy with 600s → 60s (CHIP-2025-03)
CHIP-2025-03 proposes cutting the block target from 10 minutes to 1 minute. Sunlight isn’t a prerequisite for that, but the two ideas reinforce each other in specific ways:
-
Orphan margin. A 60s block has 10× less time to propagate. Sunlight addresses stale-tip risk directly: when two tips are tied, the share stream exposes within seconds which tip is accumulating more hash power, so the miner on the losing side switches early instead of mining in vain. Doomed tips stop being extended sooner, the chain converges faster, and fewer blocks go stale. The CHIP assumes orphan rates stay under ~2%; this is the mechanism that helps them resolve faster and with less wasted work.
-
Work-per-confirmation. A 1-minute block carries 1/10 the work of a 10-minute block, so “1 confirmation” is economically lighter, and reorgs happen ~10× more often at equal attacker hash. The usual response is to demand more confirmations — which eats the speed you wanted. Sunlight changes the answer: instead of accumulating work, you accumulate visibility. A competing chain is visible within seconds, so low-conf acceptance stays safe on speed.
-
Memory coupling. If shares arrive at a fixed rate, the data you have to hold is roughly
(block_time / share_time) × blocksize. At 1 share/s, a 60s block means ~60 × blocksize outstanding; a 600s block means ~600 × blocksize — 10× more. Faster blocks either shrink the memory footprint or let you run faster shares at the same cost. -
Pre-validation and mempool sync. Today mempools sync by tx inv broadcasts, with no regard for whether anyone is actually mining a tx. Templates change that: the txs that are really being mined propagate ahead of the block, so when the block is announced it’s likely to arrive with no missing txs and no round-trip fetches. That both lets nodes validate the likely block early and removes the “missing tx stalls block propagation” problem on the real block.
-
Withholding. Hiding a block for a double spend costs one block’s worth of work — 10× cheaper at 60s. So the “punish hiding” pressure Sunlight relies on becomes more important, not less, as block time drops.
Implementation reality: the cs_main critical path
It’s worth being honest about complexity, because Bitcoin Cash inherited the Satoshi client and itscs_main lock.
Block relay today is synchronous with validation: an announced block waits for validation, and if even one transaction is missing, propagation stalls until it’s fetched and checked. That’s the part of the code that isn’t fully async.
Tx-level shares would drop more validation work onto that same critical path. Making Sunlight work without slowing down the propagation of real blocks is a genuine architectural challenge — not impossible, but not a weekend patch.
The good news is that the complexity has a natural split:
- Work-only shares (headers + PoW, no txs) are far simpler. They’re verifiable off the critical path, with no mempool or validation coupling.
- Templates are the heavier layer, but they attack the stall at its source: because the mined txs have already propagated, a real block is far less likely to hit the missing-tx stall in the first place.
Work-only shares alone add significant security to 1-confirmation — which is precisely where 60s blocks need help — and they help with the gnarly edge cases: fee sniping and MEV, where early visibility of a competing reorg attempt is the whole game.
A pragmatic roadmap is phase 1 (relay competing blocks + work-only shares), then phase 2 (templates) behind a fully async pipeline once the critical path is decoupled.
References
- CHIP-2025-03 Faster Blocks for Bitcoin Cash
- “Just a Bunch of Blocks” by Jack — BLISS Day Three Live Stream
Attachments
- Sunlight talk transcript
Sunlight talk transcript
All right, our next speaker is Satoshi Nakamoto.
No, I’m just kidding, but he’s equally mysterious.
Welcome, Jack.
How do I use this?
That’s it.
This one’s next slide.
Hi, guys.
Mic check, mic check.
Thank you.
So yeah, there’s going to be a lot of diagrams that I have hand drawn.
And it might be extremely exciting, extremely boring, or extremely blasphemous, depending on your angle.
But I am going to go into some of the core mechanics of consensus, how it works, how the proof of work works, and, you know, just investigate some possibilities about it.
This is a review of how Bitcoin, you know, around 2017, how Bitcoin works.
And to a very large degree, still how proof of work works today.
Which is, you know, everyone knows how—you know, anyone who has given Bitcoin.pdf a read knows how it works.
You know, longest chain wins, with an asterisk that, oh, it’s not really actually longest.
It is block weight, blah, blah, blah.
But yes, the longest chain wins.
And how exactly does this longest chain win?
So, um, if you have a longer chain, your node will ignore a shorter tip that is not on your same tip, even if it comes in.
Um.
If some guy tries to extend that shorter tip, you will still ignore it.
And then, if it’s the same length as your tip, you will still ignore it because you have seen your side first.
Right up until the point where, if the guy becomes longer, then you will doubt yourself.
Apparently, a lot of people are mining on that tip.
And then I should probably switch.
And then that’s exactly what you do.
And then you add to that tip, and then that tip becomes longer.
So there were some modifications that happened since then.
And this is kind of what we have today on BCH.
So some people might have remembered around the time, around, you know, late 2018, something happened that made people doubt BCH’s security.
It was a terrible and very unpleasant event.
And in that event, the attacker complained that we made the chain more secure, which made his attack fail, and he spent a lot of money on that attack.
And this was how it was done, for the first stage.
There are more stages to this, but I will just skip them because they are basically the same mechanism.
So remember from the previous slide that the moment a competing chain becomes longer, we will switch to it.
No questions asked.
Well, in 2018, we pondered the question: what if we simply don’t switch to it?
That is exactly what we have done.
If we have a four-block lead and a chain comes in and tries to reorg more than four blocks, it becomes a lot harder, and it becomes even harder the more blocks they are trying to reorg.
So in this case, for example, if someone is trying to reorg my four blocks with five blocks, that’s going to fail.
My node would park it.
I say, okay, I have seen that, but it would not do anything.
Until it just brute-forces the shit out of it and goes straight to like eight blocks, nine blocks, ten blocks—okay, fine, fine, fine, we’ll do it, we’ll follow you.
But that is a lot harder.
Once you hit a ten-block reorg, you’re just not going to do that anymore, no matter if he throws you hundreds of blocks.
So that is kind of the status quo on BCH.
So it is less pure.
Um.
It is less pure.
It is in some sense already a jump from the purely, you know, longest-first regime, but it is effective.
It is useful.
It meant that our exchange confirmations are generally ten or twelve blocks instead of one hundred or one hundred twenty blocks.
So when we have competing tips, if you dive a little deeper, what does proof of work actually do?
In this case, the basis of security on proof of work is that if a longer chain is broadcast around, everyone who sees that—they need to see it first—will jump on it, mine on it, and compound on it.
So, for example, if I have a tip, and it spreads really fast.
But it spreads only to three-fourths of all the mining nodes before a competing node emerges.
It could be malicious, it could be not.
You know, it could be malicious that, oh, he just doesn’t like my block, he wants to out-compete me.
You know, it could be innocent.
He just never heard my block and somehow came up with the block.
That happens all the time.
It’s called an orphan.
You know, you go through the history.
It happens all the time.
It doesn’t matter.
I have reached more mining nodes or more hash power.
So you enter a competition, and more miners are going to mine on mine.
And there is a higher probability that my tip is going to get extended.
And the moment I extend my tip, the expectation, the consensus, is that everybody would jump on the longer tip.
And it becomes severely disadvantageous to mine on the shorter tip, because you expect everyone else to do the same.
And so the effect compounds, and that’s how we get a longer-is-better regime.
As long as there is a general expectation that everyone is going to jump on the longer chain, then it becomes a self-fulfilling prophecy.
All right, that is the review of what has been going on so far.
And then I’m going to say some blasphemous stuff.
So the first thing is that if you dig a little deeper, you will realize that the proof of work mechanism, the Nakamoto consensus, is very brilliant.
But at the same time, Satoshi did the bare minimum.
He went, he got it to work, and did nothing more.
So a quick glance at the white paper will lead you to the quick conclusion that—okay, this is something that not just the white paper says, but also people repeat the point everywhere else, on arguing why the Nakamoto consensus is inefficient or whatever it is—that for an attacker to catch up to a chain, it requires that he spend the exact same amount of proof of work as the chain that he’s catching up to.
So the basic idea behind this is that, well, it is a distributed, it is a decentralized network.
Who are we to tell who is an attacker and who is on us, right?
So it is only fair for him to spend the exact same amount of proof of work to catch up as, you know, to defend.
Well, I mean, there is a very simple criterion that we ingrain, especially using the compounding effect that I mentioned before.
The compounding effect relies on the fact that everyone has seen the longest tip and jumped on it.
It is actually implied that the thing that everyone has seen is the honest one and you should jump on it.
The only reason why that is not explicit, and we still have the longer-chain-first thing, is because of latency.
You know?
A lot of times there is high latency and you actually don’t know.
But you can know to a reasonable degree, and that is why Bitcoin Cash has this defensive mechanism that kind of relies on the fact that past four or five blocks, it becomes extremely unlikely for this to be a latency thing, and you will need to prove yourself a lot more.
Um.
So, you know, we can tell much better than this, but instead, for the most part, to some degree on BCH and to a much larger degree on BTC, we still do things assuming that it’s nuclear apocalypse all the fucking time.
And, yeah.
And not only that, there are other numerous points where we just outright favor, you know, things that everyone has seen, you know.
We have checkpoints encoded in every node, including BTC.
And there is the final thing that, okay, yeah, maybe all you have said is true, but, you know, why does it matter?
If six confirmations is good enough for this amount, that’s what the white paper said.
Well, six confirmations for DeFi in this economy, really.
Not only that, there are some other implicit things hidden in propagation that are kind of not mentioned in the white paper, but it is just how it is because it works well enough.
But it’s super annoying.
Which is that if I have two competing tips that are of the same length, you could argue that, okay, if I see a shorter tip, I maybe don’t need to bother anyone else with it.
It’s just garbage.
People should never be expected to jump on it anyway, so I shouldn’t give a damn about it.
Well, if I have two competing tips, um, you only actually forward the one that you have seen first.
The other competing tip is kind of like, okay, I know about it.
I’m not going to tell anyone else about it.
This creates a situation where a good part of the network, depending on their connectivity, might actually never be aware of any competition that is going on.
And so, you know, if they are not aware, they will only know the moment this is resolved by the next block coming in.
Who is actually winning.
That might take ten minutes, twenty minutes, whatever.
So when you see your transaction included in a block, one confirmation, it actually kind of tells you less than you think it is.
And this actually becomes worse if you have shorter block times.
These competitions will become more common.
And it is kind of a miracle that we are able to tell people that, oh, we have one-confirmation security at all.
And it basically only depends on the fact that these competitions happen very rarely.
And even when they happen, it is likely that they are honest competitions and your transaction is going to be in both.
That’s basically what it is.
But one confirmation doesn’t mean that you actually have one-confirmation security.
So the fact that the network doesn’t forward everything means that there is a good chance that you don’t know about them.
All right.
So all the previous things, the fact that Satoshi did the bare minimum on those things, means that we have less information than what we could have.
So there are a bunch of things that we would not know until much later.
So, you know, if we have two tips, which tip is actually currently winning?
We don’t know until the next block.
Um.
So before 2021, we also didn’t know if there was a double spend somewhere.
And then in 2021, we improved on that.
We have DS proof.
And DS proof, I will not go into the details, but by relying on a certain amount of first-seen fidelity, it works well.
It works well enough for a number of good use cases, and it is awesome.
But in other proof-of-work chains, we still have no way to tell if we have a double spend unless you pull a BitPay and connect to basically all the nodes.
Is someone trying to reorg us?
I don’t know.
How much hash rate do they have?
We can tell, like, way later after the fact, but not right now.
And if we have a competition, we have seen our tip first.
So the default is that we ignore the other guy and mine on our own tip.
But because we don’t know who is winning, we don’t know how much hash rate people have, we don’t know if we are the baddies.
We don’t know if we are the bad guy.
Maybe we are the bad guy.
Maybe the majority is some other guy.
We are the ones causing trouble.
We should switch over.
We should just stop this immediately.
We have no way to tell any of this.
So this is just a diagram.
So if you have two competing forking tips, you can’t tell between them.
And if you are mining on the losing tip, maybe you want to join the winning side early.
And in fact, some mining pools already do this by inserting, you know, stealth workers into somebody else’s mining pool.
It’s kind of a very janky way to do this all, but, oh, yeah, and, uh, Antpool and F2Pool are mining this tip.
Maybe I should just go over there.
It does sometimes happen, but it is a very janky, not public, and totally terrible way to do this.
And then it follows that for the mempool, if you have one copy of the double spend, you also have very little way to tell, like, okay, what’s everyone else mining?
Maybe for the sake of the payment, I should not mine the thing that I have at hand because it came like ten seconds later and it’s clearly not going to be a thing.
And I should just go over to the other side and make everyone a lot happier.
I can’t do that.
Um.
So, in the following slides, I would propose that instead of just a leak of sunshine, we give all the actors a lot more sunlight to force out any potential attackers and make everything go a lot smoother.
So for recap, there are a lot of mechanisms in place that already favor doing things in public.
We are, you know, this is not a novel concept.
It is already not the case, you know, that if someone digs up a chain that goes back three months, they can just plop it on the blockchain and tell everyone on BCH to go to his chain.
That is already not a thing.
And it doesn’t just apply for three months.
It applies forever, even just beyond ten blocks.
And so we have to ask, okay, so the basis of all of this is the first-seen rule and the compounding effect.
So it already favors publishing your information early, except that you are not allowed to publish certain things.
What if we make people publish those?
And then you would naturally come to the point where, okay, there is a very simple and straightforward way to publish all the things, which is to make the blocks a lot faster.
It has its place.
And we can debate that, okay, you can make the blocks go five minute, two minute, one minute, and it will be fine.
And things would go, you know, at least the users would be a lot more comfortable.
Their life would be a lot better.
But you can’t go on forever.
You can’t have ten-second blocks.
That’s not a thing.
And the reason that is not a thing is because blocks, by their nature, exist as ordered chains.
One block comes after one predecessor and that’s it.
It would have one legit descendant and the other guys are bad uncles.
Um.
So if you go too far, you significantly increase the chance of really bad competitions.
And if you have really bad competitions everywhere—if you have a two-block-long competition—they will eventually resolve by the nature of proof of work.
But it will be terrible, and the competition that I mentioned just now about one confirmation will become—not only would that become a lot more common, you have two-block competitions, you have three-block competitions, three-block-versus-two-block competitions, where the two-block somehow manages to catch up just by chance.
Everything becomes kind of meaningless and it’s terrible.
So you can’t go fifteen-second blocks, ten-second blocks, that is terrible.
I mean, I guess, you know, if anyone here is into Groestlcoin, they would object to this.
I will welcome any novel mechanisms, but that is my general understanding.
And does anyone here have any understanding of how Groestlcoin works?
No, no, no, okay.
Oh my.
Because I have seen that on mining pools from time to time, and they have ridiculously fast blocks.
I don’t claim to have any knowledge on how well that actually works, or maybe they have hybrid mechanisms or something.
Ahem.
So the first very easy and straightforward thing that we can even do today by simply having the nodes change their behavior at the next upgrade, and it will be transparent and make everything immediately better, is that we should just relay all the blocks.
You know, even if it’s competing, even if it’s a competing tip that we have not seen first, even if it’s a slightly shorter tip, we should still forward it.
And people are like, oh, yeah, but does that make it easier for miners to just switch to it?
Not really, because there is still the expectation, as long as you maintain the expectation that other people are also doing first-seen, it is still on average over the long term advantageous to stay on first-seen.
You know, mining the first tip that you see, but, you know, if you do this, you will now be able to see all the competition.
But that is a very small change with a very small corresponding benefit.
Jack, you’ve got five more minutes.
We’re going to have to move on to—
Oh, fuck.
Okay, I’m getting to the good part.
Give me five more minutes if I don’t finish.
All right?
So the next thing you can do is that, um, at the tip, you can start emitting weaker blocks that didn’t quite make it to the difficulty.
You should still make the node publish and forward and relay them anyway.
It is something—if any of you guys are more familiar with mining—it is something that you will recognize as already being done in a different context.
These are the shares that the miners send to their pools.
Weaker blocks that didn’t quite make it to the top difficulty, but they still send them to claim rewards.
This is exactly what they do already, except that it’s not currently broadcast to the network.
What if we make them broadcast to the network?
And broadcasting shares is different from shrinking block time in that it can come in unordered.
If it’s not ordered, then it simply piles on each tip that is piling up.
It doesn’t quite matter the order they come in, whether S1.1 comes in before S1.2 or vice versa.
So there is no chance of further fracture.
But then it gives you a lot more information.
If you have this information, then after a few seconds, after like ten seconds, it will be immediately apparent to you that, oh, one of the tips is winning.
Maybe I should switch.
Maybe I should switch to the other guy.
And then after, say, fifteen seconds, since there is an expectation that everyone has seen that one side is clearly winning, you can then ban the other tip.
You can enforce that if anyone else is building on the other tip, they are clearly doing something terrible.
You can enforce against that.
And what does this do in practice?
It fixes the aforementioned problem where, say, you have one confirmation, but a lot of times you don’t actually know if you have security that is as good as you think it is.
All right, so a question that I’ve pondered—that part is the easy part.
The hard part is, okay, what if someone just hogs a lot of this signal pile, this share pile, and then just dumps it to you all at once?
Doesn’t that make people switch back and forth and make everything terrible?
No, because we can apply the principle that is already in place in BCH, which is that if you accumulate a certain amount of lead in public, then you can make that proof of work that you have already seen in public carry more weight.
And if people throw in more shares, more signal, whatever, later, and they try to overwhelm you, they don’t carry as much weight.
They don’t carry as much weight, and you have a certain amount of security from that.
And then to make it even more useful, you might realize that those shares, those not-quite-make-it blocks, already carry transactions in them.
So you can actually tell not only which tip is winning, but within a winning tip, if you have two competing transactions, which version is winning.
You can actually know that.
And if you are on the losing side, you might wonder, okay, maybe I should switch.
Yeah.
And as long as there is an expectation for people to switch after a while, after a sufficient lead is piled up, you can start rejecting the failing transaction, such that if another full block comes in that somehow carries that failing transaction anyway, you can reasonably and securely say that that is malicious and reject it.
Remember, rejecting blocks requires not only that you harm malicious actors, but also that you do not harm honest actors.
And I believe that this is the way to do that.
So what does this mean in practice?
It means that because of the unordered nature of the weaker blocks that you are passing around, it can be much faster without incurring the same fracture risk.
So exactly how fast?
I believe it will be in the seconds.
It will be in the seconds, and it will directly correlate to the amount of time it takes for any given piece of signal to reach, you know, 99% of the network, as well as practical bandwidth restrictions.
So that number—I’ve looked it up—Bitcoin Unlimited actually did a measurement of it.
That number is around 2.5 seconds in 2018.
I don’t know how much better or worse it is today.
We should measure it again.
Okay, Jack, you got thirty seconds to wrap it up.
So, some key insights.
I need to get to one very critical slide.
Let me get to it.
It’s not very far.
So, some key insights.
Unordered good, more information good, reward public, punish hiding.
All right?
And then on the question of faster blocks, faster blocks would actually aid this scheme a little bit because it reduces the worst-case load of each piece of signal.
Those guys become smaller because there are fewer transactions piling up.
You can even reduce the block size if you want.
But anyway, it will aid it, but there are practical considerations.
If you do it over two separate upgrades, would it be a lot of just user-space kerfuffle that makes everyone really upset?
And if you combine it, would it be too big of a kerfuffle?
That is something to be explored.
All right.
And then the alternative.
So if you think about it from the information perspective, the old Satoshi consensus just hides information.
Basically you have all this information, but it hides it between ten minutes.
You purposely don’t give anyone—you don’t even forward them.
BCH consensus has meta elements, like it heavily favors mining in public a lot more, but it does so in a janky, very awkward way.
If you have DS proof, then you remove the information blockade for a very specific subset of things, and it’s already very useful for double spends.
But you don’t address anything else.
And you don’t affect the miners.
You don’t affect the ultimate security.
Some other chain has implemented Avalanche on top of their tips.
Avalanche gets you a new set of guys that is completely unfamiliar.
Then they are here to help you: if you have two tips, they will pick one and you will follow.
I guess that works, but yeah, it’s highly unpleasant.
I think we’re going to cut it there, but we will publish the slides and Jack can add extra information later.
Let me have one more sentence, all right?
In seconds.
I think we have a good enough thing that has a lot of potential already today, but we can do a lot better using things that already exist today.
Thank you.
Perfect.
Thank you.
Thank you.
Well done.
Thank you.
And we don’t have time for questions, but you have all lunch to go in extreme detail about that proposal.
I’m sure some of you are going to be keen for that.
Okay, I’ll see you back here at 1:30 for the next session.
- Sunlight slides
slides.pdf (3.9 MB)