Just curious

[Just curious @i__amcurious]

Your focus should be protocol, fundamentals, vision. Avoid price charts and PA analyses.

[Hans Moog @hus_qy]

I like! This is a really simple and inexpensive way to significantly reduce the quantum threat to Kaspa users.

Traditional addresses expose the public key controlling the funds. A sufficiently powerful quantum computer could derive the private key from that public key and steal the funds.

KIP-22 proposes a simple change: instead of exposing the public key, an address commits to a cryptographic hash (a fingerprint) of the spending conditions. The public key stays hidden, and unlike elliptic-curve cryptography, strong cryptographic hashes remain highly resistant to quantum attacks.

Only when we spend the funds do we reveal the necessary information for the network to verify the transaction.

There is still a theoretical attack vector where an attacker could intercept a spending transaction, derive the private key, and attempt to front-run the original transaction. But since PoW relies on hashing, which is far more resistant to quantum attacks, the network should remain operational and continue confirming transactions, leaving an attacker with only a very narrow window to act.

Exploiting this would require not just a quantum computer capable of breaking public-key cryptography, but one powerful enough to do this faster than the network converges. On Kaspa, that means just a few seconds. That's a much stronger "theoretical adversary," and it's unclear whether such a machine will ever exist.

Personally, I doubt quantum computers will ever be able to break public-key cryptography at realistic key sizes (I suspect that Hilbert space itself is discrete and has a much coarser resolution than commonly assumed, but that's a different topic).

So TL;DR: KIP-22 isn't a "complete" post-quantum solution, but it's an elegant, relatively low-cost way to significantly reduce the attack surface for quantum adversaries.

[Michael Sutton @michaelsuttonil]

@aKaspamaxi i believe we can get to a stable (and secure) testnet this year

[Olaf Weller @WellerOlaf]

Had a really interesting conversation with Kaspa core developer @michaelsuttonil about the Kaspa Privacy Initiative today.

We discussed our candidate architecture for a scalable shielded native KAS protocol, using covenants, ZK proofs, permissionless relayers and batchers.

One of the biggest takeaways was how much of the infrastructure we're looking for may already be available through Kaspa's Based Apps and KIP-21.

In our original design, one of the challenges was ensuring that batchers couldn't selectively omit user operations while claiming to have processed a complete batch.

With Based Apps, user operations can be ordered directly on Kaspa L1 in an application-specific lane. KIP-21 provides cryptographic sequencing commitments, allowing a properly designed settlement proof to demonstrate that the relevant operations were processed correctly.

That could remove a substantial amount of custom infrastructure we'd otherwise have to build ourselves.

We also discussed canonical bridges, recursive proving and why sharding may introduce unnecessary complexity at this stage.

Our next step is a small Based App feasibility PoC on TN10.

We'll test lane ordering, execution, proof-based settlement, deliberate transaction omission and independent reconstruction before adding the actual shielded privacy logic.

No architecture has been finalized. The goal remains to find the safest, most scalable and most decentralized solution, not to defend an earlier design.

Really appreciate Michael taking the time to share his insights. Conversations like these are incredibly valuable.

Technical feedback, criticism and contributions are very welcome!

https://t.co/h4gdcS1dfn

[Michael Sutton @michaelsuttonil]

@kaspaunchained kaspa is programmable high-frequency proof of work.

i think high frequency is all the rage so to speak. it makes it a continuous composition of highly responsive mini programs

[Michael Sutton @michaelsuttonil]

i think the single differentiating concept is indeed, as many have pointed out, one of “forgery” / “lineage” / “provenance”

a more formal definition might be:

[Michael Sutton @michaelsuttonil]

i’ve written about it in the past but i feel like now it would hit more ears so to speak.

there are basically two categories of covenants, those that are all about the Kaspa they protect (eg vaults, timelocks, escrow etc) and those that are about the state they carry which essentially forms another mini social consensus (eg name services, native kcc20 tokens, and whatnot). one might typically call these stateful covenants but that’s not the full story

instead of diving straight in, i’d like to hear from you. how do you understand the difference between the two categories, conceptually as well as what are the technical implications resulting from the differences

[Michael Sutton @michaelsuttonil]

👀

[Kaspa Kii @KaspaKii]

Safety by construction versus safety by check. Solana DvP documents that creation is permissionless and that a forged record can redirect proceeds, so every funder must verify the stored terms before depositing.

A Kaspa covenant whose address is the hash of the full terms never receives funds at a mismatched address; the failure mode is a non-event rather than a drain that depends on the integrator running the helper.

Smaller operational surface. Solana’s lifecycle includes reclaim, cancel, reject, recover, a permanent tombstone, rent, and Token-2022 constraints. A covenant that refunds statelessly and ignores stray deposits avoids those account and dust paths, which reduces the audit and custodian integration surface, if that is how the contract is actually written.

Commitment versus free option. Solana explicitly allows either party to pull its leg back until the settlement authority acts. Settlement systems that need funds locked once committed need a different rule; a covenant can enforce that, but only if the script does so.

[Michael Sutton @michaelsuttonil]

we have a whole new class of entrepreneurs nowadays. ppl who are passionate about technology but until now did not have enough technical intuition and understanding for actual entrepreneurship.

llms on the other hand are brilliant when guided correctly, but without proper guidance lose the plot

it is critical to bridge this gap and give more and more passionate ppl enough knowledge for guiding llms correctly

[Kaspa Silver @KaspaSilver]

Just messing with covenants on $KAS and I did not fully grasp that what is happening is an address is being created that is owned by no one. It simply an address that is created with hard coded rules of what occurs with the balance that exists in the address.

This address has no private key or seed phrase. (P2SH addresses) Really cool stuff that truly understanding doesn't come around until you start messing with it yourself!

[Kaspa @kaspaunchained]

if a dev says their covenant was audited, you should be able to check that they deployed the code people reviewed.

argent’s covenant genesis proofs let people check a covenant’s original code and setup against its on-chain ID.

the goal is for explorers to show these proofs, so people can inspect what they’re trusting their KAS to.

[Luke Dunshea @elldeeone]

my goal is to reverse engineer our miners

i guess it could be like trying to unbake a cake - you look at the finished tasty cake and work backwards to understand all the ingredients that went into it

i spoke about my goals with this initiative here https://t.co/AEqGUEpF3A

the tldr is, i think it's beneficial to the public (maybe in more ways than i even know) to make the inner workings of the devices you own public

whether this is for being able to take greater control (QOL sw upgrades or even over/under clocking) or even perhaps repair purposes. it needs to be done.

i'm a huge supporter of the right to repair movement and frankly the lack of kb available on these is terrible. if by me burning tokens on understanding the inner workings might benefit someone in future then i'm all for it.

for any nerds out there some notes from now looking at the Goldshell KA Box:

- the controller uart provides auth'd root login (winning) - so no uboot trickery like had to be done with bitmains secure control board

- goldshell uses SPI rather than UART to communicate with the hashboard - so far SPI feels easier to capture and reproduce but this also is likely because the ks5 has ~9x the hashing/ sending results to make sense of

- within a super short time i've got custom code mining real accepted shares on the KA Box - i don't think this would have been possible in this short amount of time without the months of apparatus i built to assist with the KS5 work though

also, i've not forgotten about IceRiver - dw you're next once my new soldering iron arrives - unfortunately the KS0 does not have data lines i can easily tap so i must solder

[Kaspa @kaspaunchained]

the kaspa dev roundup has reached the ‘people might notice if i skip it’ stage.

1 / Argent

@michaelsuttonil shared the first implementation of covenant genesis proofs. these let devs check a covenant’s original code and starting state against its on-chain ID.
https://t.co/BGiQUMQZTz

2 / KCC standards

KCC1 and KCC2 entered a 14-day last call review. they cover shared conventions for covenant data and who can authorize actions. KCC20 still needs its reference implementation reviewed before it can enter last call.
https://t.co/b1Zhlae5dq

3 / dotK

@supertypo_kas released the dotK indexer and API as open source. devs can run their own service for looking up .k names and following registrations on Kaspa.
https://t.co/IXKTevtlpR

4 / research discussion

@WellerOlaf opened a public research repo to discuss what optional privacy for native KAS could look like.
https://t.co/0Y4QtuOJ8b

right. back to my other duties, whatever those are.

[Luke Dunshea @elldeeone]

I want to share something I’ve been working on that I'm calling OpenMiner.

My goal is to understand the chips that power our miners, share what we learn, and use that knowledge to build open software and hardware.

Today, I’m making the OpenMiner Reference repo public. This is the research and documentation repo, starting with my work on the BM2382 chip inside the Bitmain KS5. It covers communicating with the chip, initializing it, sending mining work, and reading its responses, including what I’ve tested and what I still don’t know.

I hope it grows to cover more chips, manufacturers, and miner models. My focus is Kaspa, but I want OpenMiner to be useful for all miners. Other people have different hardware and interests, and I’d love for their research to become part of it too.

I see three stages to this work:

1. Understand the chips. Learn how they work and document that knowledge so others can use it.

2. Take control of our miners. Build open software for existing hardware. I’d like to explore detailed logging and diagnostics, remote monitoring, custom fan and temp controls, and automatic power management based on schedules, electricity prices, solar availability, or other triggers. Over time, I’d also like to work towards power limits, efficiency tuning, undervolting, and overclocking, so we can choose how our miners run.

3. Build new hardware. Explore taking chips from existing miners and putting them into new form factors. Maybe, over time, that leads to miners of our own.

A lot of my inspiration comes from Bitaxe and the people who have contributed to open mining hardware in the Bitcoin community. I have huge respect for that work and would love to see more people able to experiment with mining hardware themselves.

Later, I’ll share the OpenMiner platform repo, where I’ve been turning this research into an open source, modular mining platform. I want it to support different miners, with compatibility growing as we learn about and test more hardware.

I’m going to keep working on this. I’m sharing the reference now because others might want to join in, whether that’s investigating another chip, improving the docs, writing software, or designing hardware.

I’ll be focusing on Kaspa. If your interest is elsewhere but still would love to contribute, I’d love to hear from you too.

https://t.co/pF2mQxz3TD

[Michael Sutton @michaelsuttonil]

argent now has a first implementation of covenant genesis proofs:
https://t.co/u4G36X0lkE

idk how to emphasize this enough, but i expect *every stateful covenant* deployed on kaspa to eventually provide such a proof.

the goal is a verifiable link from a covenant id back to the source code, deployment parameters, and genesis state that produced it.

we should strive for an ecosystem where explorers expose this proof data for every covenant id they discover onchain, assuming its deployers want public trust.

think of it as the analogue of contract verification on etherscan, extended to stateful covenants: you should be able to inspect what a covenant is, audit the code behind it, and verify how it was instantiated.

kudos to @supertypo_kas for being an early-bird example of such a proper deployment process:
https://t.co/B6g9H0C9x1 (not sure if the sil contracts themselves are public yet)

[Michael Sutton @michaelsuttonil]

@markcrypto8 anything

[Kaspa @kaspaunchained]

you can build a kaspa vault that only lets you spend once a price condition is met.

silverscript’s HodlVault example checks your signature and a signed price message from an oracle, an outside source of data.

kaspa checks that the message meets the contract’s conditions. you’re still trusting the oracle to report the price accurately.

the example code is in the comments for devs to build from.

[Kaspa @kaspaunchained]

based apps can use kaspa to order user transactions while maintaining balances and other shared app data off-chain.

the app processes that activity and produces a proof that the recorded instructions changed its state according to its rules.

an L1 covenant checks the proof against kaspa’s recorded activity and validates the update.

the L1 support for this has been available since the toccata hf.

[Kaspa @kaspaunchained]

toccata added a native ZK proof verifier to kaspa’s L1.

an app can do expensive calculations off-chain, then submit a proof that it followed the programmed rules.

a covenant checks the proof and makes sure the transaction applies the proven result.

kaspa calls this inline ZK.

[Kaspa Kii @KaspaKii]

@LevendiPro