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
- Tweets1.9K
- Following184
- Followers3.9K
- Likes2.3K
take this opinion with a grain of salt as it is just my personal opinion and shouldn’t be taken as a recommendation. i don’t own a onekey device but iirc they do blind signing. i bought a tangem but ended up not using it because I don’t like the fact that there is no seed phrase and has only a single address. as for ledger, i use it but not as much as other options like cli.
tbh I use kaspium, rk cli wallet and golang cli wallet all because I understand how those work on a code level. mostly i use cli due to easy access to custom scripts such as multisig and easy access for me to modify the wallet as needed
i think it’s important to understand where your trust boundaries lie. for the wallets i use, i at least saw their code and have a good understanding how they work.
especially nowadays with ai it’s easier to dyor
The p2sh support feature has to be implemented on the Ledger app itself to allow for clients such as kasvault, LL, or other such apps to expose that feature in the ux. So yeah, it has to undergo a full on feature impl process
kasvault is only a webapp, same as ledger live/wallet. the real work to support p2sh addresses needs to happen in the app-kaspa embedded app but iirc that’d require a work + maintenance + a security audit (per policy) which aren’t free
Thanks for this, I’ve been testing it at 64k it’s amazingly fast. At CTX=long it’s still performing really well (eyeball figures around 50+tps on a single 3090).
lol, but i’m sure it was still a great retreat. in any case, i’d like to get testnet13 out soon(tm)-ish
To help visualize this “virtual selected parent chain” take a look at the blue line connected blocks here: kgi.kaspad.net/
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.
coderofstuff retweeted
Nice to be back home after 8 days of intense devving sessions with several contributors to Kaspa’s core development, some of whom I had never met before. We exchanged a l o t of information and brainstormed different paths forward and their tradeoffs across several parallel topics.
On a personal level, my public coding activity was somewhat on hold during this period, including Argent progress and coding sessions I wanted to do (and share via @KaspaNative). My next few weeks will center on initiating the DK group effort -- with several ppl joining @coderofstuff_ in his already long journey deep in the trenches (actually, @FreshAir08 is already deep in as well with a very promising incremental cascade-voting algo). Alongside that, I’ll also find time to move Argent towards a release and perhaps take a more active role in helping the ongoing covenant-related spec & conventions work (KCCs) converge
Even with just 24gb vram you could run the qwen3.6-27b already. There’s good info on that here xitter.cf/sudoingx/status/204905…
"how do you fit qwen 3.6 27b q4 on 24gb at 262k context" lands in my dms 5 times a week. here is the exact memory math.
model bytes at idle = 16gb (q4_k_m of 27b dense)
kv cache at 262k context with q4_0 for both k and v = 5gb
total = 21gb on the card
headroom = 3gb for prompts and tool call traces
the magic is the kv cache type. most people leave it at default fp16 or push to q8 thinking quality wins. on qwen 3.6 27b dense at 262k:
- fp16 kv cache = does not fit at all
- q8 kv cache = fits at 23gb but runs 3x slower (double penalty: more vram, less speed)
- q4_0 kv cache = fits at 21gb at full speed (40 tok/s flat curve, same speed at 4k or 262k)
most builders never test the kv cache type because tutorials never mention it. it is the single biggest unlock on consumer 24gb hardware.
flags i run:
./llama-server -m Qwen3.6-27B-Q4_K_M.gguf -ngl 99 -c 262144 -np 1 -fa on --cache-type-k q4_0 --cache-type-v q4_0
what they do:
-ngl 99 = offload everything to gpu
-c 262144 = 262k context window
-np 1 = single user slot (do not enable multi-slot, eats headroom)
-fa on = flash attention on (memory and speed both win)
--cache-type-k q4_0 --cache-type-v q4_0 = the unlock
if you are sitting on 24gb and not running this config, you are leaving 250k of context on the table. or worse, you are running q8 kv cache and burning 3x your speed for nothing.
q4 is not a compromise on consumer hardware. it is the right call.
Sounds like the right amount of time for a full-on dk conceptual deep dive. Good thing you got it recorded, as you’ll need to go over it maybe 3-4 times to absorb it.