4. XXIM Interviews Ori Newman

Chapter 1: Introduction and Ori Newman's Background

• Ori is one of the early developers of Kaspa, having participated in Kaspa development as a core member of DagLabs since 2017, and as of 2025, still contributing to Kaspa.

Chapter 2: Ori's Background: Early Bitcoin Journey (2013)

(1). First Contact with Bitcoin (2012-2013)

• Ori first encountered Bitcoin around 2012 or 2013, primarily influenced by libertarian ideology—at the time he deeply studied libertarianism, and while still paying attention to the field, his focus gradually shifted to cryptocurrencies.

• Two core points that attracted him to Bitcoin: first was the censorship resistance feature, meaning no one can interfere with transaction sending; second was the fixed monetary policy, with the censorship resistance feature being most attractive to him.

• In 2013, Bitcoin's price rose significantly, and he believed this was related to the Cyprus crisis—at the time, the Cypriot government confiscated funds from banks, causing some public panic, which in turn drove Bitcoin to form a bubble. This event prompted him to want to understand Bitcoin better. Additionally, he had used the "Silk Road" platform.

• He recalled that around 2013, countries like Greece and Cyprus faced economic crises and debt problems (Spain's crisis came slightly later, with Greece's problem being most severe), which also indirectly made him pay more attention to Bitcoin's value.

(2). Early Bitcoin Community Experience and Technical Exploration

• Ori first purchased Bitcoin through the IRC (Internet Relay Chat) platform, which had a reputation system: users needed to complete multiple transactions, and each transaction would increase their reputation score. This "cyberpunk" style experience impressed him.

• In the early days, he had misunderstandings about Bitcoin's technical principles, spending quite some time to understand its core implementation logic, but continued to follow Bitcoin's price and related dynamics for several years thereafter.

• When Ethereum launched, he was excited about the "world computer" concept; in 2016, he began deeply researching Ethereum's technical details, and the deeper he went, the more fascinated he became, even entertaining the idea of quitting his job to work in cryptocurrency-related fields—previously he worked as a full-stack developer, believing such work lacked appeal, while in his eyes, cryptocurrency was a "new revolution."

(3). Turning Point to Enter the Cryptocurrency Industry (2017)

• In 2017, Ori met someone at a party who, upon learning he followed cryptocurrencies, proposed "let's improve Bitcoin together, participate in hackathons to compete for championships," and the two subsequently collaborated on improving "Brainwallet."

• Brainwallet at the time had flaws: before the advent of mnemonic phrases, users needed to generate private keys through passwords. While this facilitated memory (such as being able to carry assets by remembering passwords without hardware wallets), the entropy of human-chosen passwords was low and easily crackable. For example, Yonatan Sompolinsky had tested generating brain wallets with simple passwords like "1234," and the assets deposited were stolen within seconds.

• Their improvement approach was: referencing BIP39 mnemonic phrases (but mnemonic phrases were too long and hard to remember), designing automatically generated short character (such as 6-word) brain wallets. Although generating a wallet took about 30 seconds, it could significantly increase the cost of brute-force cracking.

• During this experience, Ori also compared the Bitcoin community of 2013 with that of 2025:

  • The early community was open to altcoins, not rejecting the idea of "improving on Bitcoin" (such as Satoshi Nakamoto once proposing using Namecoin to implement blockchain domain registration), with a strong innovation atmosphere. Even if there were unreasonable ideas (such as "supernodes"), everyone was willing to discuss.

  • The Bitcoin community of 2025 is more closed, with "maximalism" discussions prevalent, and excessive focus on price, with decreased attention to technical progress. Although there were technical disputes related to Core, community topics almost revolved around price fluctuations.

  • He mentioned that some Bitcoin developers didn't agree with the view that "Bitcoin is only for value storage," but due to the block size debate (developers maintaining decentralization by insisting on not expanding blocks, leading to decreased payment usability of Bitcoin), community leaders gradually took an evasive attitude toward the "payment function," which also indirectly led to a shift in community culture.

(4). Process of Joining DagLabs

• In 2017, due to the Bitcoin block size debate, Ori leaned toward supporting Bitcoin Cash, but wasn't an extreme supporter, only believing that "better scaling trade-offs needed to be found."

• At the time, he was active in Israel's Facebook cryptocurrency discussion groups, where most Bitcoin supporters in the group advocated "expanding blocks," while he and Mike Zak were among the few with different opinions, leading to their intersection (the interviewer had previously interviewed Mike Zak as well).

• Later, Ori and the partner he met at the party won the hackathon championship and even made it into Israeli newspapers. After Mike Zak saw the report, he recognized Ori as the discussion subject in the group and invited him to interview at DagLabs. Ori eventually joined DagLabs.

• When asked "why not join the Bitcoin Cash or Bitcoin SV team," Ori stated "first, I obtained a job opportunity at DagLabs; second, after deeply understanding DagLabs, I realized the drawbacks of expanding blocks, and was attracted by the advantages of DAG (Directed Acyclic Graph) protocols."

(5). Recognition of DAG Protocols

• Ori believes that from a theoretical perspective, DAG protocols are "ideal consensus protocols": they can process all network information and output optimal results, miners can feed back their observed network state to the network through "parent blocks" (similar to "real-time reporting perspective"), and support high block generation rates, more frequently synchronizing network state.

• He specifically mentioned DagLabs' two core protocols:

  • Ghost DAG: Requires presetting the network's maximum latency. As long as confirmation time exceeds that latency, fast finality can be achieved.

  • DagKnight: Developed by Michael and Yonatan, requires no preset network latency, can automatically adapt to network changes—for example, if current network latency is 2 seconds, and drops to 0.5 seconds five years later, developers don't need to intervene, and confirmation time automatically shortens. Even if network latency suddenly increases to 20 minutes (beyond Bitcoin's assumed range), DagKnight can still operate normally.

• After joining DagLabs, he was attracted by the team's "academic research-oriented" atmosphere—this was the first time he worked in such an environment, with team members being highly professional and widely known, which impressed him.

(6). Early DagLabs Team Composition (2017-2018)

• Core members included Yonatan (core researcher), Mike Zak (responsible for project advancement at the time), a talented developer without a cryptocurrency background (accidentally entered the industry, strong learning ability, open attitude, full of enthusiasm for crypto technology), and one of Yonatan's summer researchers.

• The team had a clear initial plan, which was to develop and launch Kaspa (originally named Ghost DAG, later renamed), not "doing it while planning."

Chapter 3: The Name "Kaspa": Means "Dandruff" in Spanish!

• Kaspa's name has two backgrounds: first, it means "silver" in Aramaic; second, it was later discovered to mean "dandruff" in Spanish.

• After discovering the ambiguity of the name, the team was very concerned and specifically consulted marketing personnel from Latin America, receiving feedback that "it's not a big issue"—when locals hear "Kaspa," they more likely associate it with shampoo advertisements (not a high-frequency daily word), so no negative associations are generated, and thus the team decided to keep the name.

• The interviewer also agreed with this decision, believing that the Kaspa brand has high recognition and strong community support, making it the "right choice."

(1). Ori's Role and Technical Choices in Early DagLabs

• The early team had no clear division of roles, leaning more towards "non-hierarchical" collaboration: Ori participated as a developer while also responsible for "R&D bridge" work—after the research team proposed solutions, he would examine edge-case vulnerabilities from a development perspective and provide feedback to the research team for optimization.

• Later, he gradually became the "lead developer," but in the early team, he was the only developer, so the "leadership role" was more nominal.

• Regarding technology stack selection, the team initially weighed between Go language and Rust, ultimately choosing Go: first, Go's ecosystem was more complete at the time; second, the learning curve was lower. However, they later discovered Go's drawbacks—optimization difficulty, with garbage collection (GC) becoming a performance bottleneck—so they later switched to Rust.

• He mentioned that many blockchain projects initially chose Go, influenced by Go's propaganda as "safer C language," but in reality, Go's security is not as good as Rust, and it runs slower. Large projects like Ethereum, with sufficient human resources, can optimize Go code (similar to Facebook optimizing PHP), but small to medium-sized projects can't afford such costs, so Rust is more suitable for projects pursuing performance.

• The transition from Go to Rust began after Kaspa launched: the team's goal was to achieve 10 BPS (blocks per second), realizing Go couldn't support this performance requirement, so they initiated a rewrite. The transition process took far longer than expected—originally planned for 1 year, but actually took 2 years, with some funding coming from community crowdfunding through Discord.

Chapter 4: Final Decision: Fair Launch

(1). Repeated Weighing of Launch Options

• The early team considered a "pre-mine" model—pre-allocating some tokens to developers and investors to cover costs—but Ori believed "hardcore crypto users wouldn't accept pre-mining," so he proposed an alternative.

• Alternative: Develop dedicated ASIC miners and raise funds through "selling hash rate" (similar to ICO, but selling mining hash power instead), believing this approach was "purer"—the consensus protocol wasn't modified, no pre-mining, only relying on "first-mover advantage" to occupy a certain position in the mining market. However, the team worried this model lacked appeal and ultimately abandoned it.

• Final decision: Dissolve DagLabs' algorithm department and launch Kaspa in a "completely fair launch" mode—no pre-mining, and no guaranteed returns for investors. At the time, investors invested about $8 million (not a large sum in the context of the 2017 cryptocurrency industry), so there wasn't much intervention in the launch plan, respecting the team's decision.

(2). Selection of Mining Algorithm (2 Days Before Launch)

• The team discussed the mining algorithm in the public Discord group, ultimately choosing HeavyHash: first, the algorithm supports "optical mining machines" (focusing on Kerklex technology); second, there was already a project (Optical Bitcoin) based on HeavyHash development and launched FPGA miners, and the team made minor adjustments to the algorithm to avoid that project gaining hash rate advantage.

• Before launch, the team expected "maybe only 10-20 miners would participate," but actually attracted thousands of miners, completely exceeding expectations.

Chapter 5: Problematic Launch: Everything Descended into Chaos

(1). Technical Failures After Launch

• Due to the rushed launch, there were bugs in the code: block header sizes were too large. While Go clients could operate normally in test environments, when facing a mesh network composed of thousands of miners, serious network bottlenecks occurred, causing the network to descend into chaos.

• Normally, the DAG should maintain a "converged state" (stable size and width), but the bug caused the DAG to split into multiple disconnected subgraphs, unable to operate normally.

(2). Solution: Restarting the Genesis Block

• The team ultimately decided to "restart the genesis block": not completely creating a new genesis block, but in the new genesis block "committing to preserve some UTXOs (unspent transaction outputs) from old blocks," essentially fixing the block header bug, resetting the network state, and notifying the community that "a new genesis block will launch after 24 hours, and transaction records before this will no longer be valid."

• Ori frankly stated, "I'm not proud of this, but it was the only solution at the time." The failure occurred within 2-3 weeks after launch, when there were already at least hundreds of miners participating in the network.

(3). Team Adjustments After the Failure

• After DagLabs dissolved, Ori faced dual pressures: on one hand, he had no degree previously, so to improve himself, he began pursuing degrees in mathematics and computer science; on the other hand, he was Kaspa's only developer, needing to support project development alone.

• Later, he invited Michael Sutton to join. Michael had previously mainly worked on research and hadn't written Kaspa's core code (only written Python simulation code), but not only did he have strong development capabilities, he also possessed leadership skills, eventually becoming the person in charge of the Kaspa development team. Ori stated, "I lack leadership ability, and Kaspa team's excellent development today is inseparable from Michael's leadership."

Chapter 6: Mission: Building a Knowledge Base for Kaspa

(1). 2025: Comparison Between Kaspa Community and Early Bitcoin Community

• Similarities: Both focus on "decentralization" and "trustlessness" core features, with a community atmosphere oriented toward technical exploration.

• Differences: The Kaspa community "lacks sufficient technical knowledge reserves"—in the early Bitcoin community, there were extensive technical discussions in forums and mailing lists, with participants having strong technical backgrounds; while the Kaspa community is progressing (development team scale is expanding), technical knowledge is still concentrated in the hands of a few people, needing further improvement.

(2). Actions to Build a Knowledge Base

• To address this issue, Ori launched a "Kaspa-exclusive Q&A website," with functionality similar to StackOverflow. It supports user questions and answers, with a reputation system, encouraging community participation through incentive mechanisms.

• He mentioned that initially, the website's content was mainly filled by himself (even asking and answering his own questions), with the core goal of "establishing a retrievable knowledge base"—previously, community questions were mostly discussed on Discord and X (formerly Twitter), with scattered information that was difficult to find; while a knowledge base can long-term precipitate technical content, helping developers grow.

• Ori clearly stated, "Perfecting the knowledge base for Kaspa and expanding the developer community is one of my current core missions."Optical Bitcoin) based on HeavyHash development and launching FPGA miners. The team made minor adjustments to the algorithm to avoid that project gaining a hash rate advantage.

• Before launch, the team expected "perhaps only 10-20 miners to participate," but actually attracted thousands of miners, completely exceeding expectations.

Chapter 5: Problematic Launch: Everything Descended into Chaos

(1). Technical Failures After Launch

• Due to the rushed launch, there were bugs in the code: block header sizes were too large. Go clients could operate normally in test environments, but when facing a mesh network composed of thousands of miners, serious network bottlenecks appeared, causing the network to descend into chaos.

• Under normal circumstances, DAG should maintain a "converged state" (stable size and width), but the bug caused the DAG to split into multiple disconnected subgraphs, unable to operate normally.

(2). Solution: Restarting the Genesis Block

• The team ultimately decided to "restart the genesis block": not completely rebuilding a new genesis block, but in the new genesis block "promising to retain some UTXOs (unspent transaction outputs) from old blocks," essentially fixing the block header bug, resetting the network state, and notifying the community that "24 hours later, the new genesis block will launch, and transaction records before this will no longer be valid."

• Ori frankly stated, "I'm not proud of this, but it was the only solution at the time." The failure occurred within 2-3 weeks after launch, when there were already at least hundreds of miners participating in the network.

(3). Team Adjustments After the Failure

• After DagLabs dissolved, Ori faced double pressure: on one hand, he didn't have a degree previously, so to improve himself, he began pursuing degrees in mathematics and computer science. On the other hand, he was Kaspa's only developer, needing to support project development alone.

• Later, he invited Michael Sutton to join. Michael had previously primarily engaged in research work and hadn't written Kaspa's core code (only Python simulation code), but not only did he have strong development capabilities, he also possessed leadership skills, eventually becoming the head of the Kaspa development team. Ori stated, "I lack leadership ability, and the excellent development of the Kaspa team today wouldn't be possible without Michael's leadership."

Chapter 6: Mission: Building a Knowledge Base for Kaspa

(1). 2025: Comparison Between Kaspa Community and Early Bitcoin Community

• Similarities: Both focus on core characteristics of "decentralization" and "trustlessness," with community atmosphere leaning towards technical exploration.

• Differences: The Kaspa community "insufficient technical knowledge reserve"—in the early Bitcoin community, forums and mailing lists had extensive technical discussions, with participants possessing strong technical backgrounds. Although the Kaspa community is progressing (development team size expanding), technical knowledge is still concentrated in the hands of a few people and needs further improvement.

(2). Actions to Build a Knowledge Base

• To address this issue, Ori launched a "Kaspa-specific Q&A website," similar to StackOverflow. It supports user questions and answers, has a reputation system, and encourages community participation through incentive mechanisms.

• He mentioned that initially, the website's content was primarily filled by himself (even asking and answering his own questions), with the core goal of "establishing a searchable knowledge base"—previously, community questions were discussed on Discord and X (formerly Twitter), with scattered information difficult to find. A knowledge base can long-term accumulate technical content, helping developers grow.

• Ori clearly stated that "perfecting the knowledge base for Kaspa and expanding the developer community" is one of his current core missions.