Yes its harder. Ok its been a LOONG time, but if I remember correctly: The way I read the algorithm, and if I understand what you mean by "dripping": to keep both branches "alive" in a node, you need to keep them within the "parking" range. Giving some blocks to the nodes (but not all of them) — "dripping" your blocks — keeps both chains within the "parking" range until you can force a split at the finalization depth.
A
What you also might take from my paper is that I do not just make an unsupported analysis. I encode the algorithm into a Markov process and run an exhaustive analysis of the probabilities.
From your analysis, which I've just read quickly: "The moment a 4-block secret chain appears, the network is alerted to an ongoing attack. Surprise 4-block reorgs do not happen by accident, and neither do 4-block orphan races (Stone's dripping attack would look like a prolonged orphan race that refuses to resolve)."
I think you need to be a lot more precise here. For instance, there is no "the network" — there is no entity that is "the network". There are only full nodes following an algorithm (unless you are talking about human intervention). I don't think there is an algorithm that you can run on a full node that can distinguish the difference between my attack and rare "natural" occurrences like netsplits (perhaps politically caused), and also you can't tell which side of such a split is the good one or the bad one. So if your full node makes an earlier conclusion about the forks based on an advertisement of an "attack", you effectively just reduce the finalization depth, which makes it EASIER, not harder for an attacker to get lucky with less hash power and cause the split.
A
(or if you CAN do this — determine early on which is the "bad" fork — then your analysis should state the local full node algorithm to do so very precisely!)
There's no algo that can resolve this, you paper is correct, I just highlight there's this practical obstacle of human participants who'd be alerted by an odd 4-long race
Yes, but in Satoshi consensus there is no possibility of a split (partition tolerance). There's this idea called the CAP theorem which says pick tradeoffs between consistency, availability and partition tolerance (ability to heal after a partition). Satoshi consensus is inconsistent, always available, always partition tolerant. Finalization&Parking is inconsistent (but consistent for data > Finalization blocks deep), always available, and does not have partition tolerance. My paper investigates how bad the partition intolerance really is.
And a final issue is the actual split attack attacker hash power could be probabilistically much lower than the 33% needed for a split, if you have a network advantage (which is relatively easy to engineer and cheap compared to hash). You use your (say) 5% hash and a network connectivity advantage to "carry" 50% of the rest of the network into your fork. Then you shift your 5% hash between forks to keep them within the parking range of each other (both forks are in unstable equilibrium if you managed to split the miners, so your 5% goes a long way towards stabilization) until finalization.
Yeah, if his 1st block splits the network 50:50 then you can say the hardest part is done, and he can use his 5% to try maintain the instability until parking lock in, but there's still a good chance of this resolving before 4 blocks when either side gets a 2-block lead
Tricky part is in even learning exact hashrate behind node IPs (although there is a method, that has been recently replicated but only managed to pin down 50% to 200 "influential" IPs: https://github.com/Crypt-iQ/crypt-iq.github.io/blob/master/coinscope-post.md#mempool-partitioning-and-identifying-mining-nodes)
The other tricky part is in betting on hashpower not changing due to a race; miners who have skin in the game can add more hash to increase chances of victory, and attacker has no way of knowing how much either side has in reserve
B
ah wait, actually the moment either side wins +1 the other side (everyone except the attacker) should switch to that tip, unless attacker can prevent or slow down propagation until he has a competing block ready,
Consider what it takes to reach the lock-in depth:
| Step | Chain A | Chain B | Lead | What must happen to continue |
|------|---------|---------|------|------------------------------|
| 1 | 101 | 101 | Tie | — |
| 2 | 102 | 101 | A +1 | B must ignore A's lead, keep mining |
| 3 | 102 | 102 | Tie | — |
| 4 | 102 | 103 | B +1 | A must ignore B's lead, keep mining |
| 5 | 103 | 103 | Tie | — |
| 6 | 104 | 103 | A +1 | B must ignore A's lead, keep mining |
| 7 | 104 | 104 | Tie | Depth 4 reached, lock-in |
Each "must ignore" step is a deliberate choice to deviate from default policy.
Nexa 100k TPS & Talistor are Ferrari engines, but a 4-year halving is a lead anchor. Copying BTC in 2026 isn't "loyalty," it’s myopia. Kaspa, ICP, already proved scarcity wins. Tech is nothing without economic survival. Don't be Kadena 2.0.