There are 10 types of people in the world - those who know binary and those who don’t | coding DAGKnight eprint.iacr.org/2022/1494.pd…

Based in North America
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
135
Replying to @michaelsuttonil
Let the fun begin
18
100
5,614
Replying to @sudoingX
gonna have to stick to gpus i already have for now for local ai
6
167
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
709
36,492
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
396
29,607
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
189
496
54,003
From that same whitepaper, section 7
1
4
58

ALT Lotr Maybe GIF

1
14
193
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
108
426
58,280
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
231
26,281
Who else just noticed the new look on explorer.kaspa.org? @lAmeR_1337 where’s dark mode?
3
8
69
2,004
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
Replying to @LevendiPro
The meme
2
7
186
Replying to @LevendiPro
722 public nodes now: nodes.kaspa.ws/
5
24
115
1,607
Compared to when I asked, the number of public nodes has more than doubled - now at over 650 public nodes! That’s at least a few hundred kas community members that took it upon themselves to spin up a node and make it public. It’s not >1000 (yet) but that we grew by this many nodes in such a short timeframe is nothing short of amazing. You guys rock! I am left to wonder how much longer til we light up that map everywhere? Anyway, belated happy 4th bday to Kaspa!
Replying to @OrangutanElder
Can we get that number of public nodes to >1000 before the next kas bday?
7
60
287
13,476

ALT Matt Damon Grandpa GIF

2
66
You and I fundamentally disagree on the fact that L1 should be scalable, but that’s fine. I think L1 being scalable allows for better real-time settlement which opens up a lot of use cases (that are interesting to me). If there are issues arising from this, they ought to and will be fixed. I don’t necessarily think all traffic ought to be in L1. L2s on Kaspa are about to be a thing - and they do have their usefulness. I think block space in L1 being filled is going to be a combination of several L1 txs and **based** L2 txs coming together. All of which fund the miners. On your point about decentralization and burdensome nodes, the specs for 10bps is as attached. We arrived at that by running testnet to max capacity (~3k TPS) and determining which specs still hold. Do you think these are unreasonable specs?
1
1
90
Replying to @elldeeone @brt2412
Here you go
1
4
189
Replying to @LevendiPro
@kaspador_ something you said earlier about mainnet reminded me of this from the Google SRE book: sre.google/sre-book/introduc… “Hope is not a strategy”
1
9
156
Quick question, what does it collect the email address for?
2
1
17
830
Not that archival nodes are necessary for the network to run, but to weigh in on this part, instead of buying such large hardware you can simply buy a disk that’s good enough for slightly over a year (about 42TB based on your math). A 20TB HD in ebay is about $350. If you start an archive, once every 6 months when it is close to full, you can then swap the HD out with a new one and start an archive from that point. You’ll have several physical disks containing your archive that way but you don’t need to spend some large amount all at once.
1
56
> You cant just prune away transactions. Enough runners need to hold all transactions Why? You definitely can prune txs and it’s done securely for kas. Kaspa don’t need archival nodes at all for consensus. The post linked above describes the IBD process which should’ve made it clear why archival nodes are not necessary for consensus. The btc paper even talks about pruning old enough txs. See section 7 (in image here) of the btc whitepaper at bitcoin.org/bitcoin.pdf Kas prunes blocks and txs in a secure manner following the MLS protocol adapted to DAGs. See pruning security proof at github.com/kaspanet/docs/blo… and read about the MLS protocol at eprint.iacr.org/2021/623.pdf
2
4
205
That’s definitely some good specs to run a node. It’s on the beefy side but know that the node can run on cheaper hardware. For anyone curious about the minimum required, it’s documented here github.com/kaspanet/rusty-ka…
1
14
359
Thank you anonymous donor for the blue checkmark gift. I will put it to good use!
7
14
280
6,473
If we go to 4TH (which is roughly a single KS7 lite), you’d get this simulation result which shows you almost certainly get to mine at least one block per day. With these figures one thing is clear: solo mining is viable even with a small fraction of net hashrate.
1
4
37
924
Replying to @realvijayk
What does it take to solo mine in Kaspa and consistently get a daily reward? If you have 2TH in hashrate this simulation says that in a period of 30 days you’d only have about 2-3 days that you might not get rewards while the rest of the days you solo mine at least one block.
3
9
55
5,728
At 10BPS, Kaspa can handle about 150-300 txs per block (so roughly 1.5k-3k per sec) on the hardware specified here github.com/kaspanet/rusty-ka… We tested this prior to the Crescendo HF to determine how low can we recommend the specs to be. I think these specs are easily accessible
1
18
157
Replying to @auzghosty @brt2412

ALT Crossed A Line GIF

3
68
At 1BPS you would’ve seen highly variant results for solo mining. In this simulation, you can see there are some days with no rewards and the days you do get rewards are more erratic. On the 10bps sim side, you have rewards on all days and the daily rewards are pretty leveled out
1
3
16
850
See the streak of 3 days in miner 3 or 2 days in miner 4 with no rewards? Only time will tell if your experience is closer to miner 3 or 4 in this simulation :)
1
4
278
1/ It’s nearly a week after the Crescendo HF now. I made a few interesting mining observations since then. How are pools dealing with the frequent blocks? How does solo mining look like now? Why is the dag so complex? Read all about these in my Medium article linked below
10
94
322
17,234
Follow-up: I have a v1.3.0 dev release with the fix in place. The result for me is as shown in the photo. Dev release link below for kaspa-stratum-bridge. If you’re experiencing a similar issue with the bridge where your asic hashrate dipped, try the build below out.
1/ Regarding solo mining, I noticed my KA box pros dropped a bit in hashrate while mining with my stratum bridge while my KS0 ultras were mining fine. After doing some investigation, it appears that some asics may struggle with receiving several new block notifs/jobs too fast.
6
22
111
4,541
Replying to @RedPandaMining
Looks better than what you’d normally get for the hashrate for the day. Nice.
3
348
If you’re curious about how Kaspa solo mining post-Crescendo might look like for you, I put together a simple site where you can try and simulate your experience. Link below
13
58
274
21,216
Some resources to get started: - Crescendo-ready stratum bridge release at github.com/aglov413/kaspa-st… by @aglovale0x - Video Tutorial from @KaspaSilver piped.video/WHBlwJ2sN7Q - Discord channel to get help on discord.com/channels/5991532…
2
4
26
638
Replying to @AndyBute
A bit of this later to celebrate
4
1
9
109
So much I want to respond to but let me start with: I want to say that one of the things that attracted me to this project is the pedigree and past results of the developers and researchers in it. The faces were there, but the idea and ideals were what I was interested in more.
1
2
56
1,169
All entities with significant hashrate is using v1.0.0. We’re practically at full mining adoption of Crescendo at this point.
34
145
526
21,264
One week before Crescendo. 90% of mainnet blocks are from v1.0.0 nodes. The remaining 10% are from @f2pool @whalepool_com (who are transitioning) and @MARAHoldings (who claims they will upgrade this week). This brings us close to 100% adoption in terms of hashrate.
13
80
336
70,006
Two more weeks before the HF and we’re currently about 51% of mainnet blocks mined with v1.0.0 nodes. The top pools are transitioning so we expect about 34pp more, effectively putting us at 85% of mainnet hashrate support on v1.0.0. The rest are unreachable or unresponsive.
10
65
236
44,769