There are 10 types of people in the world - those who know binary and those who don’t | coding DAGKnight https://xitter.cf/t.co/WZfxjGEEgq

Joined April 2023
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.
1
1
8
139
Replying to @michaelsuttonil
Let the fun begin
18
2
100
5,618
Replying to @sudoingX
gonna have to stick to gpus i already have for now for local ai
6
168
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
Here we go again: rehearsing a major hardfork on testnet 10, this time crescendoing into Toccata Activation is scheduled for tomorrow May 18, 16:00 UTC. Existing TN10 miners/operators should upgrade now. In a few hours upgraded p2p nodes will stop connecting to non-upgraded nodes as we enter the 24h pre-activation window. Let’s make the mainnet activation boring by making the TN10 rehearsal as mainnet-real-world as possible
43
228
21
707
36,536
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
20
154
15
393
29,662
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.
Dagknight technical progress I want to share some technical progress related to the dagknight effort. In a yet-unshared post by @michaelsuttonil, the DK effort is split into several iterations: devnet v0, testnet v1 and mainnet candidate v2. v0 is focused on getting a full end-to-end flow running, even if it only partially implements components of the full protocol. v0 progress will be the focus of this post. Since the last update, more things have been implemented such as: efficient k-searching algorithm, gray blocks (to replace representative) among many other technical changes that I will elaborate elsewhere. The most important change since then is that DK can now be run over a dynamic DAG. Rusty-kaspa has a simulation engine called simpa where you can test dynamic DAG conditions. Current state of DK can now run there. There are a few more changes that need to be checked in to fully complete v0. This will happen very soon. The dk branch will also be posted into the main repo once it is cleaned up. A small internal devnet will be set up to test the v0 in a controlled but dynamic non-simulation environment.
26
186
16
494
54,068
Regarding DAGKnight - the cascade voting isn’t implemented yet nor is the code here in any way mainnet or testnet ready yet, but I do have a vanilla static-DAG based impl that has core components of the protocol like hierarchic conflict resolution and incremental coloring in place. I was working on this on a private repo, but what the heck, I pushed it out in my rusty-kaspa fork if anyone wants to see. @michaelsuttonil I think it’s time to share that long overdue post soon. The attached image shows a view of what the DK parent selection looks like from the pov of the next block to be mined (block 64). It correctly selects a parent from the supposed “honest” cluster. The blue line is the VSPC.
I’ve never felt a stronger dissonance between how Kaspa R&D is thriving and how (part of) the community seems to be feeling -- at least on some of my radars, though completely not on others :) TL;DR: Talent and expertise are compounding in R&D, and real work is being done. More concrete updates soon. What I see as the strongest indication of long-term growth is that Kaspa R&D circles are expanding by the day. You can feel it not just growing in size but maturing in spirit as well. More and more contributors, full of passion and a desire to understand, explore, and contribute to the core technology, keep popping up. More vibe-coders opening PRs, more ppl writing KIPs. Parallel research/dev efforts are converging into a single coherent vision. Timelines are clearing up, OG contributors are regathering, and coders-of-stuff are talking about DK’s cascade voting algorithm in their sleep (I have no proof for that, but it can’t be wrong). At the same time, deep core narratives that will lead to near-term products are being polished and understood as we speak. These will be delivered. Kaspa’s main superiority point is taking shape in front of our eyes: fast PoW provides true real-time decentralization (RTD), probably for the first time ever. I know I’ve always been optimistic, but right now the dissonance is especially interesting to follow. Bitcoin has “died” many times, ETH went through its own “is it over?” phases, and Solana definitely felt dead post-SBF -- ppl understandably correlate weak price action with long-term prosperity, even when fundamentals are quietly compounding. Part of my challenge is figuring out how to share that vantage point so more of the community can feel what I’m seeing from up close. I genuinely believe that big things don’t happen in the world without low periods that prove your resilience to yourself and to everyone watching.
18
107
9
425
58,315
PR740 by @IzioDev (and initially by DS) was just merged into the rusty-kaspa repo! This is a significant contribution that allows populated txs to be returned in RPC. It serves a lot of important use-cases needed for integrations such as: - being able to tell the source address (sender) of an accepted tx - being able to calculate the fee paid by a tx when it’s been accepted I’m sure exchanges (which need source address info), apps (like kasia who may need to know senders) and indexers (such as KRC20 which care about fees) would appreciate this info now being accessible. Exposing these properly to RPC required digging and understanding well how things are stored in Kaspa’s node consensus stores. An effort that @IzioDev undertook and pulled through! Kudos to you
16
53
2
231
26,288
Who else just noticed the new look on explorer.kaspa.org? @lAmeR_1337 where’s dark mode?
3
8
69
2,005
Unix epoch begins is at Jan. 1, 1970 00:00. Since it actually shows Dec. 1969 here,my guess is his verified timestamp is stored as -1 in the db (hence Dec 1969).
1
1
73