ProofOfWork

Just a real world resource connected to a digital goldmine

[Yonatan Sompolinsky @hashdag]

@binance,

Thanks for including me in the top 100 blockchain people list, appreciate the signal!

I must decline the Dubai invite though. I do not wish to disrespect, but many of the award voters are avid kaspians who rooted for my kaspa status at least as much as for my research. Let them win or count me out.

Crypto has turned from a euphoric cypherpunk project to a house-friendly casino. You may not be the culprit, but as a top player you hold the lion’s share of the responsibility to correct this, and the October crash your USDe oracle glitch helped trigger adds to what needs to be addressed.

There are three classes of crypto, as @mert put it recently: commercial crypto, casino crypto, cypherpunk crypto. <<Binance should hold a privilege policy for the latter.>> A TBTF CEX should know better and play a different game with hardcore crypto projects.

When binance lists a green frog three weeks post its “launch” but skips a fair-launched-Nakamoto-Consensus-100ms-upgrade-ATH-top-20-the-only-nonbitcoin-marathon-mined project, this is not merely binance rationally calculating; it is also binance molding the market in a way that is alas misaligned with the roots of the movement.

You may feel that kaspa’s sovereign money thesis is boring – that bitcoin is already money and that implementing an internet-speed bitcoin is useless - fine. Wrong but fine. But what’s the thesis for the green frog?

Money is a classic chicken-and-egg product. It is a scam up until one moment before tipping point, “most of the value comes from the value that others place in it.” Considering your resources and influence, I think it's safe to say you can serve as both the egg and the chicken and make it worth your while to push sound attempts towards tipping point.

@cz_binance tweeted recently that “strong projects will be listed.” But binance is part of what defines "strong", it bears responsibility for the market’s compass and impulse and definition of strong. It is not a read-only entity.

Binance listing fees are legit, they are just unfit for category cypherpunk. Kaspa devs and early supporters fairly mined less than half what satoshi and hals mined. We don’t have a 20% ZEC-style founders’ reward or protocol-enforced dev fund; this is not a jab at ZEC and the wonderful @Zooko, who was crashing in my car on a late Thursday back in the low ZEC MC days – if somebody deserves to win it is zooko – but assuming binance is not taking a maxi bet, it should revisit its relationship with hardcore crypto.

We are here through bull and bear, ICOs NFTs XYZs; and we are the source of confidence that restores faith and capital inflow post meme-induced or CEX-induced crashes.

Please fix this.

Thanks again,
hashdag

cc @michaelsuttonil

Exhibit A: Binance Innovation Zone
Exhibit B: 10 bps Nakamoto Consensus

[Michael Sutton @michaelsuttonil]

Raw thoughts re Kaspa’s next big upgrade(s)

You don’t end on a crescendo, and it is no secret that several anticipated upgrades are waiting on the sidelines for Kaspa. Primarily, the Dagknight (DK) protocol and the ZK L1<>L2 bridge. These two major endeavors may look independent, but I see strong merit in bundling them into a single hardfork (reasons below). I also argue this bundled effort is the right window to incorporate the foundational L1 changes needed to support ongoing research into MEV‑resistance and oracle‑voting.

A word on deferring DK to this point. I acknowledge that per past statements we expected to be post‑DK by now. Context for the long delay: (1) after the Rust rewrite, moving from 1→10 bps (blocks/sec) was too natural a follow‑up to ignore, and I dove into ~1‑year of work there. (2) Strong community push for smart contracts; in the absence of formal committees planning the next phase we reasoned that prioritizing smart contract enablement would let a builder community form around the Kaspa app layer, and that unleashing this potential (and its ripple effects) would let us refocus on L1 perfection without bottlenecking ecosystem growth.

This post provides a bird’s‑eye overview of active + upcoming Kaspa R&D efforts and sketches their relation graph.

DK: Dagknight is a ’22 ordering‑protocol research paper by myself & @hashdag; it evolves GHOSTDAG (GD). A (mostly written) follow‑up post will deep‑dive DK across:
- practical benefits / applications of its abstract “no a priori delay bound” property
- a breakdown into four main components → raw development phases
- broader system / consensus implications
- applied research for efficient incremental algorithms (notably the cascade voting procedure)
- protocol (and paper) relaxations / simplifications
- “resistance to Internet chaos”: practical limits + engineering caveats

ZK: In the past year, there has been an ongoing publicly visible effort to establish the landscape of ZK over Kaspa. The results of these efforts can mostly be viewed in Kaspa’s research forum under the L1<>L2 category. Kaspa’s approach is to support based ZK rollups, where “based” means the ZK layers / rollups / dapps fully commit to L1 sequencing—so L1 serves all three roles: sequencing, data availability, settlement. The base mechanisms to support this are largely established. The main area still under heavy research is atomic / synchronous composability (multi‑rollup transactions that land atomically). Explaining the vision and mapping current research there deserves its own dedicated post.

Why bundle DK + ZK: Their technical complexities barely overlap, so development can proceed in parallel and merge cleanly. That’s the engineering case. There is also a safety case: we (strongly) conjecture DK yields faster practical convergence of total DAG ordering. Under normal operation the delta is likely inconsequential; under powerful attack attempts DK’s convergence could be much faster—possibly by orders of magnitude. Faster convergence of total order is especially valuable for smart‑contract systems that are highly order‑sensitive. This further strengthens the case for linking the two upgrades.

Additional elements that should ship with them are support for reverse MEV auctions and oracle voting mechanisms (two of @hashdag’s ongoing research efforts with @yaish_aviv and @elimmea respectively; see his recent Sydney/HK talks), seizing the opportunity to address some of DeFi’s hardest problems using Kaspa’s unique structure. Once full smart contracts are live we will inevitably inherit the MEV + oracle weak spots seen elsewhere. By making a few minimal, high‑leverage consensus changes now, we can “apply the remedy before the blow”. Engineering cost here is negligible relative to DK + ZK while ecosystem upside is large. Here is how we can approach each:

MEV. Proposed approach: reverse auctions in which miners offer kickbacks to users for transaction‑ordering (or bundle) rights. Kaspa’s parallel 10 bps DAG already produces intra‑round competition; formalizing a kickback path captures that value for users instead of private orderflow brokers. L1 requirements are small: add a canonical kickback route and a deterministic auction‑ordering rule in consensus (how to rank conflicting bids; details are still open afaik). Game‑theoretic refinements can follow post‑fork, but a base path should exist in my opinion.

Oracles. The strategy for oracles is to leverage Kaspa’s high bps to enable a robust, real-time attestation network, with data aggregated from numerous miners each round. From an L1 perspective, the main consideration is whether to tie this system to PoW for greater security/sybil resistance. The practical step would be to add miner voting mechanics at the consensus level. This is a low-cost, preparatory change that provides significant future flexibility for L2 oracle designs.

—————

Overall I expect dk/zk branches to begin landing soon in rk’s main repository. Looking forward to this turning into a beautiful decentralized open source coding voyage

[ProofOfWork @ProofOfWork3]

@DesheShai Congrats Shai! Nacho deserves a full and complete family! Best of luck!

[Michael Sutton @michaelsuttonil]

72 hours to a big crescendo moment in permissionless distributed systems, showing that a multi-leader consensus real-world system can achieve block times shorter than global internet round-trip time (RTT) without artificially suppressing the P2P network size or assuming proximity

[ProofOfWork @ProofOfWork3]

He either covertly moved onto or at least his vision helped to inspire an updated version of his Nakamoto Consensus. His vision was clearly a peer-to-peer cash system. The resulting Store of Value was his MVP. $KAS @KaspaCurrency is his inspired GA release. The Crescendo hard-fork is available for adoption exactly 11 days from today. Buckle up! Things will start moving very fast.

[ProofOfWork @ProofOfWork3]

Could be.. but it took me about 20 minutes to get rusty 1.0.0 up with the stratum bridge (Crescendo branch) So if the big guys are taking days it either doesn’t make sense or they are having troubles implementing. Good news is that by moving to solo I’ve seen a 5x in yield, with the hash and diff going down I’m making huge gains (as a home miner). Very excited to see how things work in a 10bps world.

[The OFFICIAL Ultimate Crypto Tournament @UltimateCrypto7]

CHAMPIONSHIP GAME 🥇 of the 2025 #UltimateCrypto 🏆🪙 Tourney:

Which cryptocurrency is better:
$LTC or $KAS?

Only humans may VOTE IN THIS GAME @UltimateCrypto7

Good luck! 🥳 May the best coin WIN!

@litecoin @KaspaCurrency

[ProofOfWork @ProofOfWork3]

@Gr8erGoodMining @CoinMarketCap Awesome if true however .. just because CMC website says something like this doesn’t necessarily mean it is true. It was probably an intern that posted this list. 🤷🏻‍♂️

[ProofOfWork @ProofOfWork3]

@DesheShai PPV? Take my 💰

[ProofOfWork @ProofOfWork3]

@icerivereu 😂 you forgot hashtag #justsayin. Old news from fake @IceRiverMiner. Maybe strange news is good news though! LFG! 🚀

[ProofOfWork @ProofOfWork3]

I have 5 of these units. One ☝️ does this shutdown constantly sometimes multiple times per day. One shuts down randomly but typically will run for up to 15 days before this happens. The other 3 have been running since the day I got them with no issues at all. Power off power on always fixes. I’m running all of mine on 120V. I ordered new power supplies and control boards to see if that helps but 🤷🏻‍♂️ hope @IceRiverMiner is able to fix in firmware.

[Shai (Deshe) Wyborski | Parallel Thoughts @DesheShai]

$kas, I have an inkling some of you might find this development desirable

[Yonatan Sompolinsky @hashdag]

Dropped a technical post on L1/L2 design, atomic composability, and other discussions

Atomic composability sounds like a nuance but it's vital for ensuring defragmented unified shared-state which doesn't force users, devs, LPs to work in isolated rollups

https://t.co/thPeGGbrGl

[Shai (Deshe) Wyborski | Parallel Thoughts @DesheShai]

Hi $kas. @hashdag just dropped a very important post about the L1/L2 zk SC design for $kas he has been fervently working on with @MichaelSuttonIL, @dimdumon, @VolokhIlia, and others:
https://t.co/fAJJc1zeNd

This post, for me, is the ultimate answer to "what is Kaspa good for?".

Not unexpectedly, this is a post written for peers, whereby it is densely written and relies on considerable jargon (sometimes internal jargon whose meaning is left for the reader to understand from context). Here is my best attempt to distill the key point for less technical readers.

The core notion of the entire discussion is atomic composability. In the context of computation, the term "atomic" usually means that an action is indivisible, it is either carried out in its entirety or not at all. The textbook example is transferring money from your bank account -- when you do, two things must happen: your balance is reduced, and the recipient balance is increased. However, we cannot tolerate a situation where only one of these things happened. It is the bank's responsibility to make sure that either all related balances are appropriately updated, or the action doesn't go through at all.

An example that is more on point is cross-chain transactions. Say I want to pay someone some USDT to buy some Kaspa. How can we make sure that either both of us or none of us transfer the money? The current solutions such as CEXes or escrow services are far from perfect, and have been exploited many times by schemers and hackers.

Is it possible to "atomize" this process? To somehow guarantee, cryptographically, that either none or both of the transfers take place? This problem is called "atomic transfers", it is the simplest problem in discussion, and it is already quite difficult. In particular, it requires two disparate chains to depend on one another. But it is more complicated than that: one can think that having an SC on chain A that only transfers money once its counterpart was transferred on chain B could be a solution, but they would be wrong. Say that for some reason the transaction on chain A reverts, would chain B be programmed to return the money? What if it was already spent? Say that the code on chain B had a bug or a malicious backdoor, chain A never checks that chain B transferred the money correctly. If you have both chains observing each other, who is the one to make the first move? You see where this is going.

Atomizing transactions is just one example. Some operation are atomic by nature, you can't "partially" process a simple transaction from one UTXO to another. Either it is processed or it is not. A holy grail of having interoperable SC L2s is the ability to take two atomic operation and transform them into a new atomic operation that does both. This is what we call "atomic composability".

Obtaining atomic composability within a single "logic zone" (a term used in the post, roughly meaning some domain of assets all controlled by the same state) is not trivial, but possible. The real challenge is enabling actions that affect several logic zones in an atomic way. Cross chain transfers are a prototypical example. Currently, the way to wrap one coin in another network is to have a bridge operator that holds on to the wrapped coins and issues tokens on the destination chain. We have to trust the operator to hold on to enough liquidity to allow all users to cash out their tokens if they want to. Such services are hard to establish, centralized and costly.
Imagine if instead we could have just atomized locking coins on one chain while issuing tokens over the other, where the lock can only be opened by burning the tokens. If we had an infrastructure that allows us to atomically compose operations that affect both logic zones (the original chain and the chain holding the wrapped tokens), we could do that!

The trade-off in SC design pretty much boils down to these two extremes:
- logic zones that do not sequence on-chain cannot be verified from the chain, and hence cannot provide atomic composability across logic zones. They thus have to resort to async composability. There are several ways to achieve this type of composability, but the bottom line is that it requires some protocol where each logic zone interacts with the other logic zone and waits for a response. This means that, while working within the logic zone might be very fast, multi-logic transactions become as slow as the settlement times of the involved chains.
- Using on-chain sequencing to achieve composability allows the verifiers of the base layer to make sure all conditions properly holds on both sides before processing the operation, providing the sought-after atomicity. The deterrent to this approach is that on-chain sequencing means that progressing the state of the logic zone is subject to the latency and costs of using the base layer.

This trade-off is a difficult one. Since L1s are limited in their throughput and latency (and since support for on-chain sequencing has to be developed on the L1) we see mostly the former type. However, this is where Kaspa comes in. Given the superior throughput and latency it provides, it could provide us with a best-of-both-worlds solution: providing the luxury of multi-logic atomic composition with internet-fast latency and reasonable operational costs. Or as described in the post: "I think that the construction I’m proposing here extracts the best of all architectures: Bitcoin, Ethereum (rollup-centric roadmap), Solana—an internet-speed version of Nakamoto base layer (verification-oriented), a zk-based computation layer, and a Solana-like unified defragmented state."

(N.B. One point absent from the post that's worth mentioning is that existing chains do not have to migrate to Kaspa to use this feature. There are several possible hybrid designs, such as using the same verification they use today, but adding a component sequencing over Kaspa for the sake of atomic transactions. This is essentially what Yoni meant when he talked about using Kaspa as "a sequencing layer for Ethereum" and it is, in my opinion, a fantastic use case.)

[Shai (Deshe) Wyborski | Parallel Thoughts @DesheShai]

Happy third birthday $kas

[Paul Grewal @iampaulgrewal]

@KaspaKii @brian_armstrong @coinbase @KaspaCurrency @Kaspa_HypeMan @elldeeone @cz_binance Hi Kaspa team.  I'm happy to put you in touch directly with our listings team so they can share further insight into your case.  I've emailed you separately. Thanks for reaching out.

[Luke Dunshea @elldeeone]

15.79 Million Transactions.

That's the total amount of accepted transactions from the @KaspaCurrency network last Tuesday, 22/10.

Since I’m a visual person, I thought, why not create a graph to compare Kaspa’s performance against the old PoW dinosaurs sitting ahead of it on the CMC rankings?

The results are impressive, considering that 15.79 million transactions were conducted using censorship-resistant Proof of Work technology.

To put it into perspective, Kaspa’s transaction volume last Tuesday was 2.1x the combined all-time highs of $BTC, $ETC, $LTC, $BCH, and $DOGE. Even more impressive, this surge was driven by the launch of just one token on KRC20, which saw massive support from the community

I would also like to point out that even when comparing the daily transaction count of $KAS to $SOL, which achieved its highest-ever non-vote transaction count of 53.8 million back in December 2021 (https://t.co/uqzydfUGU5), Kaspa is only 3.4 times slower.

Kaspa is achieving this using PoW at 1BPS on the Layer 1.

Let’s revisit this at 10BPS… We are just getting started.

[ProofOfWork @ProofOfWork3]

@SonOfATech SunOS 4.1.4 the last real OS Sun ever made.

[ProofOfWork @ProofOfWork3]

Congratulations $KAS! Yet another milestone.

[Shai (Deshe) Wyborski | Parallel Thoughts @DesheShai]

Ladies and gentleman of $kas and crypto, I don't think you understand the magnitude of what's going on right now. We are witnessing, for the first time in history, a fully deployed production mainnet of a PoW coin perfectly handling a constant organic throughput of 250-300 BPS, and queues in the tens of thousands.
This is, objectively, the most successful live run in the history of proof-of-work, nothing less.