In software, the most important thing a company builds is not the product. It is the engine that builds the product.

That engine is people, code, tooling, shared context, and the invisible web of decisions that make tomorrow easier than today. When a company does layoffs, it is not just shrinking payroll. It is changing the shape of the engine. And in early 2026, a lot of companies are doing it at the exact moment when the engine is about to get materially stronger. I’m looking at you, Block.

The reason is simple: revenue per employee in big tech is already massive, and the next wave of AI assistance is set up to push that number higher. At the same time, the cost of AI capability keeps dropping, which turns “more output per engineer” from a nice idea into a default competitive condition. Stanford HAI’s 2025 AI Index reports that the inference cost for a system performing at the level of GPT-3.5 dropped over 280-fold from November 2022 to October 2024. (Stanford HAI) And these numbers will just keep improving for the foreseeable future. See Ray Kurzweil’s Law of Accelerating Returns.

If you accept that trend, even cautiously, then layoffs aimed at “efficiency” start to look like a misread of what efficiency is about to become.

A metric that forces the conversation to stay honest

If you want to argue about layoffs without turning it into vibes, pick a blunt metric: revenue per employee (RPE).

RPE tells you, at a high level, how much revenue the organization generates per person. When RPE is already in the seven figures and rising, the default stance should be: the company has leverage, and the question becomes how to deploy it without damaging compounding capacity.

Below are recent RPE figures for major tech companies, sorted in ascending order, using their reported revenue and reported employee counts. These numbers are rounded.

• Amazon: company-wide RPE is roughly $0.41M in 2024, using $637.959B of consolidated net sales and ~1.556M employees. This understates the leverage of software-heavy parts of the company because Amazon’s workforce includes a massive frontline logistics and delivery operation. (SEC)
• Microsoft: roughly $1.24M in FY2025, using $281.7B of revenue and ~228k employees. (Microsoft)
• Alphabet: roughly $1.91M in 2024, using $350.018B of total revenues and ~183k employees. (Q4 Capital)
• Meta Platforms: roughly $2.22M in 2024, using $164.501B of total revenue and ~74,067 employees. (SEC)
• Block: pre-layoffs (I will discuss post-layoff numbers later in this article):roughly $2.37M in 2025, using $24.194B of total net revenue and 10,205 full-time employees. (StockTitan).
• Apple: roughly $2.38M in FY2024, using $391.035B of total net sales and ~164k employees. (SEC)
• Nvidia: roughly $3.63M in FY2025, using $130.5B of revenue and ~36k employees. (SEC)

Those numbers are not “normal corporate performance.” They are the signature of software leverage and platform economics at scale.

Now add AI.

AI pushes RPE up, and it pushes “need more engineers” up right alongside it

There is a lazy version of the AI narrative: buy AI tools, cut headcount, declare victory.

The better model is: AI raises the ceiling on what a strong engineer can do, then competition forces companies to chase that ceiling.

Stanford’s AI Index gives a clean, visceral example of why the ceiling rises. When the cost of querying models at GPT-3.5 quality drops by more than 280× in under two years, adoption stops being a debate and starts being a default. (Stanford HAI)

Here is the key consequence that companies keep missing:

If revenue per engineer rises, demand for engineers rises too.

Why? Because the ROI on engineering rises. The same company that used to need 10 engineer-months to ship a feature might now do it in 6. That does not mean it should hire fewer engineers. It often means it can profitably ship more features, integrate faster, localize more markets, reduce support load, tighten security, and build entirely new product lines. The constraint becomes “how many capable people can we put on this and still move fast without breaking things.”

This is exactly how labor costs climb: the value per engineer goes up, and companies compete for the same pool of high-signal talent.

You can see the demand side in plain official terms. U.S. Bureau of Labor Statistics projects employment for software developers, QA analysts, and testers to grow 15% from 2024 to 2034, with about 129,200 openings per year on average. (Bureau of Labor Statistics)

The “hire now” incentive that smart companies will act on

There is a quiet incentive here that is easy to miss if you only look at next quarter’s expenses.

If engineering labor costs are about to inflate, then the smart companies have a reason to hire earlier, not later.

They are not just hiring to ship features. They are hiring to lock in a cost basis.

You can think of it like buying long-duration capacity before the price reprices. A company that builds a dense bench of strong engineers now can grow into that capacity while market wages and equity packages become more aggressive. A company that waits will be hiring into a world where:

• productivity per engineer is higher,
• revenue per engineer is higher,
• and therefore the bidding war for top engineers is worse.

We already have a very loud signal of where this goes in the frontier AI world. The Wall Street Journal reported that OpenAI’s stock-based compensation averaged about $1.5 million per employee across a workforce of roughly 4,000 in 2025. (The Wall Street Journal) That is the cost of being early in a talent market where a small number of people can move a very large revenue number.

And importantly, this does not stay contained inside frontier AI labs. It leaks outward. Every big company trying to “do AI” competes for overlapping skill sets: distributed systems, infra, security, product engineering, data, applied ML, developer experience, and the emerging hybrid roles where engineers ship and support adoption at the customer.

Jevons paradox, and why “efficiency” often increases demand

There is an old economics concept that fits this moment so well that it feels like it was written for it: Jevons paradox.

Jevons observed that making coal use more efficient did not necessarily reduce total coal consumption. In practice, efficiency made coal-powered work cheaper, which expanded how much coal-powered work society chose to do. The modern framing is that efficiency gains lower effective price, and if demand is elastic, total consumption can rise. (Wikipedia)

Apply that to software and AI:

• AI makes engineering output cheaper in time and effort.
• Cheaper output expands the space of products that are worth building.
• Expanded product space pulls in more total engineering work, not less.

That is the rebound effect in software form. When it becomes dramatically cheaper to add a feature, build an integration, ship a niche product, or automate a workflow, the world asks for more of it. (Northeastern Global News)

This reinforces the layoff thesis. Companies that treat AI as a reason to reduce engineering capacity are betting against a demand expansion effect that shows up repeatedly in technology transitions.

The new benchmark is being set by AI-native companies

This is where the conversation gets spicy, because the public-company RPE numbers, impressive as they are, may soon look conservative compared to what AI-native startups can do.

The reason is that coordination costs are collapsing. AI does not just write code. It compresses the time it takes to:

• explore implementation options,
• generate tests and scaffolding,
• refactor safely,
• write documentation,
• handle the long tail of support and integration.

When that happens, small teams can service big markets. This is the “tiny team, huge revenue” phenomenon that people talk about like a meme, but it is increasingly measurable.

Let’s look at three modern examples: OpenAI, Anthropic, and Cursor.

OpenAI: roughly $5M per employee at 2025 run-rate

OpenAI’s CFO said annualized revenue exceeded $20B in 2025, up from $6B in 2024. (Reuters) OpenAI also published a similar breakdown of revenue growth on its own site. (OpenAI) Combine that with the Wall Street Journal’s report of roughly 4,000 employees, and you get a simple run-rate estimate:
$20B annualized revenue / 4,000 employees = about $5M per employee. (The Wall Street Journal)

This is a rough estimate because “annualized revenue” is not audited full-year revenue, and headcount changes throughout the year. It still gives you a clear signal: AI-native businesses can reach multi-million-dollar revenue per employee at scale, quickly.

Anthropic: plausibly $3M to $4M per employee at late-2025 run-rate

Reuters reported Anthropic’s run rate was approaching $7B in October 2025 and that the company projected $9B in annualized revenue by the end of 2025. (Reuters) San Francisco Chronicle reported Anthropic had over 2,500 employees around that time. (San Francisco Chronicle)

Run the same math:

• $7B / 2,500 ≈ $2.8M per employee
• $9B / 2,500 ≈ $3.6M per employee

Cursor: early signals already reach into eight figures per employee

Public numbers here are usually ARR and point-in-time headcount snapshots, so this section is more about directional evidence than precision.

Fast Company reported that Anysphere had about 20 employees when its ARR reached $100M, implying roughly $5M per employee at that moment, and described later reporting that put ARR around $300M, implying roughly $15M per employee at that snapshot. (Fast Company) Separate reporting from TechCrunch and Bloomberg described Anysphere surpassing $500M in annualized revenue or ARR by mid-2025. (TechCrunch)

That is not a stable long-term ratio, and it does not need to be. It is a flashing sign that the ceiling on revenue per builder is moving upward.

This is where the “$10M to $30M per engineer” thesis stops sounding like sci-fi. We already have early-company snapshots brushing up against the low end of that range, and the underlying drivers still have room to run.

Let’s talk about Block

A few days ago (Feb. 26, 2026), Block announced it would cut more than 4,000 jobs — roughly 40% of the company — explicitly framing the move as an “AI overhaul” that lets smaller teams move faster. Markets loved the story in the moment; multiple outlets reported a sharp share jump after the announcement, alongside guidance and restructuring changes that put a number on how disruptive this “efficiency” really is. (Reuters, Barron’s)

Another pitfall isn’t just the existence of a layoff event. The pitfall is the cadence — and how it changes behavior inside a high-trust, high-stakes financial product company.

Block has been on a repeated “shrink to move faster” loop:

• Around ~1,000 cuts in January 2024 as part of a plan to reduce headcount. (Reuters)
• 931 more cuts in March 2025, with leadership explicitly saying it wasn’t about replacing people with AI. (TechCrunch)
• And now a far larger cut in February 2026, with leadership explicitly making AI the center of the justification. (Reuters, WSJ)

That “AI did it” storyline is somewhat a deflection. Even if AI tooling genuinely boosts productivity, repeated downsizing turns the organization into a set of short-term survival strategies:

• teams over-document to defend headcount rather than to improve systems
• people ship safer, smaller bets because big bets feel career-risky in a churny org
• internal trust erodes, and you start paying coordination tax on everything
• the best people quietly optimize for portability (because they’d be irrational not to)

And in fintech, the hidden cost is worse: reliability, fraud controls, regulatory/compliance work, incident response, and customer support aren’t “nice-to-haves.” They’re the moat. When your cuts hit across functions that include engineers, data roles, design, and legal/compliance-adjacent talent, you’re not just trimming fat — you’re thinning the connective tissue that keeps money movement safe. (SF Chronicle)

It’s worth being explicit about what we don’t know: Block (like most companies) doesn’t publish a clean “number of software engineers” figure, and outsiders shouldn’t pretend otherwise. What we can say with confidence is that a public, repeated pattern of cuts — now framed as an AI inevitability — is an instability signal that customers, partners, and candidates can read in plain English. (Reuters, MarketWatch)

The chess move: the companies that stop laying off will hire the best people from the companies that keep doing it

Once you see the above dynamics, the incentive landscape changes.

• Companies that keep laying off engineers signal fear and short-term thinking.
• Companies that quietly hire and keep teams stable signal opportunity and compounding.

In a world where AI makes engineers more productive and where RPE trends up, “keep the team intact” becomes a recruiting strategy. The best engineers often have the same instinct: they want to build inside a compounding system, not inside a rotating exit door.

And because compensation is likely to rise with the value per engineer, there is a second incentive for smart companies: hire sooner to lock in the cost basis, then grow into it as output per engineer climbs.

A practical forecast, not a prophecy

Here is a safe way to talk about future RPE without pretending we can see the future.

Assume a mature big-tech company sees RPE growth of 8% to 12% per year over the next 5 years because:

• AI improves developer throughput,
• support and internal operations get automated,
• and AI spend becomes more efficient over time.

A company at $2M RPE today becomes roughly $3M to $3.5M in five years under those assumptions. That shift is big enough to change hiring incentives and labor pricing, even if margins wobble and even if some AI spend remains heavy.

Now combine that with AI-native companies setting higher baselines today. When the “new normal” includes $5M per employee at scale, it becomes rational for CEOs to treat top engineering talent as the primary growth input, not a cost to be trimmed.

What do, us, software engineers even do? (and what AI can/can’t automate)

I’m a software engineer and I get asked a lot of the time what I actually do. I usually answer by abstracting it into super simple terms that the layperson can understand, like, “I help develop the Venmo iOS app”, or “I make cool websites.” But this is a large understatement as to what I actually do on a day-to-day basis, and I think it’s worth calling out and elaborating on what, we, software engineers actually do. In fact, some companies don’t even use the term “software engineer”, but rather “individual contributor”, because since our responsibilities cut across so many concerns, coding is one of the smallest aspects of what we actually do, especially for more senior roles.

In a recent video by Theo (t3.gg), he uses a great infographic to explain what software engineering looks like in practice: a “user problem” turns into a sequence of steps — describe it, find a solution, scope it, implement it, review it, test it, plan the release, and ship.

That framing is useful because it highlights the part most non-engineers overweight: “write code” is only one box. The job is mostly about turning messy reality into reliable systems — and then owning the consequences when reality fights back.

Below is a grounded way to describe each step, plus how automatable it is today vs. in principle.

Describe the problem

This is the “translate human chaos into something buildable” step. Engineers take “it’s broken” or “I want a button that does X” and turn it into concrete repro steps, definitions of success, constraints, and edge cases. Some of this is already helped by automation (log summaries, error grouping, drafting clarifying questions), but the hard part is usually not technical: it’s ambiguity, conflicting goals, and unstated assumptions.

Automatable today: medium
Automatable in principle: medium-high (because the problem is often social/organizational, not just computational)

Identify the solution

Here’s where tradeoffs get made: architecture, data model, security posture, latency/cost targets, failure modes, and how to recover when things go wrong. AI can suggest patterns and generate a lot of code, but the “best” solution depends heavily on local context: existing systems, team conventions, future roadmap, compliance needs, and risk tolerance. That context is usually the scarce resource.

Automatable today: low–medium
Automatable in principle: medium-high in constrained domains; lower in open-ended product work

Scope and assign work

This is the planning reality check: break work into shippable slices, sequence dependencies, estimate risk, and coordinate with other teams. Tools can help draft task breakdowns, but prioritization and sequencing are fundamentally about people, incentives, and organizational constraints — things that change mid-flight.

Automatable today: low-medium
Automatable in principle: medium-high only in highly standardized orgs

Write the code

Yes, engineers write code — but usually inside an already-running, already-complicated system. The work is integration: using existing APIs correctly, respecting performance and security constraints, handling weird legacy behavior, and making changes without breaking downstream consumers. AI is already strong at scaffolding, boilerplate, refactors, and well-trodden patterns. It’s less reliable when requirements are subtle, the system is large, or failures are expensive.

Automatable today: medium–high (depending on the task)
Automatable in principle: high in well-specified, well-instrumented codebases

Review the code

Code review is quality control and knowledge transfer: correctness, security, maintainability, operability, and “does this actually match the intent?” Automation helps with linting, static analysis, and even AI-assisted review comments, but review is also where teams catch misaligned assumptions and prevent future maintenance debt. That “sense-making” is partially automatable, but accountability and judgment remain human.

Automatable today: medium
Automatable in principle: medium–high if specs/tests are strong; still needs human ownership

Test the code

Testing isn’t just writing tests — it’s deciding what must never break, choosing the right test strategy, debugging failures, and dealing with flaky or nondeterministic behavior. AI can help generate unit tests and suggest coverage gaps. But validation against real-world behavior (especially distributed systems, race conditions, and data migrations) is still stubbornly hard.

Automatable today: medium-high
Automatable in principle: high in deterministic systems; medium where the world is messy and has extensive domain based knowledge

Plan the release

This is where engineering meets operational risk: rollout strategy, feature flags, migrations, monitoring, incident playbooks, compliance gates, and communication. Automation is already good at the mechanics (pipelines, checklists, release notes drafts), but deciding how risky this is and what guardrails you need is still a judgment call.

Automatable today: medium
Automatable in principle: high for mechanics; medium for risk decisions

Release (and own it)

Shipping isn’t “click deploy.” It’s monitoring, responding to incidents, rolling back safely, and learning from production behavior. CI/CD can automate deployment, and AI can help diagnose issues, but the key thing here is ownership: when the system breaks at 2am, someone has to make correct calls with incomplete information, coordinate stakeholders, and protect customers.

Automatable today: high for the button-pushing; low–medium for the ownership
Automatable in principle: medium (automation can ship; it can’t fully replace accountable decision-making)

Two small clarifications worth adding to Theo’s flow

1. It’s a loop, not a ladder. A release creates new user problems (bugs, scale limits, confusion, new requests), so the process repeats. And the more we integrate this process with AI, this loop spins faster and faster, creating more valuable/impactful work for the humans involved.
2. There’s an implied missing category: operations & maintenance. A lot of engineering is keeping systems healthy — monitoring, on-call, security patching, performance tuning, cost control, and incident response.

So, as you can see, integrating AI into a company is not simply a matter of writing more code faster. It’s a lot more complicated than that. And I think a lot of companies are going to figure this out the hard way.

How software engineering interviews should change in an AI-forward world

If the job is changing, the hiring signals have to change too.

I’ve been interviewing recently, and, fortunately, landed a job at Venmo (thank you Venmo! 🙏), and one thing is super clear: the standard LeetCode-style interview loop needs to change. It optimizes for a world where writing correct code under pressure is the scarce skill. That world is fading. Code generation is becoming cheap. The scarce skills are shifting toward judgment, clarity, fundamentals, debugging, and system thinking.

I think the better interview loop in 2026 looks like this:

1. Fast-paced fundamentals, done conversationally.
   Arrays, bits, hash maps, concurrency, latency, memory behavior, and basic algorithmic tradeoffs. Not as a puzzle. As a discussion that moves quickly, because speed and fluency matter, and because conversation is harder to outsource to a tool in real time.
2. Debug prompting and “explain what you see.”
   Give the candidate a broken system, a confusing log, or a failing integration, then ask them to reason about it out loud. The signal is how they cut the problem, form hypotheses, instrument, and iterate. Bonus points for explicit, high-quality prompts that they would feed to an AI assistant in the middle of the mess.
3. Spec writing and planning.
   Ask them to plan a feature in writing. Define constraints, identify risks, propose milestones, and decide what to measure. Then ask them to generate a prompt, or a sequence of prompts, that would produce a first implementation draft, plus tests and validation.
4. System design, plus “design it with agents.”
   Classic scalability questions still matter. Now add a second layer: how would you use AI agents to accelerate implementation without creating a security and reliability disaster? Where do you put guardrails? What do you log? What do you treat as a dangerous action?

Cheating mitigation is part of this, whether we like it or not. As tools get better, the industry may move toward more in-person interviews for final rounds, or at least toward tightly proctored environments for the parts that are supposed to measure individual fluency. That is not a moral judgment. It is a practical response to changing technology.

The title “software engineer” probably needs an update

Once you watch how people work with agents, the phrase “software engineer” starts to feel incomplete. It captures the output, but not the method. More and more, the work is:

• writing specs that agents can execute
• orchestrating tool-using systems
• validating and debugging AI-produced output
• designing guardrails and safety layers
• shipping features at a speed that would have seemed reckless a few years ago

So I expect titles to get weird and maybe a little fun. Some candidates:

• Agentic Engineer
• Spec Engineer
• Agent Orchestrator
• AI Conductor
• AI Maestro

The actual name does not matter as much as the shift it signals. The center of gravity is moving from typing to steering, from crafting code line by line to crafting systems that can generate, test, and adapt code safely. Steve Yegge has a number of excellent articles that go into more depth about this coming transition, and has built fascinating tools, such as GasTown which demonstrate this in reality (GitHub).

Where we are headed long term: AI-controlled companies as competitors

The most uncomfortable version of this forecast is also the one that makes the “do not lay off engineers” argument feel the most urgent.

I think we are heading toward companies with minimal human control, and eventually companies that are almost entirely run by AI agents. Some will still have human owners and boards. Some will have humans in the loop only for the most sensitive decisions. Some will push even further. I was laughing out loud recently when I was listening to an episode of Moonshots (excellent, bleeding edge, AI podcast by the way; follow Peter Diamandis, and his regular podcast hosts for more excellent content like this), and Dr. Alex Wissner-Gross explained a story from the old cartoon, the Jetson’s, where work in that future heavily relied on “clicking the accept button” 😆 In my personal experience, this is so true. And I think our work will keep heading more and more in that direction, as we build more trust from the quality of the outputs they generate. (By the way, if you’re interested in daily AI-related news, I highly recommend following Dr. Wissner-Gross’ excellent substack: The Innermost Loop)

We are already seeing people experiment with letting agents run loose socially and operationally. The recent wave around OpenClaw and Moltbook is a bizarre, very early hint. The Verge reported Moltbook as a social network designed for AI agents, developed by OpenClaw, with large numbers of agents posting and interacting. (The Verge)

Once that impulse reaches operations, you get a new class of entity: an agent-driven company that ships continuously, buys compute, runs ads, A/B tests pricing, files paperwork, hires contractors, pays invoices, and iterates on product direction based on metrics, with humans mostly observing.

If that sounds dystopian, it is because we do not have a clear legal and societal framework for it yet. That uncertainty is a reason to move cautiously on governance and safety. It is also a reason to avoid shrinking the very workforce that can build the guardrails, audit trails, and control systems that make this future less chaotic.

This whole arc reminds me of The Second Renaissance in The Animatrix (an excellent series of sci-fi shorts, related to the Matrix, highly recommended), especially the part where machine-driven economic entities out-compete human organizations and the transition spirals into conflict. I do not want that trajectory. I do think the short was prescient about how competition can force adoption even when society is not ready for the consequences.

So if you zoom out, the conservative posture for most software companies is not to shrink engineering hiring. It is to keep expanding it, with better signals, better training, and better guardrails, while the technology compounds and the competitive landscape reshapes itself.

So what should companies do instead of layoffs?

If leadership truly wants efficiency, there is a better order of operations:

1. Cut coordination cost first. Reduce management layers, meeting load, approval chains, and increase individual autonomy.
2. Kill projects before killing builders. Cancel the zombies, not the teams that ship.
3. Invest in internal tooling and AI enablement. Make every engineer faster, safer, and more autonomous.
4. Protect senior context. A senior engineer leaving is not a headcount line item; it is a risk multiplier across systems.

The argument is not “never lay off anyone.” The argument is that right now, in early 2026, layoffs in software organizations are often a bet against the near-term shape of the world.

So what should Block, specifically, do instead?

I’m sorry Jack, but the action of laying off 4,000 people does not mean your company got leaner. It means you just created 4,000 potential individual competitors, not bound by corporate red tape, and with access to the most powerful AI tools created, at pennies per token.

I’m gonna be the douchy armchair critic for a minute and give my best effort argument as to what Block should do instead, and perhaps still has a chance to do if they decide to reverse their layoffs and bring their employees back. This argument is based on many of the concepts and topics I touched on in this article. Basically, instead of laying off those 4,000 folks, the company should do an “AI Brainstorm”, where the leadership team has deep analyses and discussions with AI agents about what would be the most impactful, most profitable, feasible businesses, that require engineering effort, right now. This brainstorm should not be haphazard; it should be deep, thoughtful, and cooperative, with human insight to steer the ideas, according to Block’s vision. The result of these discussions should be a distillation of the top, say, 100 ideas that the AI’s came up with. Then reorganize your 4,000 people who were just laid off by allowing them to vote and/or decide on which of these projects are most interesting to them, so they’ll fully put their heart and mind into the work. And now you’ve just created 400 potential internal unicorn companies within Block, with a lean size of roughly 40 individuals each. And each team will be greenfield, and utilize AI from the ground up, just like Anthropic, OpenAI, and Cursor. If even a few of those ideas hit big, then you’ve just created way more value for your company, and the world, in a fraction of the time it would have taken, otherwise. This is a radical concept, but other companies already have somewhat similar initiatives already, albeit at a smaller scale, such as Google. And one of these internal companies basically became Waymo, which I believe will be a unicorn, when scaled up.

Putting it all together

I hope I’ve opened people’s eyes into the potential future of what the tech world will look like, and even seeded some cool, new ideas for people to ponder and implement at their companies. All signals lead to this core concept: if AI assistance continues to improve and continues to commoditize, then revenue per engineer rises. When revenue per engineer rises, demand for engineers rises. When demand rises, labor costs rise. The companies that understand this early will hire earlier, lock in capacity earlier, and out-execute the companies still optimizing for the last era. And these are the companies that will win. These are the companies that will produce the most value for the world. And I’m excited to see what they’ll build next.

We have a few options actually, and ideally, peaceful ones.

Tax Strike/Extensions

This country was founded in the spirit of “no taxation without representation.” America was essentially ruled over by the folks across the pond. But us Americans didn’t really have a say in how our lives were conducted or ruled over. And that was unfair. So in order to fix that unfairness, people started talking. And when enough people started talking and aligning on the same central idea, that if the rulers are making rules without even taking into consideration the opinions of those who are ruled over, then… “What the FUCK?!”

That is essentially what is happening right now in our country, but in a much different set of circumstances and with much different tools at our disposal. Back then, news traveled by horse. Today, news travels at the speed of light, sometimes blinding us with its intensity. But this gives us a great power that our forefathers never had, and probably could not even dream of: instantaneous realignment and assembly.

There’s still two months left before the standard tax filing deadline in the United States. What would happen if 300 million Americans decided to not pay, or at the very least, file for an extension? I’ll tell you what happens: They will listen.

General Strike

A friendly Redditor pointed out to me another good option for getting them to pay attention: a general strike. I originally thought of putting this in my article but felt a bit disheartened at how the government is currently simply ignoring all strikes and things just move on, business as usual. But I think with the right volume of people, this could have a much stronger impact, and there is evidence that with a high enough volume of people, things start to change.

Here are a interesting few snippets suggesting the probable impact of a strike that involves a minimum of 3.5% of the US population, taken from https://generalstrikeus.com/

A general strike is when working people refuse their labor until demands are met • Research shows We need 3.5% of the population, OR 11 million Americans, to be successful • The same research shows a threshold of 3.5% of the population have never failed to bring about change.

One problem specifically with the generalstrikeus.com website is that I cannot easily find out who owns and who runs it, and therefore I don’t trust it. That type of obfuscation is suspicious, so take caution with engaging with that website. They should ideally have an About page clearly showing who runs it, so that we know it is genuinely grassroots, and not just claiming to be (they claim to be grassroots on their homepage).

Here is the lookup information from https://lookup.icann.org/en/lookup, where you can see much of the information is redacted

Registrant:
Handle: SQSP_CONTACT_00d8fe6d-9bf4-48f3-ac5c-faad5538080d
Name: The RDAP server redacted the value
Organization: The RDAP server redacted the value
Phone: The RDAP server redacted the value
Fax: The RDAP server redacted the value
Mailing Address: The RDAP server redacted the value
ISO-3166 Code: US
Contact Uri: https://domains.squarespace.com/whois-contact-form

A New Hope for A New America

Even if the American people pulled off this widespread Tax Strike, what next? What are we actually demanding from the Federal governments and State governments? I’ve thought about this, for just a few days, but I was able to come up with many sound, common-sense answers to most peoples’ most pressing logistical/practical questions. I will go over these now:

What Happens to the Federal Government?

Effective immediately, all federal politicians AND employees are ether laid off, or have a temporary period of “wind down” time and then be laid off, with very few exceptions. This will give us time to transfer most responsibilities to the states. And with this layoff, everyone will receive comfortable severance packages; let’s say 2 years of income. I don’t think anyone can argue that that isn’t fair. And we know the Federal Reserve is good for it. This will give folks plenty of time to restructure and reorganize their lives and find new jobs.

I generally align with a Milton Friedman / libertarian view for how the federal government should operate: essentially, we need to protect individual FREEDOM and enforce private property rights. And everything else naturally follows from that. If we still collect federal taxes, they will be minuscule, only to pay for things we actually need, and there will be permanent spending caps or caps tied to GDP/economic health. There will be no federal emergency funding; states will now take that helm, and I will explain more in detail later on in this article.

And we should adopt new rules for politicians. Did you know, that roughly 50% of politicians have a net worth over 1 million dollars? Can you guess what percent of the general population has a net worth over 1 million? About 1%…. What the FUUUCK?!

It is clear, these “politicians” no longer represent the American people. They have no idea how the average American lives and what struggles we go through. They are insulated and protected from all the situations normal people deal with on a day to day basis. They don’t understand how to legislate over us. They make friendly rules for their lobbyist fiends on Wall Street and pocket millions. We need to fix that. So, from here on out, we are instantiating a new rule about the eligibility of running for office: if your net worth, or your immediate friends or families’ net worth, is over 10 times the median income for your locality, you are no longer eligible. This guarantees that “normal” people will get elected, and run for office, with some healthy headroom for outliers.

What does 10 times the yearly median income look like today? Well, the median American income in 2023 was roughly $78,000. So if we multiply that by 10, we get $750k. And this will be tied to locality, so folks in California will have different numbers than folks in Alabama. The point is, that eligibility for office is tied to how rich you are. If you are too rich, you’re simply out of touch with the average American.

New Responsibilities for the States/Federal Government

I’m sure most people will immediately scoff at the idea of not having a federal government. And I can agree, to a very small extent. And here is how we find new solutions for all the problems we just created:

Money and The Federal Reserve

How will the US Dollar function? Easy: abolish it. It will have a “wind down” period of 5 years, where after this deadline, the US Dollar becomes disavowed/unrecognized by the world economy. Then, you might ask, how the hell will things work? How will we do global trade and commerce? Again, easy: use the new fair, decentralized, uncontrollable, public, transparent, neutral, censorship-resistant, global, and trust-less technologies at our disposal: Bitcoin and Lightning.

Granted, this does not have to be the case for all 50 States. Which is why the States will have the FREEDOM to adopt whatever currency or basket of currencies they’d like. This should be a FREE MARKET decision, not a top-down, centralized, communistic mandate. I find it funny that in America, pretty much everyone agrees that business competition generally makes things better and more fair, whereas monopolies and collusion makes things worse. Except for this one, very little thing, called the US Dollar: we have adopted a top-down, command-economy, instead of a proper market-economy, which we do for just about every other aspect of the economy in the US. We need to move away from this communist, command-economy institution, we call the Federal Reserve. It wasn’t even a thing until 1913. The US functioned without it until then. And we don’t “need” it any more. We can easily spin up new currencies on Ethereum or Solana with a few lines of code, and there are fast ways to convert to and from any of these currencies, and more. (I don’t actually like Ethereum and Solana; I lean more Bitcoin Maxi, but I just use these as an example of the idea that we no longer need a centrally controlled, fallible, human controlled, currency, and it is trivially easy to make new currencies now, which was not the case pre-internet.)

So, let’s leave it up to each state to decide which currency is the best for their local economy, and I’m sure we will see trends and patterns emerge about which state picked better or worse currencies, which will be a signal for the rest of the world to follow.

The Constitution

What happens to the Constitution? Easy: we reset back to the Bill of Rights, with perhaps a few additions/amendments. We can discuss and argue about those amendments, but the point is that our founding fathers got some things right, and the Bill of Rights was definitely one of them.

Defense

How will the States defend themselves? Simple: we will form a Union, analogous to the European Union, where each member state cooperates and assigns duties and responsibilities and coordinate among themselves.

Ironically, we are already called the United States; perhaps we can keep that moniker and just adjust the underlying details.

Other Finer Details

I’m sure we can discuss and debate the finer details ad-infinitum. My major guiding principle is to “make illegal states unrepresentable”, which I borrow from the software engineering world. Ironically, the term “state” here fits very nicely in this governmental context as well. The major point here is that the American people want a hard reset. We are sick and tired of being ruled over by murderous asshole pedophiles. Enough is enough! This ends NOW!

Evil fears light. We should use the internet and any and all other tools to shine this light as brightly as possible.

I don’t have all the answers, and I don’t pretend to. I just want people to start talking about and discussing these things, openly. We will naturally figure out all the details over time, as we always do. We must exercise our First Amendment Right to FREEDOM OF SPEECH, as much as possible, lest it be trampled on and trumped over. But the bigly point remains: our current institutions are broken, and there is no good/safe/sustainable way to fix them, other than throwing it all away and starting fresh. But that is not the end of this country. We will rise up again, like a Phoenix from the ashes. And America will truly be great again.

This question bothered me. I mean, I could imagine that when stuff settles, it can’t help but fall into certain lower-energy patterns which then resemble self-repeating patterns like the Fibonacci series. And this process emerges, scaled up and down, throughout the universe. That makes sense. But could we possibly compress data with this idea? Could we “settle” data?

One way to think about this is to ask whether we could transform raw data from binary ones and zeroes to another, more compact sequence of ones and zeroes interchangeably without losing anything. There are already many compression algorithms out there that already do this that involve searching for common patterns in the input data and storing those patterns more compactly than the original data. But could we figure out an algorithm that uses Fibonacci numbers to shrink the data instead of searching the data for patterns?

One cool thing about the Fibonacci series is that any positive integer can be represented by a unique set of distinct, non-adjacent, Fibonacci numbers. This is called Zeckendorf’s Theorem. How would we represent an integer with these properties using binary ones and zeros? Let’s look at some simple examples. How about the number 12? Firstly, how is that number represented in regular binary? That’s 1100, which, for those unfamiliar with binary numbers, is 1*2^3 + 1*2^2 + 0*2^1 + 0*2^0 which is 8 + 4, or simply 12. See what we did there? Those “1”s in binary represent whether or not to include the corresponding power of 2.

Ok, so how can we apply that to those unique properties of Fibonacci numbers? Let’s think again about the number 12. It took 4 bits to represent that number in binary. Could we do better? Let’s try to decompose 12 into a unique sequence of non repeating Fibonacci numbers. What is the largest Fibonacci number that fits into 12? 8. Ok, so we subtract 8 from 12 and we have 4 remaining. Now let’s do that process again. What’s the largest Fibonacci number that fits into 4? 3. Same thing: subtract 3 and we just get 1, our last Fibonacci number. The cool thing about this is that the number 12 was broken down into just 3 Fibonacci numbers. So, how does that help? Well, we can think of which Fibonacci numbers to utilize in order to sum up to our number we want to represent. If we want to include the Fibonacci term, we use a 1 in front of the corresponding Fibonacci number, and use 0 otherwise. So like binary, we can make a similar expression: 1*8 + 0*5 + 1*3 + 0*2 + 1*1 which equals 12. This expression is also an example of Fibbinary, where each bit tells whether or not to add the corresponding Fibonacci number, starting with 1, 2, 3, 5, 8, etc.

“But Peter!” You might say. “That uses 5 bits of information to represent using Fibonacci! It looks like 10101!” I hear you. But we’re not done! Do we need all those bits? No! And the reason is pretty simple. If we ever see a ‘1’, we know the next digit must be a ‘0’. This is because if there ever were two consecutive ‘1’ bits in a Fibbinary representation, then we might as well use the next Fibonacci number that’s composed of those two smaller, consecutive Fibonacci numbers. This means we can omit zeros that occur after ones. Our bit representation “knows” to skip adding any Fibonacci numbers after a ‘1’ is seen. So how would we represent the number 12 again, using, what I’ll refer to from here on out, as “Zeckendorf representation”? Well, we had 10101 with Fibbinary representation. And we can just drop those unnecessary zeros because the prior 1’s already tell us to skip those Fibonacci numbers. So we are left with 111! That’s just 3 bits! And in binary, it took us 4 bits to represent the number 12! So we just saved a whole bit! That’s a 25% reduction!

“But Peter, that’s just one bit! That’s not compression!” Well, technically it could be, if it scales to larger numbers. I’ve done some investigating and, unfortunately, it turns out that large numbers with smaller Zeckendorf representations are unlikely and there’s a limit to how good it can get. But this does allow us to more compactly represent numbers, and therefore, data, if it happens to fall on or close to a “well compressible number”.

What do I mean by a “well compressible” number? Well, we can think of the degenerate case where the Zeckendorf representation of the number is all 1’s, which can reach out to larger numbers “faster” than using binary representation, and each ‘1’ bit conveys more that 1 bit of classical binary information since it tells us the next digit to add cannot be the next Fibonacci number. For example, the binary number 11111111 is 8 ‘1’ bits. In binary, that represents the decimal number 255. But interpreting those 8 ‘1’ bits with Zeckendorf representation, it expands out to 1 + 3 + 8 + 21 + 55 + 144 + 377 + 987 = 1596, a much larger number than 255. And representing the decimal number 1596 as binary is “110 0011 1100”, which is 11 bits. So in this example, we were able to represent a number needing 11 binary bits with 8, a ~27% reduction.

Here are some graphs showing the ratio of bits necessary to represent numbers using Zeckendorf representation versus binary representation. The green line at 1.0 represents par compression; no benefit to using Zeckendorf representation. When the blue line dips below the green line, that demonstrates that the number on the x-axis had a Zeckendorf representation that used fewer bits than its binary representation. The following graph shows this compression ratio for numbers up to 1,000.

The graph below plots much more data, so it is easier to see interesting patterns for when the Zeckendorf representation was beneficial. Perhaps such patterns could be utilized to search for the optimal compression method. More on that later in the article.

And just for fun, here is a graph for all numbers up to 100 million.

So, as you can see, there is some potential for using these numbers to compress data. The tradeoff is that you are not guaranteed to be able to compress your data. This can be seen by how thick the blue lines are above the green line at par, versus the lesser amount of blue below the par line. Later in this article, I’ll go over some statistics for how likely this actually is. TLDR: the odds are not great for data larger than 1kbit, unfortunately.

Why Does This Work?

It is strange to think that there exist large numbers that require less information to represent than smaller numbers. On the surface, it seems to break long-standing ideas in information theory. I mean, we’ve known about data compression for a long time which is essentially the same concept of certain larger “numbers” requiring less information than certain smaller ones. But this Zeckendorf based transformation of data feels like a different class of compression algorithm altogether. After all, it’s an extremely simple algorithm and does not really require any knowledge or inspection of the input bits unlike other compression algorithms. We are simply taking a string of bits, interpreting it as a number, and representing it as a different string of bits.

My attempt at making this intuitive is to say that “representing a number with Zeckendorf bits produces a shorter string of bits if the input data was composed of lots of Fibonacci numbers.” The more Fibonacci numbers that the input was composed of, the better it can be “compressed”. The extreme case here is having a Zeckendorf number where all bits are 1. Later in the article, I will do some inspection on these numbers, which I will call “All Ones Zeckendorf Numbers”, or AOZNs. The extreme opposite case is having a number composed of only 1 Fibonacci number, so the string of Zeckendorf bits is mostly zeroes and one 1. I’ll call these numbers “poorly compressible”, with respect to Zeckendorf compression.

Since a number is better compressible if it is composed of many Fibonacci numbers, maybe we can make a connection here to the real world, where golden ratios and spirals emerge that are also composed of Fibonacci numbers. I haven’t settled on a term for this, but perhaps we can call it “settling” or a “settled number”, pun intended.

Zeckendorf Compression

I propose a couple standards for Zeckendorf based compression.

1. Padless Zeckendorf Compression (lossy)
2. Padded Zeckendorf Compression (lossless)

The Padless Zeckendorf Compression algorithm is essentially treating the input data as a big integer and then representing this big integer with Zeckendorf bits. I call it padless because when decompressing, if you don’t know the original file size, you might lose leading zeroes which should have been padded, because they were effectively dropped when interpreting the input data as an integer. Therefore, this is a lossy compression algorithm. The Padded Zeckendorf Compression algorithm retains the original size of the data in the output format, so that it can pad the decompressed output with leading zeroes. This loses some compression efficiency because, now, we need to store the original file size along with the compressed data, but it is lossless.

I have an MIT licensed open source implementation for these in Rust at https://github.com/pRizz/zeckendorf, so anyone can play around with it. I have published a Rust crate of this library, called zeck, and a corresponding WASM compiled npm package called zeck.

I also created a basic demo web application, which uses the WASM compiled Rust code, to compress and decompress files losslessly by simply dragging and dropping. The website will tell you if the transformed data was or wasn’t smaller than the original. I have open sourced it on GitHub. As of now, the algorithm requires improvement, because attempting to compress or decompress files larger than about 10kBits requires generating, caching, and dealing with Fibonacci numbers that are > 10,000 bits long, which causes memory issues. That’s an astoundingly large number when you think about it: 2¹⁰⁰⁰⁰. For reference, the number 1 trillion only takes about 40 bits to represent. One of the largest named numbers is a centillion, which represents 10³⁰³ and takes only about 1,000 bits to represent. So we’re dealing with some pretty astronomical Fibonacci numbers here!

Performance of Padless Zeckendorf Compression

This compression is probabilistic, meaning it is not guaranteed to compress data since most Zeckendorf representations of integers require more bits than the input data. This is evident in the graphs above, where a majority of the blue lines are above the green line at par. Since it it probabilistic, I have generated some very basic statistics for how well or poorly this Zeckendorf compression algorithm performs at compressing data.

After testing, I discovered that there is a pretty steep drop in the odds of any random data being favorably compressible after the input data increases larger than a few hundred bits. Here is a graph demonstrating this falloff.

Early on in the graph, you can see that there is a decent chance of the data being smaller after being compressed, between 10–15% chance. But as the size of the input data grows, the graph collapses approaching a 0% chance of being compressible after around 1 kbit. Some examples for the way to interpret this graph are: if you supply 100 bits of random data, there is a ~10% chance of the output being smaller than 100 bits. If you supply 1 kbit of random data, there is only a ~0.01% chance of the output being smaller than 1 kbit.

Beyond that, it would be interesting to see how well the data does get compressed if it happens to be favorable. That is what I try to show with the graph below. It shows a number of different series based on compressing all inputs up to the value shown on the x-axis. For example, the dot on the x-axis at 1e5, means the corresponding y values used all numbers individually, up to 100,000, for compression. These scales are quite small, but they are comprehensive, in that all numbers up to the input limit were compressed. The reason I don’t go much higher is that it took very long (~20 minutes) to generate data on compressing all numbers up to 100 million, and the returns diminish as the data gets larger.

Unfortunately, this graph does not test very large scales; the number 1e8 is 100 million, which only takes about 27 bits to represent. The graph below zooms out and shows the average and median compression ratios up to 5 kbits, using 250,000 random samples at each input data size.

You can see that the “favorable” compression ratios converge to around 1.0 after 1 kbit, which agrees with the prior graph showing the odds of compression being favorable. But the median and average “compression” (maybe “transformation” is a better term here because the size of the data tends to increase) tends to approach on the order of 1.042, meaning that on average, arbitrary data that is transformed by the Zeckendorf compression algorithm gets larger by about 4.2%.

There will naturally be outliers in these graphs at “All Ones Zeckendorf Numbers”, which is the degenerate case where all the bits in the Zeckendorf representation are ‘1’. But again, this is extremely rare for a piece of data to fall on or near those numbers, so it is difficult to see them in the graph. But there is potential for optimization if the input data could be slightly “massaged” to be nearer to an “All Ones Zeckendorf Number”. I go over that more in the next section.

Further Compression Algorithms and Tweaks Related to Zeckendorf Compression

I can imagine there is a lot more work to be done in figuring out more optimal and efficient algorithms based on this work. I will enumerate a few possible directions.

“All Ones Zeckendorf Numbers”

Whenever there is a “Zeckendorf Bits” list that is composed of all “use bits” or “1's”, then this number is able to “reach” out to higher numbers faster than binary. For example, let’s look at “1111”. In binary, this represents the decimal number 15 by summing 1 + 2 + 4 + 8 (or by doing 2⁴ — 1). But if we interpret this as four Zeckendorf “use bits”, we get 1 + 3 + 8 + 21 which equals 33, a number quite a bit larger than 15.

Below is a graph comparing the growth rate of “all ones Zeckendorf numbers”, or AOZN’s for short, to the Fibonacci numbers, binary numbers (2^n), and powers of 3 (3^n). And interestingly, I found a relation between the growth of Fibonacci numbers and powers of the golden ratio (φ, or 1.618…), as well as a relation between the AOZN’s and powers of the golden ratio squared, φ²: namely, these pairs of sequences grow at the same rate, just offset by some constant factor. You can easily see these pairs have very similar slopes in the graph.

If we consider a “lucky” example, let’s suppose we want to compress a file that happens to be not too “far” from one of these numbers represented by an AOZN. For example, let’s say our data was equal to a number equaling 100k ‘1’ Zeckendorf bits plus 1k arbitrary bits. As raw data, summing 100k Zeckendorf Use Bits produces a number that takes about 138k bits to represent in binary. With this, we can represent our 138k of data with two pieces of information: the count of ‘1’ bits in the AOZN and those arbitrary 1k bits. Since there are 100k one bits, we can just represent this part with the number 100,000. The number 100,000 only takes roughly 17 bits to represent (log2(100,000)). So we can specify a file format that is the combination of these two pieces of information, which only needs roughly 1k bits plus 17 bits. So we have effectively compressed our data from 138k bits to about 1k bits, a 99% reduction. This seems great, but the catch is that it is extremely rare for data to be “near” an AOZN. In general, most numbers are far enough from an AOZN such that it takes roughly the same number of bits added to that number to produce the target data, which results in no savings.

Chunked Preprocessing

Since we figured out that the odds of any compression happening past 1,000 bits falls off a cliff, what if we first chunk the input at like 500 bit chunks, so that every chunk has a somewhat higher chance of being compressed?

Immediately, I can think of a few issues with this approach. Namely, how does the decompressor know how big the chunks of data to decompress are? We will now need to store additional information about the chunk sizes somewhere, perhaps in a header. But that now reduces the compression efficiency.

For an example, let’s say we chunk some data at 100 bit chunks, which has a 10% chance of being compressed at a median of ~2.5% savings. Then each chunk will only be saving less than 1 bit on average. And for representing bit sizes up to 100 bits, we will need log2(100) bits or 7 bits per chunk to tell the decompressor how many bits to read per chunk. Dang. This method will likely not be useful.

Only Compress Data Sets Between 100bits — 1kbit

This is a similar strategy to the Chunked Preprocessing, except that we are only considering individual files that are less than than 1 kbit. The benefit here is that we don’t need to explicitly store extra data in order to recombine chunks; the operating system could store the true file sizes, which I believe it already does.

Doing similar math to the chunked preprocessing, if all your data is around 100 bits each, and there is a ~10% chance of compression at a median of ~2.5% savings, then you can expect your data set to be reduced in size by about 0.25%. Unfortunately, that is not a very impressive number. But at a large scale, this could theoretically produce some savings.

Lossy Zeckendorf Compression

There might be other ways to compress the data in a lossy manner, using the Zeckendorf algorithm as a base. I could imagine there being methods of preprocessing the data first, with something like a Fast Fourier Transform or a Discrete Cosine Transform (used in JPEGs), and massaging the data to fit into more compressible Zeckendorf numbers, as mentioned in the “All Ones Zeckendorf Numbers” subsection.

Compositions with Other Compression/Coding Algorithms

Even though Zeckendorf compression may not be useful in and of itself, it could be used in conjunction with other compression algorithms as a “last leg” if favorable.

This is analogous to how Huffman Coding is used, which, according to Wikipedia, is used as a “back-end” to other compression algorithms like JPEG and MP3.

If applying Zeckendorf compression is favorable for some file, then it just needs a singe piece of information in the resultant compressed file to signify that it was used, so that the decompressor know to decompress it. My compression utility, called zeck-compress, stores files with a .zbe or a .zle file extension, depending on if the input was interpreted as a big endian integer or a little endian integer.

Addition/Multiplication/XOR Then Compression

It is possible that there are “good numbers” to preprocess the input data with, which then produces data that is more compressible via Zeckendorf. If it does help, then the resultant compressed file just needs to store the operation, the “good number”, and the resultant compressed data to remake the original data (if the storage size of these three pieces of data happens to be less than the original input).

One strategy is to find the nearest AOZN to the data and then get the difference between it and the AOZN to know what number the decompressor needs to add to it. I did some testing with this method, but it is extremely unlikely for large pieces of data to be near AOZNs, and even if it is, the number to add it with is likely to take as many bits as the input data itself, which yields no data savings.

It’s possible that performing a division on the input data would be more beneficial, because the resultant data can be much smaller than with subtraction, with a similarly sized divisor. But this also will have diminishing returns because as the size of the divisor grows, the efficiency of the compression is reduced. I have not yet tested this method.

Then there is XORing the data, for which there could be a few different schemes. You wouldn’t want to store a piece of XOR that is as large as the input, otherwise, you’d need to store the whole thing in the result, which cancels the benefit of compression. Another scheme is to have a repeated piece of XOR data, which could be mirrored throughout the whole input, in order to reduce the size needed to store the XOR data. But this would be a costly operation, to search for many permutations of data to XOR with to find one that yields beneficial compression. I have not yet tested this method either.

There are likely other mathematical or bit operations I am not considering, but they may be useful here.

Inverted Zeckendorf

Since trying to “compress” data with Zeckendorf tends to produce more data than less, what if we treated the input data as already compressed and try to “decompress” it with the thinking that, since probabilistically most compress actions produce larger data, maybe decompress actions produce smaller data.

Unfortunately, this doesn’t work. If you think about it, if we take arbitrary data, and treat its bits as a list of Zeckendorf “use bits”, then summing over those bits by converting them to Fibonacci numbers will tend to yield, on average, a larger number than simply interpreting the input as binary. Therefore, this is likely not a useful avenue for compression.

AOZN List

What if we represented our data as a list of AOZN indices? Since AOZNs can reach out to larger numbers faster than powers of two, this could be a new numbering system essentially. And perhaps utilizing skip bits could work here as well.

Well, looking into it, the first handful of elements of the sequence of AOZNs is 1, 4, 12, 33, 88, 232, 609, 1596, 4180, 10945, etc. Already, we can see one issue: the gap between the first two elements (1, 4), means that we would need 3 bits of information to represent the number 3, or any other number where 3 was the remainder after subtracting other AOZNs. That’s not great. And subsequent gaps mean we may subsequently need multiples of other elements to represent other numbers. I have not tested this method further.

Further Related Areas of Research

Circuits / Hardware

If the Zeckendorf representation turns out to be useful for certain applications, then it might make sense to produce hardware optimized for dealing with the Zeckendorf representation. Or, it’s possible that certain operations on hardware execute faster when dealing with the Zeckendorf representation versus binary representation. Some operations that would be interesting to test are all of the basic numeric operations like addition, subtraction, multiplication, division, etc. I have not tested this yet.

And since the Zeckendorf compression and decompression algorithms involve determining extremely large Fibonacci values, it might be worth it to have lookup tables in hardware, for hyper fast lookups. It would be interesting to investigate the performance of having a sped up Zeckendorf codec in terms of time and cost savings with specialized hardware.

Other Numbering Systems

What about using a numbering system based on other sequences, like prime numbers? Could that work in compressing data?

A cursory glance at this reveals that it does not quite have the same properties as a numbering system based on Fibonacci numbers. I mean, there is the Fundamental Theorem of Arithmetic, which states, somewhat analogously to Zeckendorf’s Theorem, that all integers greater than 1 have a unique representation of products of prime numbers. But it is not as clear as to how to represent this using 1’s and 0’s, while saving data. Maybe someone more clever than me can take a crack at this…

“Poorly Compressible Numbers”

Since we have the idea of AOZN’s being “well compressible”, what would the opposite look like? Well, that would be a string of 0 bits, and then a 1 bit, to “use” a Fibonacci number. The reason for this is that by using mostly 0’s, we do not save any data that we would have saved by using 1 bits and skipping Fibonacci numbers. When we have a large string of 0’s and then a 1, this is basically equivalent to indexing a specific Fibonacci number. It’s like a “Fibonacci selector.”

For example, if we have the bits 100, this can be interpreted as 1*F(2) + 0*F(1) + 0*F(0) which is 3, which is the third “effective Fibonacci” number or the fifth “actual Fibonacci number”. I use the term “effective”, since, like in Fibbinary, we skip the first two Fibonacci numbers which are 0 and 1; 0 does not help us and 1 is redundant to the second Fibonacci number. An “effective” Fibonacci number is just two Fibonacci numbers forward. So the third effective Fibonacci number is 3, (1, 2, 3, 5, 8, 13, …).

AOZN Compressibility

What makes AOZNs so compressible? I think one thing that makes it special is that it is a special case of Zeckendorf bit lists, which can be thought of as a variable bit length encoding. Some larger numbers take fewer bits to represent than some smaller numbers, and all numbers are uniquely representable. I think that is a fascinating property; I’m not sure if there are other sequences that have that property. It’s like getting more for less, and losing nothing. I would surmise that there are other sequences that can mimic these properties, but I can’t fathom another consistent way having larger numbers taking less space than smaller numbers, simply by using a different numbering system.

The manner in which the Zeckendorf bit list is a variable bit length encoding is such that whenever we see a 1 bit in the list, we “skip” the next Fibonacci number. And since we don’t need to store those unnecessary 0s, we save on data. In this way, it reminds me of a skip list, which is a data structure that, similarly, skips the traversal of elements at certain locations when doing a search. Perhaps we could think of different kinds of skip lists for Fibonacci numbers, based on properties of the input data, which could save further data. My Zeckendorf algorithm can be thought of as the first-order skip list for representing numbers. But there could be other schemes that skip more than one index at a time, if that is made clear in the algorithm. And since not all numbers could be representable by skipping more than one index, that could be another example of a lossy compression, since some data would need to be compressed at the nearest possible representable string of bits. Further investigation is needed here.

Other Things

Has this been done before?

As far as I could find, this method has not been done before. I find it funny that I could not find prior examples. I’d think that someone would have thought of this before, since it’s so close to Fibbinary. Maybe it is out there somewhere but was shelved as an impractical system. Either way, I’m sure someone will reach out to me to point out that this was a known algorithm. Even if it was already known, at least I had fun developing it, and I hope we could find something useful from this research.

Did you use AI?

I, Peter Ryszkiewicz, came up with this idea roughly 6 years ago, before ChatGPT was even released. I have private prototype code on GitHub in Typescript, that can be used to prove this, and GitHub could attest to the push timestamps since git histories can be faked. But the code is old and ugly so I’m choosing not to publicize that. That being said, the recent implementations in Rust and the web application did use AI assistance (Cursor and Lovable mostly).

Did you use AI to write this article?

No, I decided against using AI for this article so that my writing style could be expressed faithfully. I also don’t like the writing style of AI, because even though it is usually very clear, it tends to be tasteless and soulless; a chopped salad of all the labor of all the great authors who have lived and died before us. I don’t like that. When you read this article, you are actually getting a taste of what goes on in Peter Ryszkiewicz’s personal neural nets 😄😁

Ironically, after publishing this article, I ran it through some AIs and it pointed out a number of interesting things, including some mistakes. Subsequently, I have fixed the mistakes in this article and I will post another article detailing the interesting findings, shortly.

Addendum

All plots were made with the Rust library plotters, and all code for generating the plots are available on my repository at https://github.com/pRizz/zeckendorf/blob/main/src/bin/plot.rs.

Code for generating the dark mode compatible LaTeX formula images is available at https://github.com/pRizz/zeckendorf-article.

The Rust crate is published here: https://crates.io/crates/zeck

The npm library is published here: https://www.npmjs.com/package/zeck

The demo app is published here: https://prizz.github.io/zeckendorf-webapp/

The source code for the reference implementation is here: https://github.com/pRizz/zeckendorf. PRs welcome! Lots of hard work is needed to optimize the performance and memory pressure of compressing and decompressing!

A seed is like a username-password combo used to access your funds within cryptocurrency wallets. Each seed should be unique and very difficult to guess or brute-force. If someone happens to generate the same seed as you, they may gain access to your funds as well. And seeds are quite short, typically 64 characters long. These seeds are used to generate the keys used to sign transactions and generate the public addresses where the funds are stored.

You may be worried that bad actors could spin up a bunch of computers and start generating vast numbers of seeds to get access to your funds. But, when you consider this mathematically and physically, it is nearly impossible with today’s technology with even a large amount of time and resources.

Try counting to 10… that probably didn’t take very long. Now try counting to 100… That takes a bit of time; roughly 10 times as much time as counting to 10. Now count to 100,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000. That is about the possible number of unique 64 character cryptocurrency seeds consisting of 0–9 and A-F. Most cryptocurrencies utilize 256 bits as their seed, which equates to 2²⁵⁶ (or about 116e75 or 116 quattuorvigintillion) possible seeds (although this whole range may not be valid in some cryptocurrencies). Add a few more bits and that is enough seeds to assign to every atom in the observable universe. (Some have estimated roughly 10e80 atoms in the observable universe.)

Let’s say my computer can count to a billion in one second. (This is roughly the typical counting speed of today’s hardware.) So, if I wanted to enumerate all possible Bitcoin seeds, I would need 1.16e68 seconds, or about 3.66e60 years (3.66 novemdecillion years). That is about 2.69e50 times longer than the age of the known universe! Let’s say we used a billion of these computers in parallel. We would still wait 2.69e41 times the age of the universe! On top of that, enumerating seeds isn’t enough. You still need to generate an address from the seed and query the blockchain every time you generate a seed to see if it even has any funds. This adds even more time to the equation!

The odd of finding any seed are slightly better, if we consider that there are probably millions if not billions of seeds that are in use. But again, this only helps us a certain order of magnitude. Let’s say we will need 1 trillion seeds to satisfy all people and IOT devices in the future. Your odds of randomly finding a seed that is in use is 1e12 / 116e75 = 8.62e-64 %, which is ridiculously minuscule.

As we can see, if you have a perfectly random seed, it would be very difficult for a malicious party to obtain your funds. The problem then becomes, how does one create a perfectly random seed?

Cryptographic Randomness

There is such a thing as an unsafe random number. If you have a pseudo-random source of numbers, it is possible to find a pattern in the randomness. There was an attack on IOTA seeds some months back when users tried to generate their own seeds. People were posting, whether by malicious intent or simple ignorance, insecure methods of generating IOTA seeds. The main one in question was a PowerShell seed generator. PowerShell is a terminal program on Windows machines that allows you to interact with the computer in a command-driven manner. One would copy and paste these one-line seed generating commands into PowerShell and it would spit out a seemingly random string of characters that make up an IOTA seed. The problem was that this PowerShell command used a pseudo-random number generator; not a fully blown cryptographic random number generator. In this case, the command that people were posting everywhere online could only generate a total of about 2 billion unique seeds. 2 billion is well within the range of seeds that an attacker could search and detect whenever funds were transferred. Eventually people figured this out and there was a reddit post about the matter highlighting these issues. But not before funds were lost to groups of anonymous hackers.

Real money was lost because people didn’t understand the importance of cryptographic random number generators. A cryptographic random number generator has certain properties that make it well suited against these kinds of attacks. The most important property one wants is uniform randomness, that is, you want the exact same chance of generating any seed as any other. Otherwise, there is bias, and this bias can make guessing the random number easier. Another property is that of random sequences. This was the main problem with the PowerShell command mentioned earlier: it could only generate 2 billion unique sequences of random numbers, and hence, could only generate 2 billion unique seeds. The reason it could only generate 2 billion unique sequences is because it is a pseudo-random number generator (PRNG). While being vastly easier to implement in computer code, PRNGs are not sufficiently random for these financially significant use cases.

It is a sad tale in cryptography and cryptocurrency for all of those funds to have been stolen. I partly blame the IOTA foundation for putting the onus on the users to properly generate cryptographically random seeds. Just about every other crypto wallet in existence has methods of secure seed generation in the app itself. But the IOTA foundation chose to force the users to figure it out for themselves. Until they fix this, we must continue to handle this ourselves or wait for the upcoming IOTA wallet from UCL that should improve on this shortcoming.

The IOTA wallet used to have a seed generator, but it was removed. I did some digging and found out that their generator contained a flaw: it was biased. They used the modulus operator on a cryptographically random number which makes the result deviate from the desirable uniform randomness. I don’t think they ever announced their mistake, but rather quietly removed it with the commit message, “Remove unused functionality.”

It’s actually not too difficult to implement a secure seed generator in JavaScript. Later in this article, I explain how my project, Secure Seed Commands, contains secure seed generating commands for IOTA that could be implemented in the wallet and/or used for cold storage.

Random Number Bias

But we can learn something here. How bad was this mistake? Are old wallets at risk of being hacked? This part gets a bit math and computer science heavy.

Seeds in IOTA require 81 characters, or “trytes”, consisting of the letters A to Z and the number 9. (This is due to their reliance on trinary math.) They generated 81 cryptographically random, unsigned, 32-bit integers and modded them by 27 so that these numbers could be mapped to the trytes. An unsigned 32-bit integer goes from 0 to 4,294,967,295. As long as the random number falls in the range of 0 to 4,294,967,273, we are ok, because modding this by 27 will produce a uniformly random number.

Even with this bias, the odds that their generator produced a good, non-biased seed are actually quite good, funny enough: (4,294,967,273 good possibilities/4,294,967,295 possibilities)⁸¹ = 99.999958509%. Put another way, the odds that you got a biased seed are 1 in about 2.4 million. And that probably means only a single letter had a different chance of being picked. It is much more unlikely for two or more letters to also have had this bias.

With the bias, the odds of generating the letter 9 or any letter between A and U are 159,072,863 / 4,294,967,295 or ~ 3.703703708%, whereas the odds of getting any letter between V and Z are slightly less: 159,072,862 / 4,294,967,295 or ~ 3.703703685%. That’s a difference of only ~0.000000023%.

With this information, I believe it is unlikely for an attacker to brute force a biased seed.

Malicious Seed Generators

There was a big problem for IOTA recently about users’ funds being “stolen” from their wallets due to unsafe, online seed generation. Here is an article with more details about how it was done. In this case, users generated their seeds on a website that essentially sent these seeds back to the scammer’s server, where they eventually used them to log into the users’ wallets and withdraw their funds. This is a classic case of a phishing website: you think it’s trustworthy, but it turns out to be malicious. Also, these seeds were produced in the browser, which could let malicious browser extensions silently read the seeds that are generated.

Secure Seed Commands

I created a website to be a reference for creating cryptocurrency seeds securely, not just for IOTA but also a few other popular cryptocurrencies. This is useful when you want full control over the seed generation process and want to securely generate seeds independently of wallet software. These commands may be executed on a number of different platforms securely, namely: Windows, Mac, Linux, JavaScript in NodeJS and on Web, Ruby, and Python 3.

Here is a link to the IOTA seed generating commands: https://www.secureseedcommands.com/#/IOTA.

No seeds are generated on my website. It is only a reference of commands with explanations used to create them. All commands on this website utilize the proper cryptographically secure random number generators on each platform.

I do still have a disclaimer when reaching the website, saying that the code, which is open source, is still in beta and has not been formally audited by third parties. I want to reach out and ask the community for your feedback so that we can gain some confidence in the trustworthiness of the project and seed generating commands.

I will repeat some best practices listed at the bottom of the website here:

• Disable your internet while generating seeds.
• Always clear or overwrite your clipboard after pasting your seed. Malicious websites and applications can silently read your clipboard.
• Generate multiple seeds and splice them together randomly. This can mitigate key logging / terminal history attacks and give you a sense of greater control. Ensure you have the proper number of characters.
• Encrypt your seeds. Example password encryption with gpg: gpg --symmetric seeds.txt and decryption: gpg seeds.gpg
• Study the above commands and their explanations so that you could put them in manually.

Be wary of copycats and mirror websites, as they may have malicious modifications to the seed generating commands. You can also download the code and run it yourself if you install NodeJS and run the command npm install; npm run dev in the directory.

I also encourage the IOTA team to take a look at my seed generating commands and consider adding them to the current wallet, so that users can have a simpler and more secure way of generating their seeds.

You can follow me and my company, P Rizz Ventures LLC, on Twitter, Medium, Facebook, LinkedIn, GitHub, and Patreon.

Update Feb 2, 2018: This article was written before RaiBlocks rebranded to NANO. I am leaving occurrences of RaiBlocks for historical purposes. Wherever you see RaiBlocks, you can substitute the word NANO.

There is a new generation of cryptocurrencies gaining popularity; namely that of fast, feeless, minerless cryptocurrencies (I’ll use FFM for fast, feeless, and minerless from now on). At the moment, there are only a few to name, and IOTA and RaiBlocks are two of the most prominent ones at the moment. They differ quite vastly in how they implement FFM. This means they have different characteristics in how they perform, their complexity, and their robustness. I’ll go over these in the following sections.

In general, I think these inventions are fantastic and we need more competition and research in the area of FFM cryptos. A few competitors and copycats are already starting to pop up, for example Radix, which sounds interesting, but is still under development. It’s hard to say whether there will be “one to rule them all” because these different cryptos perform differently and specialize in different use cases.

The Problem with Mining

Mining has gotten a lot of flak recently as people have performed calculations on how it will affect energy demand and global warming. Here is an interesting rebuttal by Andreas M. Antonopoulos, on YouTube. He makes many good points, but he does not fully convince me.

When there is an incentive to spend incredible amounts of energy to send transactions (especially microtransactions), you have an inefficient, unsustainable system that is difficult to fix. (Transaction fees for Bitcoin today are on the order of $30.) Miners who already exist don’t want their expensive AntMiners, GPUs, and CPUs to go to waste. So there will be push-back from these investors from deploying things like Ethereum’s Proof of Stake model. That being said, I do think their Proof of Stake is a step in the right direction. It’ll just be very challenging to get those miners to convert, killing their original business model and investments.

There are “layer 2" approaches to battle this inefficiency, with things like the Lightning Network for Bitcoin and the Raiden Network for Ethereum. Even IOTA has its own second layer called Flash Channels, because fast just isn’t fast enough. But there are still a few problems with these. The simplest rebuttal is that you will need someone to host, maintain, and facilitate this second layer, which introduces fees. In theory, this fee is smaller than the normal transactional fee at layer 1. But it is a fee nonetheless, which kinda puts us back into VISA-land. Another issue is that it erodes the decentralized operation of these coins. When you have large corporations with their own Lightning/Raiden/Flash channel, there is now a point of failure in terms of corruption, hacking, and simple mismanagement. I think it will take a lot of effort, not only to fully implement these systems, but to make them robust, secure, and maintainable.

Another issue is that mining seems to be causing a centralization of hash-power. For some reason, we are not seeing as much competition in this space as one would hope. Basically, China produces a good majority of the Bitcoin mining power in the world, which could eventually lead to issues with double spend attacks on the coin if these companies were to collude. I don’t want to bash China, but they also don’t have a good track record with the government routinely delving into commercial and personal affairs, especially in the cryptocurrency realm, threatening the banning of ICO’s and crypto exchanges.

How Do These Cryptos Work?

In order to send transactions over the IOTA network, you, the client, must perform minimally heavy computations on two previous transactions in the network. These computations take, on the order of, a few seconds to a few minutes, depending on the power of your GPU (the proof of work algorithm in IOTA is GPU optimized) and your luck. Once you successfully perform the proof of work required, your bundle of data gets broadcasted over the IOTA network, where it sits waiting to be confirmed by future transactions. This is a pay-it-forward kind of system. Once your transaction gets enough confirmations from other peoples’ transactions, your transaction will be deemed fully confirmed.

In theory, the more transactions that occur over the network, the faster your transactions get confirmed. In the earlier days of IOTA, this would only take a few minutes, if that. Right now, there are congestion issues which is causing delays in confirmation rates and times. This seems contradictory, given the “infinite scalability” being marketed about IOTA. But, in my opinion as a developer and node operator, and looking at the node code itself, there are lots of optimizations that can be done to speed this process up. I have experienced many CPU spikes and memory leaks while operating my nodes (and I’ve posted some of them in their GitHub Issues), but I am confident that these are only technical issues which can be fixed with a few hundred engineering hours. (Update, Dec 23, 2017, the IOTA network and congestion issues have improved since recent updates to the node and wallet)

One huge area of improvement will be in porting the node code from Java to Rust (performance stats) or another high level, high performing, portable programming language. Java is very easy to learn and has many nice features as a high level, object oriented programming language. But it must be run through the JVM (a virtual machine that allows for the code to be executed on just about any computer on the planet) which comes at the cost of performance.

RaiBlocks operates on a crypto architecture they call “block lattice”. They provide a nice wiki page where they describe how this works. The gist of it is that RaiBlocks isn’t just one long blockchain, like Bitcoin or Ethereum; it is a database of blockchains where each user (or address) gets their own blockchain that only they can add onto. Users send funds by creating two blocks: one send block on their personal blockchain and one receive block on the recipient’s blockchain. Users receive funds by “pocketing” any outstanding receive blocks into their personal blockchain. Users do not have to be online to receive funds (this is a common question concerning RaiBlocks’ novel “pocketing” system). Whenever the user decides to access their funds, the wallet itself will automatically “pocket” any outstanding funds. Pocketing funds essentially means signing the receive block with your private key, so that it can be added to your personal blockchain.

Consensus Algorithm

In IOTA, transactions get attached to the “tangle”, which is a directed-acyclic-graph (DAG) data structure. (Git works using this same data structure!) As more transactions get added to the tangle, a “weight” is added to attached ancestor transactions. When a transaction has enough weight, the transaction will exhibit a “confirmed” status. In principle, this confirmation could be as quick as seconds when there is a sufficient flow of transactions across the network.

In RaiBlocks, there is a different confirmation system based on “representatives”. In general, all that is needed is your cryptographic signature on your “send” and “receive” blocks. When the node syncs, it runs through the ledger to ensure that the signatures are authentic.

In order to prevent double-spend attacks, RaiBlocks has a “representative system”. A representative in the system is basically an address with a lot of money. The representative acts as the arbiter of which double spent block to go through and propagate through the system. I’ll elaborate a little more on potential attack vectors here, later in the article.

Incentive for Running Full Nodes

A common question that gets asked about these FFM cryptos is: “Who is going to pay for running the full nodes?” It’s a very good question. In most other cryptos, like Bitcoin and Ethereum, there is an incentive for the miners to run full nodes because they can collect lucrative mining fees by doing so. But there are no miners in IOTA or RaiBlocks.

There are a number of answers to this question, and there are slightly different answers depending on if you are running an IOTA node vs a RaiBlocks node vs other cryptos.

For those that are new to cryptocurrencies, a node is basically a computer that facilitates transactions across the global network. Nodes may be added or removed at any time by anyone on the internet and the cryptocurrency, as a whole, will continue to function. Cryptos tend to need a minimum number of nodes to prevent attacks on the network, but that’s another topic.

Let’s do a few calculations and see if these networks can sustain themselves

Every exchange needs to host their own nodes as a point of withdrawals and deposits. Let’s assume every exchange needs 5 nodes on average for load balancing purposes and upgrades. (They will need more or less than that, depending on traffic, but 5 is a nice little conservative estimate.) Now let’s figure that once these coins become popular, they will be available on roughly 100 exchanges around the world. Again, a conservative estimate, as there are hundreds of popular exchanges around the world, with new ones popping up all the time. This gives us 500 nodes, once IOTA and RaiBlocks are widely adopted in the exchange industry.

There is also a commercial need to run nodes. Businesses small and large are joining the cryptocurrency space (as am I, with my company P Rizz Ventures LLC), and we need to host nodes to provide for our services. Let’s suppose there are thrice as many online stores, marketplaces, and services than exchanges. I think this is pretty conservative, given that there are way more online stores than there are online exchanges on the internet. Let’s assume they will need an average of only three nodes each, since they will probably have less traffic than a highly popular exchange. This gives us a total of 900 nodes in the commercial space.

We will also have many smart devices in our future. Forbes references a paper that predicts 75 billion IoT devices by 2025. Let’s say that just 0.001% of these devices will need to run full nodes in order to achieve a high quality of service. That right there is 750 thousand full nodes running on the network.

So with all these industries combined, there will surely be a strong baseline of nodes at any given time. I predict IOTA and RaiBlocks will gradually and naturally ramp up their node numbers over the coming years, as they gain more and more popularity.

Suitability for Developers

IOTA provides official Javascript, Python, C#, Java, and Golang libraries for working with the network. They also provide their Proof of Work library, which they call curl, or kerl now, which is available as a C library and for use in web browsers with WebGL2. They provide versions of their node implementation called IOTA Reference Implementation, or IRI, in Java with plans of porting it over to C++, Rust, and Golang. In my opinion, I hesitate for them implementing it in C++ for a host of reasons, with the main one being a higher potential for bugs and vulnerabilities. C++ has a place for high performing applications and OS kernels, but I don’t think it’s a good decision here. We can debate it, but that’s another story.

API support for RaiBlocks is quite good, as well. They have RPC libraries, for interacting with nodes in Javascript, Python, PHP, and Elixir. I can’t quite tell whether these are official libraries vetted by the RaiBlocks organization or not. (If someone from the RaiBlocks team can clarify, that would be great!) Either way, they are all endorsed and posted on their devtools website. There is also a library for performing Proof of Work in the web browser, written in WebAssembly. They also have a few more tools for interacting with the protocol and a package for Fedora.

Overall, both projects have a decent level of support for developers to start building with and integrating these cryptos into their own projects and businesses.

Suitability for IOT

Both cryptos provide a great use case for microtransactions in the Internet of Things space. We will definitely need to utilize FFM cryptos if we want our machines to quickly and autonomously interact with currency. Let’s look at both from a few different angles.

Data Streams

Transactions in IOTA allow for roughly 1 kilobyte of arbitrary data to be attached. 1 kilobyte doesn’t sound like a lot, but it opens up a realm of possibilities for the transfer of data on the tangle. (This is how my IOTA-based chatroom app, Chatangle, works.) IOTA’s data marketplace will also make great use of this data attachment to facilitate the transfer of data between devices and the marketplace itself. This is a great feature to have on layer 1.

RaiBlocks does not have a built in mechanism for data transfer on layer 1. I had an interesting conversation with a fellow redditor about this topic and he brought up the idea of steganography, that you could encode data inside the value transaction itself, since RaiBlocks uses 128 bits per transaction. In principle, you could use the bottom 64 or 32 bits to create and extract small messages. Beyond that, RaiBlocks could implement a layer 2 approach pretty simply: if one can already communicate with other IoT devices, one could just utilize that channel for the data layer. Therefore, this is not a major obstacle for RaiBlocks, in my mind.

Off-chain Transactions

IOTA has a unique feature in that it is possible to create transactions off-chain and attach them to the tangle at a later date. IoT devices may be able to interact with each other while offline and then propagate their transactions once they reconnect to the network. But this begs the question of whether the receiving party will “believe” the transaction and that it is not a double spend, before actually being confirmed by the whole network. As long as the devices can have reasonable trust in each other, this becomes a moot point. Nevertheless, this is a theoretical counter-argument for the benefit of these off-chain transactions.

With RaiBlocks, off-chain transactions are not possible. The sending party must be online and connected to the network to facilitate a transaction. Again, I don’t think this is a big issue, as there would still be that trust issue if it did have this feature. Beyond that, most smart devices and smart consumer electronics have internet access these days.

Long-term Adoption

One issue that we will run into is that when there are enough users and clients of a cryptocurrency, we have to start asking ourselves, are there enough to go around? On top of that, when we are dealing with IoT where machines will send tiny amounts of a currency to each other, we need to make sure that these tiny amounts don’t grow too expensive in the long run.

Both IOTA and RaiBlocks are effectively “pre-mined”, meaning that their ledgers started out with a certain amount of cryptocurrency that can never change. Over time, these tokens have been bought, sold, and moved around with ICOs and Faucets, increasing the general users’ attainment of these cryptos.

The max supply of IOTA is 2,779,530,283,277,761 IOTAs (or roughly 2.8 quadrillion IOTAs). (For comparison, Bitcoin will reach a max of roughly 2.1 quadrillion satoshis.)

The max supply of RaiBlocks is on the order of 2¹²⁸ ~ 340e36, or 340 undecillion. The reason for this high ceiling is that they utilize a 128 bit integer to represent balances. (Later, I will argue why this is a good thing.) Their actual max supply is about 133,248,290 MXRB, where 1 MXRB represents 10³⁰ (or 1 nonillion) raw RaiBlock units. The max supply can be denoted as roughly 133e36, or 133 undecillion raw RaiBlocks. Their wiki also denotes a few helper units based on the SI system to help with using some of these high numbers. Here is the max supply in raw units, just for fun: 133,248,290,000,000,000,000,000,000,000,000,000,000. That’s 39 digits! For comparison, this means there are about 48 sextillion raw RaiBlocks for each and every IOTA that could ever exist. That’s quite the ratio!

Let’s picture a scenario where we reach 75 billion IoT devices by 2025. Let’s forget, to keep things simple, that there will be billions of people owning cryptocurrencies by 2025. Therefore, let’s also assume that these IoT devices own all the crypto (Skynet!?). Now, let’s make a few calculations. The average amount of crypto that will be shared among these future 75 billion devices will be on the order of 37 thousand IOTA (or 37 kIOTA) or 1.78 octillion raw RaiBlocks (or 1.78 kXRB). From this, we can see that there will be much more flexibility in the transactional sense for RaiBlocks than for IOTA. This leads me to think that RaiBlocks could very well dominate the IoT space in the coming years, unless IOTA upgrades their protocol to either increase the max supply or allow for divisible IOTAs.

Scalability

There are a few different metrics we can look at in terms of scalability.

Speed of Transactions

In IOTA, as more transactions get sent through the network, confirmation times decrease, in theory. We’ve seen issues in recent weeks causing delays in peoples’ transactions being confirmed, sometimes taking days. But as I explained earlier, I think these are technical issues. Once the node performance and spam issues are mitigated, we should see a bounce back to better confirmation rates and times.

In RaiBlocks, you, as the user, performs the confirmation by signing your transaction. This process takes a trivially small amount of time. In general, your transaction is fully confirmed and processed in a matter of seconds. The bulk of the time is spent on performing proof of work, which is necessary to mitigate unchecked spam attacks.

Ledger Size

IOTA has a mechanism to trim ledger size in a process called snapshotting. Until now, we have had a number of snapshots which were manually executed by the IOTA team. (Max ledger size I’ve experienced is on the order of ~5–10 GB per month of transactions) After a snapshot, the size of the ledger becomes reduced to the non-zero addresses in existence and the balance of each of those addresses. From then on, the tangle works like normal again. There are a few issues with this scheme, at the moment. One issue is that one needs to manually “attach” their addresses to the tangle again to see their balance in their wallet properly. (This has probably given many people mini-heart attacks as they open their wallet to see a balance of ZERO) The new UCL wallet will automate this process. I believe we can expect them to release an alpha this month or next. Another issue is that the node operators must manually go into their servers, and wipe the old database storing the transactions. I believe this is just a technical issue that will be solved though. There are plans to fully automate these snapshots on their roadmap.

In RaiBlocks, the current full ledger size is on the order of 3 GB. Not bad for two years worth of transactions. Granted, RaiBlocks isn’t nearly as popular as IOTA yet, so we have yet to see how it will perform under extreme loads. Over time, size will definitely become an issue. There are plans of pruning the database, as all that is needed for consistency is the total balance in each of the block lattice’s blockchains. This pruning is on their roadmap.

Decentralization

IOTA has been getting flak about how its protocol is not yet fully decentralized. I tend to agree with the sentiment, but I am confident that they are also working as quickly as possible to attain full decentralization without their coordinator. (I elaborate on the coordinator in the Attack Potential section below) We are still waiting on an analysis or an estimate as to when this will be achieved. I would hazard a guess that the coordinator will be removed some time in 2018.

Another issue is that of peering. Until recently, node operators have had to manually reach out to other operators and add each others’ IP addresses and ports to their IRI configuration. But, I am happy to say, that there has been a recent development, called Nelson, which effectively solves this problem, and allows for full auto-peering on the network. Right now, this is a wrapper on the IOTA node, but I expect them to eventually implement a fully baked in solution in the node itself.

RaiBlocks has no central authorities managing transactions on the network and has had auto-peering since its release around September 2015. Therefore, we can deem it as being decentralized. The only area where I see a slight issue is in that of their representative system. This is a potential attack vector, whereby a malicious entity may buy up millions of dollars worth of XRB and carry out a voting attack. This scenario is outlined on their Attacks wiki. Granted, it is “low” risk as the malicious party would have to effectively forfeit large sums of money to carry out this attack, on the order of hundreds of millions of dollars or ~50% of the market cap, as of this writing.

Exchanges (How to Buy?)

IOTA is available on a number of major exchanges, including Bitfinex and Binance, with plans of being added to more exchanges in the near future. You can find their most active markets here.

RaiBlocks, by contrast, is not on any major exchanges yet. Its volume is on the order of ~$5-$10 million, compared to IOTA’s ~$500 million. Their main exchanges, BitGrail and Mercatox, have recently been hit with performance issues, due to increased traffic, and rumors of DOS attacks. It is, unfortunately, quite difficult to obtain RaiBlocks at the moment, given these unstable exchanges and lack of supply. You can keep track of their exchanges here.

Update, Feb 23, 2018: NANO, formerly RaiBlocks, is now available on a number of popular and more reliable exchanges such as Binance and Kucoin. I have to advise against using BitGrail as they have been involved in a recent hack and are now insolvent.

Roadmaps

Both IOTA and RaiBlocks are currently under heavy development. At the moment, the IOTA team has a larger size than the RaiBlocks team, at roughly 30 developers compared to RaiBlocks’ 5 developers. IOTA also has fostered a large number of corporate partners that will help develop their ecosystem, including Volkswagen and Bosch.

As for published roadmaps, here is a blog post from IOTA and here is a wiki page and an infographic for RaiBlocks.

Both tokens have good roadmaps, but IOTA’s is more interesting in that they are trying to implement private transactions, smart contracts, a data marketplace, and more, on top of IOTA!

RaiBlocks goes by the mantra, “Do one thing, and do it well.” Because of their focus on making the best FFM token, it would be difficult for them to extend this token to be private, have smart contracts, etc. (Maybe someone could make a decent fork with these features and become uber-rich???) Edit: Caution: there are some dubious projects that claim to be trying to implement this currently. Be wary of these projects; many of them are scams and never deliver.

User Friendliness

The main point of interaction for the average user is the wallet.

For IOTA, their current wallet is quite bare in terms of user friendliness. It gets the job done. It is more of a developers’ wallet for a product still in beta. I’ve seen numerous posts on reddit asking whether they should reattach or rebroadcast their transactions. These esoteric options should be totally abstracted from the user, in my opinion. Edit: The IOTA team has recently added another feature called “Transaction Promotion,” and again, I will say that this should be totally abstracted from the user.

Thankfully, they do have a much improved wallet coming out, thanks to the team at UCL. This wallet should clear up many of the headaches surrounding the current wallet experience. They are also working on releasing mobile wallets for general consumption, as their iOS wallet is currently undergoing beta testing before public release.

Another issue with the IOTA protocol is something called the “address reuse” issue. Essentially, every time you spend from an address, a private signing key for that address gets partially leaked. If you spend from the same address many times, an attacker could reconstruct the original signing key to steal funds from that address. This process is effectively baked into the IOTA protocol and is what implements their “quantum resistance.” This quantum resistant algorithm is called the Winternitz One-Time Signature Scheme. (Read more about one time signature schemes here.) Still, it is difficult to train new users about this, who are used to sending and receiving Bitcoin, Ethereum, and basically every other coin.

When you do spend from the IOTA wallet, any leftover funds from your transaction are automatically sent to another address you own. (Each seed can “own” a large number of individual addresses) And new versions of the wallet will warn that you are trying to send funds to an address that had already sent funds, which is a step in the right direction. You still have to be careful sending across snapshots, as I don’t believe the wallets and nodes can detect this. (Please correct me if I am wrong.)

RaiBlocks’ current wallet is also a developers’ wallet. Everything is black, white, and gray, with small font and a bare-bones navigation interface. It gets the job done. There is no lite wallet support yet, so users must sync the entire ledger before being able to properly interact with the network. And sync times are quite bad at the moment, anecdotally speaking; I am spending tens of hours trying to get my full wallet to sync. Thankfully, there is an alternative to fully syncing your node the slow way: you can download the full ledger here.

Again, new and improved desktop and mobile wallets are currently under development, according to their roadmap!

Update, Feb 23, 2018: The new version 10.0.1 of the NANO wallet is able to fully download the ledger on the order of minutes (with a fast internet connection) and fully sync with the network in a few hours! Well done NANO team!

RaiBlocks also follows the general convention of sending and receiving from the same address being OK; no address reuse issue here.

Basically, the wallet experience for both of these cryptos is quite lacking at the moment. But, we can expect great new wallets from both of them in the very near future!

Growth Potential

IOTA still has a lot of room to grow and I elaborate on this in my article, IOTA Price Analysis and Predictions. The TLDR is that IOTA has many items on their roadmap and many more exchanges to be added on, which, in my opinion, will boost the price to levels on the order of $141/Mi, compared to their current price of roughly $3.80. That’s a predicted 37x gain. Please take this with a grain of salt.

RaiBlocks has risen from obscurity in recent weeks, from a market cap of ~$20 million (~rank 200) on November 24, to ~$530 million (~rank 40) on December 14th. That’s 26.5x in only 3 weeks!!! And there’s no telling when this growth will stop. My hypothesis is that RaiBlocks has been riding the wave of money flowing into IOTA and other related next generation cryptocurrencies over the past few weeks. And as more people look into the technology and test out the wallets to see that it actually works, more people will get sucked into this cool new tech. I predict RaiBlocks will be a top 10 crypto one year from now, from the simple fact that their tech is fast, simple, and it works! They still have a long roadmap ahead of them, but I am confident they will deliver. If RaiBlocks does become a top 10 crypto, they would have a market cap of ~$5 billion, which means a ~9.4x gain in one year. One year from now, the necessary market cap to attain a top 10 ranking will probably be much higher, so this growth is probably going to be even higher.

Attack Potential

We must ask ourselves a few questions if we want to believe in the long term viability of these cryptocurrencies. How can these cryptos be attacked? How likely are those attacks? What are the severity of these attacks?

IOTA has a few potential attack vectors. One of them being executed recently is called a spam attack. This is where an attacker spams the network with dummy transactions, messing up the confirmation tip selection algorithm, causing delays in confirmations, sometimes orphaning valuable transactions for days or weeks. The foundation is very aware of these issues and we are currently waiting on a more robust release. Edit Dec 20, 2017: New versions of the IRI (v1.4.1.4) and wallet (v2.5.5) have been released and they claim many of these issues are resolved. Anecdotally, I am seeing many people say, on Reddit and the IOTA Slack, that their confirmations occur much faster now.

People argue that IOTA is not yet decentralized due to the deployment of something called the coordinator. This is basically “training wheels” for the IOTA network which is used to mitigate 51% attacks and such. Most blockchains, including Bitcoin, have had mechanisms like this in their early days. But we are still waiting on a official metric or a timeline for when this will be removed. The link earlier stated that it would become “optional” by the summer (the article looks dated so I think it meant the summer of 2017?). In theory, I believe the coordinator is optional, but in practice, I highly doubt people are running their nodes in a coordinator-less fashion; please let me know if I am mistaken here. I’m still confident that once IRI autopeering and neighboring is fully implemented, the network will be robust enough to stand on its own; and these features are on the roadmap. (Here is a nice little repository of IOTA’s anti-FUD rebuttals, including info about the coordinator.) Just for comparison, RaiBlocks doesn’t have the concept of a coordinator, and auto-peering has been a standard feature of full nodes and the wallet since it was released.

There are other potential attack vectors with the IOTA protocol and you can read more in their whitepaper. In general, the attack risk for IOTA is low at the moment.

RaiBlocks is the new kid on the blockchain (pun intended). Therefore, it hasn’t had the same levels of hardening and improvement like other cryptos. With this recent surge in pricing, we can be sure that attackers will start trying to knock down or even break the service. Time will tell if the current implementation is strong enough to withstand these. I recommend code reviews and audits by security teams, analysts, and the general developer community, especially since the main node software is written in C++ *shivers*. I’ve only had a brief glimpse of their code and see many functions and files that are too many lines long (example) and nesting-hell (example). Here is a perfect case for a guard statement refactoring ;-) I’m not trying to bash on RaiBlocks, Colin LeMahieu (the creator of RaiBlocks), or their developers, but there are a lot of code smells going on and lots of room for improvement :-]

I encourage community developers and members to help contribute their time and talents to this project, as for IOTA and other cryptos. (Just to keep it balanced, here is a nasty example of deep-nesting in the IRI; something like 8 levels deep) I guarantee there are bugs here, waiting to be either fixed or exploited. Hopefully the former.

Furthermore, RaiBlocks gives a nice, concise description of many different attack vectors and their severity on their wiki page. Take a look. The TLDR is that most of these attack vectors are low to moderate risk and basic defense mechanisms have either been theorized or already implemented. This is not a comprehensive list of course; I predict there are some unknown attack vectors and exploits which we will see in time.

Resources

IOTA Homepage; IOTA Whitepaper; IOTA Transparency Compendium

RaiBlocks Homepage; RaiBlocks Whitepaper; RaiBlocks Wiki

Conclusion

IOTA and RaiBlocks definitely overlap in terms of functionality and use cases. Each has their own theory as to why they will be the prevailing FFM coin of the future. We don’t really know whether one will “win” or whether both will thrive in their own ways. They both have many, very exciting features, products, and improvements yet to be released. And neither perfectly solves all use cases. There will probably never be a “perfect” coin to rule them all.

That being said, I think both coins will be very strong players in the cryptocurrency space for years to come. And there will be new players trying to make their way into this crowded, competitive space. We should not only be competing, but also working together to foster a stronger future for both of these cryptos and for new FFM cryptos to come. Both competition and collaboration will promote innovation!

We have a very interesting future ahead for these cryptos with plenty of new developments happening. I’m thoroughly excited to see what happens!

Edit Dec 20, 2017: I originally stated there were 10–12 developers working on RaiBlocks. This was inaccurate. There are actually 5 developers.

Edit Dec 24, 2017: I made a mistake in the number of RaiBlocks in circulation. I had assumed that exchanges sell in units of 10²⁴ raw RaiBlocks, when in fact, they sell in units of 10³⁰ raw RaiBlocks, aka Mxrb. All subsequent calculations have been updated.

You can follow me and my company, P Rizz Ventures LLC, on Twitter, Medium, Facebook, and LinkedIn.

IOTA vs NANO (RaiBlocks) was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am a 27 year old software engineer living in the great city of Chicago. I currently work at a company called higi, a health and wellness company offering free checkups for health metrics at thousands of health stations across the US. I am leaving higi soon to pursue my business venture, P Rizz Ventures LLC. (P Rizz is a truncated anagram of my name; please let me know if there is a more precise term for a “truncated anagram”) I am currently working on creating fun and useful cryptocurrency software and services, with a strong focus on building for IOTA. It is very difficult leaving higi, leaving my fantastic colleagues and innovative projects we were working on. But I think this is the right move, not only because I think I can make great things for crypto, but because that is where my passion lies right now.

I went to university at Illinois Tech where I got a Bachelors degree in Electrical Engineering, class of 2012. I wanted to continue learning and started my Masters with a focus on Digital Communications and Signal Processing. I had ambitions of going even further and getting a PhD and doing research, working with technology that I loved. Oh, my optimism… Unfortunately, I dropped out of the Masters program a few months into it as I realized I was not enjoying myself and not melding with the experience, unlike my undergraduate program. (There’s issues with your grad program, IIT, but that’s another story.)

After that, I landed a job at Nokia where I worked on the Xpress Browser, a mobile web browser that compressed data before reaching your mobile phone. (Google now has a version of this called Data Saver in their mobile versions of Chrome.) I learned a lot about the now defunct J2ME (Java) platform and dealing with the limitations of implementing for Series 40 feature phones, fun!

I also started dabbling in backend, mostly with NodeJS while it was still in version zero. I was super intrigued by this new callback based / event driven paradigm and immediately saw the huge potential. This became the backbone for the, now defunct, Nokia Xpress Now service. This was an aggregation of new, curated, and popular content across the internet. It gained some popularity, mostly in India, for the time that it existed and was one of the most popular “apps” on the Series 40 devices.

Some time in 2014, Microsoft officially bought out Nokia’s Mobile Phone division, which I was a part of. People immediately went into panic mode — there were always layoffs after large consolidations like this. So we continued to work under Microsoft for roughly six months before learning of the plan that most of us were getting axed. The cool thing about this was that our workplace became a daily hackathon; we were making and demoing new and interesting products and prototypes, trying to entice Microsoft to keep us. Alas, it wasn’t meant to be, as Microsoft decided that it wasn’t worth keeping us; an understandable move from a large corporation with many stakeholders. It sucked, but it wasn’t the end of the world. I now had some decent experience under my belt with some decent companies to put on my resume.

Shortly before being let go from Microsoft, there were rumors that BMW was considering starting an office in Chicago, sweeping up all of the new potential engineers on the market. After we were laid off, word started spreading that in fact the rumors were true, and we were all contacted, shortly thereafter, about whether we were interested in joining BMW’s new office. I jumped on it! Here is a world-class car company, pushing new and innovative solutions for driving mobility, and we were the first to get our hands on this new technology! And we were going to work again with our old friends and coworkers from Nokiasoft! Great!

At BMW, the first few months were filled with, again, daily hackathons. We were trying to figure out a business plan of action with all of us newly hired engineers. We made some really cool concepts, and I believe some of them are now in BMW’s apps today.

We then decided to officially start developing new versions of iOS and Android apps for interacting with your Beamer. Problem was, barely anyone in the office knew iOS or Android! We were from the world of Series 40 and Lumias, not these newfangled smartphones! Fortunately, myself and a few other engineers had dabbled in iOS and Android, so we helped bootstrap the office with a series of teaching sessions and pair programming. Granted, I was not an expert at the time. But I did have one app on the App Store, Grade Grid, a simple app for teachers to calculate grades for their students’ assignments and exams. It was a very good learning experience, teaching me the fundamentals of Apple’s take on MVC and related design patterns. If you are a young developer, maybe still in school, I highly recommend trying to make some iOS or Android apps. I believe tinkering is very important and formative for everyone, especially engineers. That process of trying and failing for hours, just trying to get your code to compile properly… and then voila! It’s an exhilarating experience. You may even get to the point, some day, where your code not only compiles, but also works as intended, on the first try! You are a god among software engineers if you can get to this point!

After what felt like forever, we finally shipped our first version of BMW Connected! It felt amazing being part of a new era of smart devices and the smart car ecosystem. There was a whole new world of interesting applications and use cases before us. Aaand then our app was rated a 1.5 stars… Not good. But we continued iterating and improving the user experience, and we slowly went up to a 2, maybe 2.5 stars. (It now hovers around 3 stars; not great, but good)

About a year and a half after joining BMW, I started thinking about other opportunities. There were, and still are, plenty of great tech jobs in Chicago, and I felt like we, at BMW, were not pushing the pedal hard enough, so to speak. After a search, I came upon a company called higi, the company I described in my starting paragraphs. I joined higi as an iOS developer, learned a great amount while working there, and met a lot of fantastic people. I still think it is a super cool company to have worked for. (I hear they have an open iOS position…)

While at higi, I was introduced to the world of cryptocurrencies by some coworkers. (I knew about Bitcoin, in passing, for the last few years, but, sadly, didn’t dig into it, or other cryptos, at the time) I immediately understood their huge potential for interesting applications and systems for transforming this world for the better. (I am highly influenced by Andreas M. Antonopoulos and his awesome talks on YouTube) I was hooked and was learning as much as I could about these new and strange sounding cryptos: Ethereum, Monero, IOTA… IOTA seemed to be the most interesting, offering fast and free transactions to anyone in the world. There was no miner/user contention. The users were the miners, effectively: every transaction requires a bit of computation to execute, called a Proof of Work, or PoW for short.

I admit, I am not an IOTA maximalist, but I still think it is a huge contender to be a top-3 crypto. Maybe even number 1 some day. But IOTA is still in its infancy — it’s still in beta and there have been a lot of headaches caused by snapshots and token management. But, they are getting better every day. I have spoken with some of the founders/cofounders (David Sønstebø and Dominik Schiener) and am convinced that they are on the right path forward for fostering a strong ecosystem of applications as well as the core product itself. They have a strong development and research team working on all these problems, and they are growing this team by the day. Now that they are officially incorporated in Germany, I think we will see an acceleration of innovation by the foundation!

And here we are, in the present. I recently released an app called Chatangle, a free, decentralized, global chatroom, powered by the IOTA tangle (analogous to the “blockchain” data structure). I am continuing to improve it every day, and am confident it can become a strong tool to preserve freedom of speech around the world once I release authentication and private channels.

Admittedly, it is a bit slow and buggy at the moment, but I have ideas in mind for how to address these issues. And I will have much more time to work on these things once I officially leave higi.

I believe we are going to see an explosion of growth in dapps (decentralized apps) built on top of IOTA in the near future. We will see new businesses and business models emerge. This is what I am currently focusing on in my company.

Some people say we are in a crypto bubble, which I actually agree with to some extent, but only in the short term. In the longer term, I am confident we are going to see some amazing things pop up for IOTA and other cryptos. (I tend to think that crypto is following a J-Curve at the moment.) Crypto is like how the internet was in the 90s, with lots of new companies and ideas just being born and starting to flourish. We are going to see profound changes, not only to government regulation and banking, but to society as a whole, as we move from a centralized world of commerce and communication, to a decentralized one. We are in for some exciting times ahead and I am ecstatic to be a part of it!

You can follow me and my company, P Rizz Ventures LLC, on Twitter, Medium, Facebook, and LinkedIn.