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.
Published KIP 22 to help Kaspa users better protect their funds from future quantum attackers by keeping public keys hidden until spending
github.com/kaspanet/kips/blo…
damanik retweeted
just to be clear, there’s a lot going on across many fronts. it’s just not helpful to talk about things before they happen; they simply need to happen, and serious things take time. some serious efforts also won’t necessarily mature for various reasons, which is another reason ppl don’t always lay out their plans publicly (until they happen). i anticipate something of a “baby boom” in a few months, but teams will simply pursue delivery rather than talk
damanik retweeted
Replying to @aKaspamaxi
we’re all in on it and doing our best. it’s a white/yellow/black (research/specs/code) effort happening in parallel with various relationships
damanik retweeted
Replying to @KaspaMobile @thucnghi07
composability between native covenants is ready (and is the key for eg all the dexs you’ll see over kcc20 tokens soon). sync composability between vprogs isn’t
damanik retweeted
KCC-20 has officially moved to Last Call status.
Developing software and developing standards are very different.
Software aims to solve a specific problem. A standard aims to define a general foundation for a wide class of solutions.
A special thanks to @michaelsuttonil , who was there from the start to finish , guided me in how to approach this complex craft.
damanik retweeted
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
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
damanik retweeted
Dia mengira dicintai Rakyat, padahal hanya dipuja para Penjilat
(Tiyo Ardianto, mantan Ketua BEM UGM)
damanik retweeted
Gue rasa para pejabat indo tuh bukan bego. Tapi emang pada dasarnya mereka jahat + nggak peduli aja sama rakyatnya. Taik emang.
damanik retweeted
24 jam sudah berlalu tapi sang presiden yg biasa gemar berpidato tidak ada memberikan 1 katapun tentang kondisi negeri yg sedang kacau balau gempa di NTT dan Sumatra, kerusuhan di aceh dan papua tp berbeda hal dengan MBG dan KOPDES kalau bisa setiap hari dia naik panggung pidato untuk mebanggakan program yg menghamburkan uang tsb
damanik retweeted
Di tengah bencana dan duka masyarakat baik bencana alam maupun bencana sosial berupa kesulitan hidup.
Apakah kalian besok merayakan HUT Kemerdekaan RI yang ke 81 akan kembali menampilkan koreografi joget-joget sebagai pertanda kalian adalah kaum Makmur ?
my first Argent application: a name service and it was incredibly simple to build.
users can mint a transferable UTXO representing a unique name (~=NFT). they can transfer it, or co-spend it with another covenant-based application to prove ownership of that name: it's composable later.
uniqueness is enforced through a compressed sparse merkle tree, preventing the same name from being minted twice while keeping computation low. the tree implementation is useful beyond this showcase, which is another reason why i wanted to share it.
a worst-case sparse-tree insertion may require rebuilding up to 256 levels. @michaelsuttonil suggested exposing two registration paths: a bounded fast path for compressed proofs, and a general fallback. this reduces script size and compute budget hence network fees, in the common case.
reminder that kcc-02 (and soon kcc-03) are still being discussed and so the ownership and authentication model should not be treated as final, as is, it will not be inter-operable across wallet ecosystem, which should be an imminent focus.
this is a proof of concept rather than a full-featured reference name service. the goal is also to give developers and LLMs a concrete Argent example of these techniques.
damanik retweeted
I’m finishing my argent compiler sprint (proof attached) and then I’ll do my best to communicate. Thing is, I think you are not my target audience despite indeed being a very informed investor. Talk is cheap, I want you to be INFORMED through the first serious app launching natively on Kaspa L1 and making you ask yourself “wait, how the hell is this even possible on KAS L1??”























