The quoted text doesn’t directly answer the question so here goes: 1. GD protocol rules say that you (1) point to all tips you know and (2) propagate blocks asap. (1) makes it so all* tips eventually get pointed at so let’s say you have 15 tips, your mined block is expected to point to all of them. Simply put this process converges. See attached part of the Phantom Ghostdag paper. (*there’s some more nuance to this but I’ll skip that for now) 2. GD and also DK has this concept of “selected parent chain” and particularly important is the **virtual** selected parent chain. This chain has the property that it doesn’t change ordering as blocks confirm apart from near the tips (I’m glossing over details and nuances here). 3. Ordering of blocks is based on this robust chain, so the global ordering is also robust (after some number of confs) Hope that helps.

Let the fun begin

gonna have to stick to gpus i already have for now for local ai

Update: Testnet 10 underwent the Toccata hardfork about 30mins ago and everything’s still running like clockwork. Transition was smooth and seamless. This seamlessness is the standard that kaspa devs set. It’s easy to take it for granted so I want to take this moment to recognize the effort and due diligence that went into making this happen @michaelsuttonil @OriNewman @Max143672 @IzioDev @FreshAir08 @manyfest_ @hus_qy (and sorry if I missed anyone) Mainnet HF soon

Toccata hardfork activation testing in devnet earlier today showed very promising results with a smooth transition. Truly amazing work guys @michaelsuttonil @OriNewman @Max143672 @IzioDev! TN10 hf very soon

Ori explains it here: t.me/kasparnd/1/3690

Dagknight technical progress As would be mentioned in a still unshared post by @michaelsuttonil, the dagknight effort is split into v0 devnet, v1 testnet and v2 mainnet candidate. I’ve been testing the current v0-based implementation in a small devnet with the help of some testers who run nodes and miners with me. The DK work can be thought of as split into two parts: (1) implementing the actual protocol and (2) wiring it up and using it. The testing and development over the last month has been focused on (2). Obviously, DK is a consensus change for selecting parents. What’s not so obvious is that such a change affects DAA, coinbase, IBD, pruning and a lot more. Each of these areas is very sensitive and requires proper understanding to wire correctly. An important consideration and difference from GD is that DK does not focus on maximizing a property like blue work. So to maintain topological properties of blue work, an independent (free) GD implementation is kept running specifically for maintaining blue work. This allows us to keep using the property for topology. Coloring and blue score use the megachain induced by DK. The wiring around DK as of this posting is in a working state, but still needs to be reviewed. Next efforts will be focused on protocol specific components, particularly Tie-Breaking and incremental UMC. Attached are some captures from the internal devnet. The dense DAG image is what happens when things related to DAA or other similar consensus parameter causes a node to insist on their POV. The video is a recent snippet of the KGI running on the devnet showing (perhaps not obviously) DK at work. The current “dagknight” branch is now posted on the main repo. A topic in the Public R&D has been opened for Dagknight development.

@michaelsuttonil @hashdag

From that same whitepaper, section 7

@IzioDev @michaelsuttonil