People were aware that media was centralized around too few companies and diversity of opinion was needed, but it was thought that this problem would be short lived because the media would eventually be replaced by the internet.

Today, this thinking is sadly quite rare. Most online culture does not consider freedom of expression to be an important value at all, and instead focuses on hand-wavy feel-good terms like “trust”, “safety” and “moderation”. Of course the majority of said moderation essentially boils down to high-school grade inter-personal drama.

As someone who deals in ideas, there aren’t many thoughts that I consider off limits. So a lot of what I read and write online is what some people would call “extremist”. Puzzlingly, I’ve never encountered the issues with censorship or de-platforming which seem to dog other people. I’ve developed a hypothesis that there’s another social element which drives certain people and platforms to become targets for cancelling and censorship. That’s not to say that censorship isn’t a problem, it’s just more of a oddity that it doesn’t really target what one would expect.

Two websites which have been the target of considerable de-platforming efforts are KiwiFarms and Gab. I am not intimately familiar with either of these websites, so my description of them might well be off-base, but I’ll do my best. KiwiFarms is, per my understanding, something of a celebrity gossip forum. A group that finds people who seek attention, and gives them … attention. Gab is a largely political discussion board which brands itself as being free speech oriented.

At current, KiwiFarms is hosted by the streaming platform Rumble, and Gab has their own hosting provider AS42651, which gets its internet from the venerable AS6939 “Hurricane Electric”. Gab has a great advantage in that they have an account with CloudFlare, allowing them to keep their actual web server IP secret - though they’re not really using it to its potential because (by running their own hosting provider) they reveal their IP addresses anyway. The reason why Gab registered their own “hosting provider” is almost certainly to be able to handle abuse complaints themselves, rather than having them go to another hosting company that might be inclined to drop them as a customer.

Recently it has come to light that Gab may have made a bit of a goof, the system number of their “hosting company” was registered in Europe - and they seem to be facing the consequences of being spread across jurisdictions.

So far this has not lead to any actual network disruptions, and this matter will probably be resolved without issue - but it’s illustrative of the fact that steps intended to improve resilience can sometimes have the opposite effect.

How to never get taken down

I concede that nothing of mine has ever so much as raised an eyebrow amongst the anti-speech crowd, so this proposal may stumble in the face of realities of people trying to shut you up. But since I have not seen anyone talking about this, I decided it’s worth writing about it anyway.

The Stack

In order to host a website, you need to figure out four components:

1. Domain

2. Servers

3. CDN

4. VPN

First you need somewhere to register your domain - wherever this is, that’s going to be your jurisdiction, so if someone is going to sue you, they’re gonna do it there. Stick to one country for your domain and your registrar. If you’re doing US, get a domain with a US-based TLD like .com, .us, .wiki, etc. If you’re doing another country, best to use that country’s TLD like .fr, .es, or .it. Make sure your registrar (Namecheap, Porkbun, etc.) is based in the SAME jurisdiction as your TLD. Don’t make the mistake of spreading infrastructure across jurisdictions!

Once you have your domain, then you need servers. Where do you host them? The answer is anywhere you want, because when you do things right, nobody is going to know where they are anyway. There is no reason for the general public to know the IP address of any of your real servers - the whole pitch by Cloudflare is that they protect you from DDoS because the attacker doesn’t know the IP of your real server, only their IPs (which are DDoS hardened).

Once you have your servers, and nobody knows where they’re hosted, then you need some kind of a CDN / proxy, a service like Cloudflare or Akamai which will stand between you and the world. It’s best to have more than one of these on-hand, so that if one of them decides to drop you as a customer, you only need update your DNS to get back running again. These services are all a faustian bargain, they’re run by intelligence agencies who want to spy on your users - but they will protect you so if you’re large scale, you don’t really have any other option. If you’re small scale, you can rent a VPS and setup your own “Cloudflare” - this just won’t scale if your service becomes big. Also VPS providers have thin margins and they don’t like customers who attract DDoS, so you should generally assume that these services will cancel you at the first sign of trouble.

Finally, you need a VPN. This is because no server is ever 100% inbound-only. You need to send password reset emails, and other little things that will leak your server’s real IP address if you don’t have a VPN. Ideally you would install a VM on your server, and all of your actual webapp would run in the VM. Then the server would force all traffic to and from the VM to go through the VPN so the webapp literally cannot know the IP of the server it runs on. Like the CDN / proxy, you should have multiple VPNs lined up, so if one of them decides to drop you as a customer, failover is relatively automatic.

Age Verification

As I’m writing this, governments throughout the western world are implementing more-or-less copy-pasted versions of the same law, which will require websites to demand ID in order to (ostensibly) protect children. Despite the claim, it’s generally believed that this is meant to suppress political and anonymous speech.

Even in this culture of relative apathy toward the principle of free expression - the policy is still being met with widespread objections across all of the jurisdictions where it’s being rolled out.

An under-appreciated point is that by passing of the same unpopular law in every country at the same time, they are effectively confessing that western democracy is a sham. There is statistically no way that such an event could occur if decisions were made the way we’re taught in civics class. But the implications of living under occupation of a secret international dictatorship is another post for another day.

The age verification rule is, in my opinion, most likely to backfire - as the most easily regulated platforms will be those large centralized platforms who gladly carry water for the regime already. The small, niche, and decentralized platforms will either lack the resources to implement verification, lack the technical capability, or insist on civil disobedience against the rule. People who don’t like doing ID verification for social media will gravitate away from the large central platforms, making narrative-control even more difficult than it already was.

Radio and Television created in the 20th century an unprecedented era of centralized social control. But despite that control, the regime had no answer to underground groups such as the Irish Republican Army. The internet, while pitched to the masses as an open communication platform, was pretty obviously conceived as a means of mass surveillance. And with the ubiquity of data-slurping smartphones, it has become extraordinarily difficult to run a terror cell. But the price they paid for this was total loss of control over public opinion.

• A dramatically aggressive firewall as you find in corporate environments where everyone is supposed to be doing specific activities so use cases are limited.

• A national firewall that only blocks direct connections to specific websites.

Neither of these scenarios are that scary, the corporate one because it would never scale, and the national one because it is trivially bypassed. The real nightmare scenario would be some sort of Digital Lockdown where firewalls are able to successfully block all VPN traffic - and once it happens, you don’t have time to prepare.

Last Friday evening there was a thunderstorm at my house and my fiber internet stopped working. Normally this would be a welcome respite from what is often time-wasting leisure - but in my particular case, I run a number of various server-like things at my house and these depend on an internet connection.

At first, I assumed my connection would be back relatively quickly so I didn’t do anything at all. But by Sunday morning it became clear to me that the line wouldn’t be coming back at least until Monday - most probably because whatever was fried in the lightning storm could not be replaced by the people who work weekends.

By Sunday noon time I had re-worked my home network to tether the entire network off of 4G. I set some bandwidth limits and setup a CAKE traffic shaper to avoid overloading the line and went about my business (gardening). This worked great for some hours before suddenly everything stopped.

As one might imagine, I make very heavy use of cjdns in my home network. The “servers” I run at home are all using cjdns as a reverse VPN to an actual hosted web server. The hosted server provides good reliability and a stable IP address that is approved for hosting, while the machines at home have the CPU power and storage to do far more than the hosted server could do.

So when I came in from playing gardener, I was surprised and frustrated to see all of my services had stopped, though the 4G tether was still active. After a bit of investigation, I found that traffic from my local cjdns nodes was not arriving at my servers. I tried changing the UDP port on the server to the famous port 53 (DNS), this port is rarely blocked because blocking DNS can cause serious issues. Still the traffic was not reaching its destination. So I tried sending some test traffic, and miraculously that passed.

It was at this point that I realized there are only two possible explanations, either the firewall at this 4G backend can fingerprint cjdns traffic (unlikely) or else it’s blocking when there is excessive traffic with the same source port. So I changed the bind port in my cjdroute.conf and presto, connection re-established.

This firewall allows all traffic, but it began blocking cjdns UDP traffic after a few hours because there was too much of it for too long. This got me thinking about how a VPN blocker might work. It’s not realistic to detect every protocol on the internet, but if most or all traffic is going to one server, one might reasonably assume that is a VPN or VPN-like protocol which could trigger a block.

This is a difficult threat to design around because everything you do needs to be limited and low bandwidth - otherwise you may trigger a block. It’s unclear if anyone can realistically block port 22 (SSH) since things like rsync or git over ssh are quite common among developers and sysadmins. Still, the threat of some “limited internet” which blocks any and all long lived / high bandwidth connections is a real one.

The most obvious mitigation to this, which is already being tested in a branch is to randomize the source port. That is to say, allocate a new socket for every outgoing UDP connection. Since cjdns uses DNS seeding, it will keep searching for new peers when it’s not getting a connection, so it will keep allocating new sockets and new source ports.

Also, in this implementation, when it has not received any traffic in a configurable timespan (set to 1 minute), it throws away the socket, so next outgoing message will be sent with a freshly allocated one. This alone would have worked around the issue I was seeing.

A more robust solution would be to build a websocket or TCP based communication module. Running cjdns over https websocket, or through an SSH port forward tunnel, would create something that is very difficult to block safely. It could still be done, but the side-effects of doing this on abroad scale would be fairly dramatic.

If that doesn’t work, it’s unlikely that any kind of VPN will work, and at that point the goal is simply to have any reliable communication at all. Nostr, DeltaChat and the Fediverse all have interesting performance characteristics in this regard - with Nostr and Fediverse both working over https request / response, and DeltaChat doing the same but with IMAP and SMTP.

At the end of the day, a sufficiently aggressive firewall can make internet usage exceedingly difficult. In particular, blocking of VPNs is realistic, and circumvention will be based on technologies which do request/response rather than VPN-like packet streaming.

Perhaps one of the best bulwarks against a “surprise internet lockdown” is Starlink. Local telcos are heavily dependent on local governments to protect their infrastructure and provide them with subsidies - so they will offer essentially no pushback to any proposal a government might cook up. Starlink however will most likely insist on formal legal demands, and even then take initiative to fight them.

These actions have the effect of slowing down whatever process is being proposed, and without the ability to roll it out by emergency decree (as they did with lockdowns in 2020), they may choose never to play that card at all.

In conclusion, cjdns is going to be getting somewhat more robust against adversarial firewalls - though there is still more to do. And also, 4G is not to be considered a real backup in case of a fiber outage. Maybe Starlink is worth investigating…

As of Wednesday January 8 2024, registration of PKT domains is now open to the public. What’s a PKT Domain? Glad you asked. A PKT Domain is a domain registered in one of the PKT Project smart contracts, it is accessible as a subdomain of every staked infrastructure domain. Staked infrastructure domains are domains that were registered with classical domain registrars, they begin with pkt and end with any top level domain, for example pkt.com, pkt.us, or pkt.wiki. When you register a PKT Domain like cjd.pkt, your domain is reachable via every staked infra domain, so cjd.pkt.com, cjd.pkt.us, and cjd.pkt.wiki.

You can see the list of actual staked infrastructure domains right now, by going to https://insight.pkt.wiki/domains/ and clicking the “Active Domains” tab. Since insight.pkt is itself a PKT domain, you can also reach the same website by going to https://insight.pkt.st/domains/ or https://insight.pkt.ovh/domains/, or insight.pkt.<any staked top level domain>/domains/.

The value of this is two-fold, firstly domains are far overpriced for what they are - an entry in a database table. Secondly, most registrars and domain registry authorities have no interest in defending the rights of their customers if they receive an official-looking (scary) email. This leads to the infamous “website has been seized” banner that has marked the end of more than one freedom-loving project.

This is not to say that there’s no such thing as cybercrime, but investigations are supposed to be slow, methodical, and protective of the rights of everyone involved. All too often, government officials get it in their heads that they’re some kind of “mods” of the internet whose job it is to “swing the ban-hammer” at any website which goes against their sensibilities.

Decentralized technologies have provided a powerful counterbalance to these god-Karens, even as the evolution of surveillance has centralized more and more power within their fickle institutions. But even decentralized projects need websites, and the domain name system has always been a central chokepoint.

There have been numerous projects to “fix” DNS, the first of which was Namecoin, followed by projects such as ENS, Handshake, Unstoppable Domains, Blockstack, and Zilliqa Name Service. Each one of these projects suffered from the same limitation, because they’re not interconnected with the centralized ICANN based domain system, you can’t use them without installing special software. Going to https://peername.bit/ doesn’t work unless you’ve specifically installed namecoin, but going to https://cjd.pkt.movie/ does work, because it’s using the pkt.movie staked domain.

Attempting to take down PKT domains by the classical “scary email” method is practically a dead end. The domains that can be taken down are the staked infrastructure domains, and there are 56 of these, spread across 21 registrars. Moreover, taking them down takes down all PKT domains, not just the one they’re after. That’s not to say they care about who they hurt, but it’s something of a mask off moment if they’re willing to pull the plug on a whole swath of unrelated internet infrastructure just to Get The Guy that they’re looking for. But most likely, out of those 56 domains, some operator somewhere in some country is going to reply to their scary email and say “But what for?”, and even if just one staked domain remains available, they haven’t truly taken down anything.

Registration

Registering a PKT domain is nominally free1, but you must have some PKT staked. The minimum amount you must have staked varies between 1,000 PKT and 50,000 PKT (roughly $1 to $50 worth). The minimum stake rises as more domains are registered, to prevent someone mass registering and squatting all of the good names. If no names have been registered in a while, the minimum stake falls back toward 1,000 PKT.

Once you’ve registered a name, it’s yours for as long as you keep the underlying PKT staked. As with any other domain, you can add DNS records to point to your hosting provider.

Setting up a site

Once you’ve registered, the easiest thing to do is pick your favorite staked infrastructure domain, for example pkt.wiki, and make that your primary domain. This will be the domain which you get SSL certificates for, and if you’re using managed hosting, you’ll enter <yourdomain>.pkt.wiki in the dashboard of your hosting provider. All of the other domains get a simple http redirect to your primary domain, so that they don’t require a certificate.

If you’re more adventurous, you can get certificates for each one of your domains and add them all to your webserver as I did with cjd.pkt. As time goes on, there will be tools to make this process easier, but for now, welcome to the future.

Going forward

I’m planning to add “default” domains to the staked infrastructure domains so that they can be used by their owners even while staked. I own pkt.wiki and I have it staked, but I wouldn’t mind running a wiki for the PKT project. Since it’s staked, <domain>.pkt.wiki goes to the relevant PKT domain, but just plain pkt.wiki doesn’t go anywhere. I plan to make it possible to configure how pkt.wiki will resolve. This will make PKT domain staking just a bit less of a hassle, since you’ll still be able to use the domain.

My next plan is to roll out the VPN exit system for cjdns. Part of this will be enabling reverse-VPN so that you can host a website inside of the cjdns network and it can be accessed from any of the active VPN exits. Requests for any of your domains (https or http) will be forwarded to your designated server, which can be anywhere with a good internet connection, even a device at your house.

When VPN client apps are complete, you will be able to browse PKT websites from your desktop without using the top level domains, you’ll just type cjd.pkt. You’ll also be able to access the public web through any of the VPN exits and your connection to the network will be made through one of the staking cjdns nodes.

Go register a PKT domain. https://app.pkt.cash/

I’m running for Network Steward in order to complete this mission, and the people who vote for me are going to have early access register your favorite PKT domains. Early access will work as follows:

• On the first 7 days, each of the top 7 biggest whales to have voted for me will be added to the early access list. Day 1 will be the person with the most votes, day 2 I will add the person with the second most, and so on.

• At the beginning of week 2, I will open up access to the top 25% of all people who voted for me.

• Beginning week 3 it will be the top 50%.

• Week 4 I will open access to everyone who voted for me.

• Week 5 I will open access to the general public.

What does top 25% mean? If 100 addresses vote for me, it will be the 25 richest whales out of them all. If 1000 addresses vote for me, it will be the richest 250. If you want early access, claim your airdrops and vote!

In order to vote, you need to add a Network Steward vote to your staked coins. You can either do this while staking, or you can do it by clicking “Update Data”.

You don’t need to vote with all of your stakes, the system will automatically include the ones which have no vote. However, only staked assets count toward your total votes, so make sure you claim your airdrops and stake!

I will soon begin publishing a daily report of the biggest voters, and on Wednesday September 11th, the early access list will be locked in. All you have to do to maintain your position is to not remove your vote, or decrease your total staked assets until the project is complete.

How domains will work

In order to register a domain, you will need to have staked assets. The minimum amount of staked assets needed will depend on how many other people are registering domains. We are aiming for an average rate of 1 domain per hour, so when you register a domain, the minimum staked assets for the next person is set to double the amount in your stake, and then every hour that amount will decrease by 50%.

Each stake can only connect to one domain, and your ownership of the domain will be connected to the stake. If you transfer your stake to someone else (it’s an NFT so it can be transferred), they get ownership of the domain as well. If you unstake, your domain can be taken over by anyone. Allowing your stake to mature will not put your domain in jeopardy, you will only lose it if you actually click unstake.

Subdomains and records

Once you register a PKT Domain, you will be able to create any subdomains and add any records that you want. The PKT name servers will serve those records the same as if you put them in a Domain provider like Namecheap.

When you are done editing the records for your domain and subdomains, you just have to click “Save Changes” to create a transaction which will update the smart contract.

Staking domains and name servers

After October 30th, “Infrastructure Day”, you will need to run PKT Infrastructure in order to continue yielding on your staked PKT. Two of the pieces of identified infrastructure are Domains, and Name servers.

The names that you have been buying up, such as pkt.com, pkt.org and pkt.us, are part of a plan to create a highly robust global DNS system, and this is how it will work. When you register a domain on the smart contract, like cjd.pkt, the records for that domain will be broadcast out to every name server on every staked domain.

So cjd.pkt will be accessible to the general public via cjd.pkt.cash, cjd.pkt.com, cjd.pkt.us, etc. Because these are all public domain names, anyone will be able to access any one of these names without installing any special software to do so.

As part of the project, there will be a name server which reads the smart contract and serves every .pkt domain (like cjd.pkt) as a subdomain under the staked domain (like pkt.cash).

Cybercrime and bad actors

Everybody wants to be part of making the internet more free and open, but nobody wants their infrastructure used by cybercriminals who bring bad reputation and police attention without so much as a thank you (let alone a share of the loot!)

In order to receive staking yield, every name server will be required to correctly resolve every domain, but this presents a risk because if a bad actor registers a .pkt domain, they could bring problems to everyone who is staking a public domain.

To resolve this, pkt domains can be blacklisted. Name server operators will be able to be choose whether their servers should resolve blacklisted domains or not. Whichever they choose, their name server will still be regarded as fully functional and they will still receive their full yields.

The blacklist will be administered by me until such time as we have a more robust governance system, my goal is to protect the reputation of this young project while keeping most of the domain stakers out of harm’s way. I can’t guarantee to blacklist every domain that is considered a problem to anyone. Domains registered in unstable jurisdictions may find that they are forced to migrate or stop staking. My goal is to make sure that public domains that are domiciled in normal free countries don’t end up with serious problems.

Conclusion

Blockchain based name registration is almost as old as Bitcoin itself. But to this day, every last blockchain DNS project requires the end user to install software in order to resolve the domains. This is because the public DNS system imposes liability, and connecting a blockchain domain system to the public DNS allows anonymous criminals to create liability for innocent infrastructure operators. The blacklist will make PKT DNS unattractive for the “worst of the worst”, and the large amount of public staking domains will create a strength in numbers for the domain stakers. I expect PKT DNS is going to be something truly unique and exciting, and I hope you will come along for the ride!

I wasn’t sure if I would write this article at all because I didn’t know what value it would bring. But there are a handful of people who I brought into the PKT project, and for you guys, I wanted to finally take the time to explain what actually happened over the past 3 years, what we did about it, and what you can do right now.

For you, this is probably the chart of “well that didn’t work out”, but for me it’s a brief recap of what has been three of the most challenging years of my life.

What you can do

The good news is that after these three years of pain, we finally took drastic action to fix the glitch. We have re-launched the project as an Ethereum token on top of Coinbase’s BASE chain. You can use the keys from your old PKT wallet to claim your new PKT. To do this, you need to install a Web3 wallet such as Metamask or Coinbase Wallet, and you will need to buy some Ethereum on BASE in order to pay the transaction fees. Luckily you can buy ETH directly inside of the wallet, just make sure it is on the BASE chain when you do so.

It might seem scary at first, but BASE chain fees are less than 1 penny so even $10 of ETH will last you a lifetime of transacting, and once you have your PKT, you can stake it to earn more. If you’re not ready to do this right now that’s ok, your airdrop will be waiting for you. But once you claim you will be able to stake your PKT to yield more PKT, and those yields will be the highest before everyone else piles in.

About the Airdrop

The original plan was to airdrop everybody ⅓ of their PKT at launch, ⅓ after 6 months, and then ⅓ after 12 months. But due to a technical glitch and an unfortunate series of mistakes, the coins for the 3rd airdrop got sent into a black hole never to be seen again. So everybody is getting ⅓ less of the new PKT than they had of the old PKT, that’s you and me and everyone. The good news is that because those coins are gone forever, the value of the remaining coins will be that much higher, and also because you can now stake your PKT and yield, you have a chance to get back a lot, if not all, of your lost 3rd.

Staking your PKT

To earn more PKT, all you need to do is claim your airdrop and stake it. There are two ways you can stake:

1. “Basic Staking” - Lock up your PKT for a period of time.

2. “LP Staking” - You add PKT and Ethereum to Liquidity Pool and stake the resulting LP Tokens.

The advantage of Basic Staking is you don’t need to add any Ethereum, just PKT.

The advantage of LP Staking is you will yield astronomically more than with Basic.

Basic Staking

When you stake your PKT, you receive what are known as “Yield Credits”, these represent your share of the total yields. As more people stake, more Yield Credits are issued so your percentage goes down.

The minimum amount of time for Basic Staking is 1 month, and when you stake your PKT for 1 month, you get 1 Yield Credit per PKT. If you stake for 3 months you get 1.5 credits, 6 months gets you 2 credits, and 12 months gets you 4 credits.

Because there are no longer any PacketCrypt mining pools in PKT, all of the newly minted coins go to the stakers. This is currently about 900,000 PKT per day.

After October 30th, you will need to also run internet infrastructure in order to continue yielding. Routie products have cjdns running on them, so customers of Routie will automatically qualify, but those who don’t own a Routie device will need to set up a cjdns node or one of the other recognized infrastructure items.

LP Staking

The far more lucrative way to stake is by adding PKT and Ethereum to what’s known as a Liquidity Pool, and then staking the resulting Liquidity Pool tokens.

The Liquidity Pool (also known as a decentralized exchange, or DEX) is a smart contract which allows people to buy and sell PKT without a 3rd party. In order to make that possible, there needs to be PKT to buy, and Ethereum for people who want to sell. So this is where you come in.

When you provide equal parts PKT and ETH to the Liquidity Pool, you receive units of another token called “LP Tokens”. These tokens represent your share of the assets in the Liquidity Pool, and like PKT they can also be staked.

When you stake LP Tokens, you get Yield Credits in accordance with the PKT valuation of those LP Tokens and the duration of the staking, but you also get participation in a one million PKT per day special LP Yield.

Unlike your Yield Credits, the LP Yields have no requirement to run infrastructure, but they will end on August 21, 2025.

Something to take into consideration when adding assets to a Liquidity Pool is that the ratio of PKT/ETH changes over time. When people buy PKT, some of your PKT gets sold, and in its place is left some ETH. If the PKT price increases dramatically, much of your PKT will be sold away. This is called impermanent loss and it can be calculated based on the future predicted price.

However, even as your PKT is sold, you receive a rich reward from the LP Yields and the Yield Credits of your staked LP Tokens are based on the valuation of those LP Tokens at the time they were locked, so as long as you keep them staked and run infrastructure, you can earn Basic Staking yields on them for perpetuity.

How we ended up here

The really short version is that a group of anonymous Russians got control over the blockchain with a 51% attack, they won the support of part of the community, and then they bullied the remaining community into leaving.

When phrased in such simple and matter-of-fact terms, it seems absurd that we didn’t make this move sooner. But like the frog in the pot, it’s hard to know when you can say with certainty that you must jump or else you’ll be cooked.

We founded this project with a culture of decentralization, leaderlessness, and conservatism. When you do something like this, you want to believe that it’s going to work. The first shadow of evidence that the project might be in trouble was something we basically disregarded. If one were to dwell on every possible reason they might fail, they would never achieve anything at all. As more troubling revelations began to emerge, we looked for reasonable justifications of why maybe it’s not that bad, or why maybe it will sort itself out over time.

I am a strong proponent of non-interventionism. It has been shown that we humans tend toward “decisive action”, and that such action usually does more harm than good. But now looking back, from the moment the PKT project became centralized around the anonymous Russians and their shadow mining pool, it was in decline ever since.

If the Russians were as blunt as this all of the time, we would have forked the project long ago, but they showed themselves to be absolute masters of manipulation. They would come and go with different usernames like Florian, Devious, Noel, and Subzero. They would also occasionally introduce fake accounts posing as concerned investors. These “investors” would never have any linkedin or other background, and they would always quite conveniently insist that more control go to the Russians. The promises they made and the stories they told could fill volumes, and I think some people just wanted to believe that there’s a guy on a private jet talking to them and that he was going to make the wealthy beyond their wildest dreams.

What they did undeniably have was an obscene amount of compute power. Power that they could throw into mining at a loss, all the while destroying the value of the coin they were receiving. For a long time, we imagined that sooner or later the economic reality would hit them and they would realize that their antics hurt their wallets. Their endless stream of promises and manipulation also made it all too easy to imagine that “this time would be different”.

But none of their promises ever came to fruition, because before anything could be delivered, they would always go back to attacking, trolling, and generally damaging the project.

When Russia began their invasion of Ukraine, we were concerned because we had heard the rumors that they were running their infrastructure out of Moscow, and we worried that using Russian electricity to mine crypto for sale in the west might be seen as a sanctions issue.

Now mining at a loss, while also working to destroy the value of the coin you receive, is a pretty terrible way to evade sanctions. But that didn’t eliminate the feelings of uneasiness at the thought that maybe the project we had worked so hard for had become centralized in a datacenter in Moscow.

A number of community members became wise to them, and expressed their feelings about the situation, but because the Russians controlled over 80% of the blockchain, they were able to manipulate the mining payouts to buy favor from what was left of the community.

The real straw that broke the camel’s back came in April of 2024, when they announced that they were going to use their mining power to change the rules of the blockchain.

They even created a pull request on github to illustrate the change which they intended to force on everyone. A private discussion ensued and they agreed not to continue, but at this point the damage had been done.

Like a bucket of ice water over the head, all of the things that we had convinced ourselves to believe over the past 3 years suddenly fell apart. It was at this moment that we could no longer honestly stand in front of someone and explain PKT, without disclosing that we had a Russian problem. And it was at this moment that we began to work on what would become the new project, PKT on the BASE chain.

The Aftermath

It took almost precisely 4 months for us to complete and launch this re-invention of PKT, and the relief I feel from this change is astonishing. It is the first time in three years that I have felt truly excited about the future. Once you get used to coping with a bad situation, it becomes harder and harder to point to exactly what it is wrong. It becomes like a vague rain cloud over your head all of the time, just making life that much less worth living.

We have banned the anonymous Russians from all of our community platforms, and now they are relegated to their shady Telegram chats, where they preach the rise of “PKT Classic” and spewing vile hatred toward me and my family. I have tried my very best to get anyone to swap me their PKT airdrops in exchange for more PKT Classic, but even from their small following I have not been able to find one single taker.

There is still some enthusiasm for PKTC, I’ve decided not to turn off the PKTC infrastructure I run for the moment. Of course it’s provided as-is and as-available, and I will no longer maintain the code, but as long as it serves someone and doesn’t cost much to run, I don’t mind leaving it up.

I honestly hope the PKTC community will succeed. I never sold any of my coins, so I have as much incentive as anyone to see them do well. But realistically, the anonymous Russians are the closest thing they have to leadership, and the last three years have shown beyond a shadow of a doubt, the only thing they can deliver is damage. I’m afraid that as next month’s server bills come due, it is most likely that the Russians will disappear and rest of the PKT Classic community will simply give up.

But on the PKT side, we finally have a new way forward. Gone with the legacy UTXO technology and the anonymous Russians, we can now build what we set out to. Our next steps will be domains names, bandwidth leases, and smart contract based elections. All things enabled by the power of Ethereum smart contracting.

Thanks for sticking around.

Caleb

Subscribe now

Due to a mistake during deployment, the 3rd Airdrop (August 2025) is not possible, so everyone (myself included) will ⅓ less New PKT.

I have been working on the PKT project for almost 6 years, and even as the price has reached all time lows over and over and over, I have continued to push the boulder up the hill because of the people who believed in me. Perversely, I never even sold an appreciable amount of my coins. I’m not much of a “trader” and I’ve always said to myself “if I’m selling now then why am I here?” But even so, I still feel a moral responsibility to the people who did commit resources (one way or another) because of their belief in me.

Since 2022, the PKT project has suffered from a situation of one entity controlling over 50% of the total mining power. This was made worse by the fact that the operator of that mining project threatened on numerous occasions to roll-back blocks and otherwise cause chaos for the blockchain. Over and over it was suggested that he must eventually realize his actions are harming his own assets, but over and over he proved that he didn’t care.

I spent much of the year 2023 focused on building an election system that would use delegated voting to replace the flawed Network Steward, and in early 2024 that project reached its completion. The community at large was largely supportive, and the Network Steward committee accepted a project to pass along funds to whoever was elected by the new voting system. But the terrorist mining pool operator declared that he was going to unilaterally blacklist wallet addresses to freeze their funds.

This was the turning point at which I realized something absolutely had to change, and whatever we did would have to be done in total secrecy so that the blockchain dictator could not take revenge on those supporting it. Spring of 2024 was an exciting time, filled with brainstorming. What we came to was the elegant solution of an Airdrop. We would launch an entirely new token and gift that token to people based on how much legacy PKT they had in their wallets at a particular time. This allowed us to make a clean exit from the legacy PKT project, bringing all of our friends along with us. In the event that somebody wanted to continue the old PKT project, there was really nothing preventing them from doing so, but they would no longer hold power over us.

Deployment Day

Deployment day (or perhaps D-Day for short) was not only one of the most challenging days, but also one of the strangest days I can remember.

It started with me drinking my morning coffee and making a couple of transactions. I custody funds for Anode and Routie so on occasion I am asked to make a transfer. That morning I started my secure device and launched the wallet, as I had done literally hundreds of times before. I prepared the transaction commands and double-checked them, as I had done literally hundreds of times before. I posted the transactions to the network, as I had done literally hundreds of times before. But for the first time in the history of me using PKT, the transactions went missing. They didn’t fail to confirm, they just disappeared.

I checked my peers, suspecting perhaps I was connected to malicious nodes, but the peers I was connected to were run by highly regarded community members - one of my peers was even a node run by me! I closed and restarted the wallet, forcing it to connect only to my node, and I re-posted the transactions again and they went through, but this would be only the first in a day of one-in-a-million events that I struggle to explain without looking beyond the physical.

The plan for Deployment Day was to launch with a small amount of liquidity, check that the launch had gone well, and then enlist a market maker in bringing the rest of the liquidity in while letting price discovery happen naturally. However at the last minute, we received expert advice that we should instead bring all of the liquidity at once. Being new to this space, I was inclined to accept that advice, but that turned out to be a mistake.

Most of Deployment Day was spent checking, double-checking, and triple-checking the configuration for the deployment, and the plan, while waiting for everyone to be ready for a coordinated release. The plan was to deploy about an hour before the public event, just long enough to check that the deployment was correct. But the market maker has issues getting ready, and an hour turned into 30 minutes, and then 15 minutes, and finally the event was just beginning and the deployment hadn’t started.

Finally, we decided we just had to do it, market maker or not. This was where the second freak incident of the day took place. We had deployed numerous times before, both on testnet and also multiple tests on mainnet. But this time, the deployment script decided to crash. Later on, it was identified that the deployment requests were not waiting for a block to complete so it was possible for them to land in the wrong order - but this bug slipped past multiple professional developers and testers. The token, liquidity pool, and LockBox all deployed, and then the script crashed.

But because we had deployed all of the initial liquidity at once, the token immediately began trading. I was on a call with a smart contract expert and I was already late for the event, and it was at this point that I did something that I should not have done - I went off the plan, and I tried to edit the deploy script to skip the first two steps and only do the rest.

The script was not meant to be run in parts, and there were variables which were not set - something I did not have the time or focus to properly notice. I edited the script, ran it again and it did one more step before crashing, and I edited it again to skip that step and fix the issue that crashed it, but in the heat of the moment I didn’t hit save before running.

1,266,383,720 PKT was sent to the Yield Vault. Twice.

I immediately began discussing with the solidity expert if there was something we could do to turn it back, but the contract had no escape hatch and the token was already actively trading. There was nothing I could do except join the presentation. As I was preparing to go live, the man who contributed the liquidity said to me “You may not believe it, but God has a plan” and after everything that happened that day, those words really stuck with me.

I’m told that I looked like a living human being during that presentation, I felt like a zombie.

The Yield Vault is a contract which gives out yields to the Executor so they can be distributed to the people staking and running infrastructure. The amount of yields that it gives out perfectly matches the amount of coins yielded by the original PKT blockchain, complete with the 100 day decimations. It also has an additional 365 million PKT allocated to those who stake the LP Token. But most importantly, none of its logic depends on how many coins it has, so the additional 1.266 billion PKT that was accidentally sent there will never be yielded. It’s effectively burned.

After the presentation was over, I could barely even look at the deploy script again. I updated the server and opened access to the airdrop signer app, but there were no coins in the airdrop contract so anyone trying to use it would get a failed transaction. There are a total of 3,787,165,551 PKT worth of claims in the Airdrop, plus 563,534,048 PKT meant to go to the exchanges and 100,000,000 that was intended for marketing.

The first thing I did was to send 1 billion coins to the Airdrop so that it would begin functioning. The Airdrop does not need all of the coins to work, but if it is undercapitalized then it could eventually run out. I hadn’t done the math of where the coins needed to go, but I knew I could safely send it 1 billion. Then I put aside the exchange coins so that they would receive everything, and I paid the 100mn to the marketing fund. After this I put 262,388,517 into the Airdrop so that it would have 1,262,388,517 PKT, exactly enough to pay out every possible claim in phase 1. At this point I was left with exactly 1,241,309,993 PKT, just 21,078,524 short of the amount needed to fully capitalize the second phase of the airdrop.

When we designed the New PKT project, we wanted everything to be as similar as possible to the legacy PKT project, right down to the 100 day decimations. As a result, the Yield Vault begins it’s yielding on an even decimation date, i.e. July 19. Because this was from before the date of the deployment, there were some “past yields” that could be claimed by the Executor. At this point the Executor was still the deployment address so I invoked a claim and was awarded 29,982,286 PKT, exactly 8,903,762 PKT more than was needed to capitalize the 2nd phase of the Airdrop. That 8,903,762 was then sent to the bot which sends out the yields.

Where we are now

Until just a few hours ago, there was a lot of uncertainty about what we were going to do. Some people suggested we should re-deploy everything, put everyone back to square one, and allow them to start over. After thinking deeply about this, I decided that the only way forward was to follow our plan and trust in God’s. Everything that went wrong for us was something where we deviated from our plan, so I became convinced there would be no cure found in further deviation.

I am not normally a religious person, I believe things that I can see with my own eyes. But the events of the past two days have shown me things that I cannot explain rationally. Why did the deploy script crash this time only? Why was the amount lost almost precisely equal to the amount of the 3rd airdrop? And what actually happened to those transactions on that morning?

As of right now, the plan is that the 3rd phase of the airdrop will be disabled. Letting some people claim their 3rd phase while others may not have claimed their 1st or 2nd would be unfair to people who don’t pay attention and only discover the project later. We may as a community choose to migrate again to a different contract so that people can have their last third, but without a terrorist mining pool, that is a decision we can make together and in the open.

It’s been a bumpy ride and I thank everybody for hanging in there. We’re just have to keep following our plan, and trusting God’s.

In this new project, the PacketCrypt mining algorithm is gone. In place of mining you will be able to earn yields by staking PKT and operating infrastructure. PKT holders are able to claim an airdrop of the new coins which they can sell, or stake in order to yield more.

This project is, at it’s heart, a technological upgrade of the original PKT project, and in this post I will explain why.

It has been five years since the launch of the PKT project. In those five years we have had some success, and we’ve had some setbacks. It’s a good time right now to take a look at where we are, and where we want to be.

The first and perhaps most important success of this project is that we’re all still here. Everyone who was around from 2019 through 2021 is still here today. To think of the number of projects which came and went over the past 5 years is staggering, so for that alone, we’re in the top of our class.

In the years since the project was launched, the crypto world and the world at large have both changed radically. As is the norm with cutting edge technology, some ideas which were expected to become the global standard did not reach their goals, while others which were considered fatally flawed ended up seeing those flaws resolved and then going on to thrive.

There’s always a certain amount of pride that gets tied up in technological picks, and that pride is necessary because you can’t win if you don’t believe. But when you have numerous different projects all vying for dominance, the chance of backing the wrong horse is incredibly high. When it becomes clear that you’re on the wrong path, you need to be able to put your pride away and pivot.

In 2019 when we launched the PKT project, there were really only two mainstream ways to launch a project. Either you launched a Layer1 Proof-of-Work coin, or you launched an Ethereum token with an ICO.

At this time, Ethereum tokens were often painfully expensive to transact in, and the Ethereum community had no convincing plan for scalability. On the Bitcoin side, Lightning Network was designed from its inception to scale all across the world, and given that it was modeled on the already dominant SWIFT payments system, there was no reason to think that it wouldn’t.

Finally, Bitcoin had a much better story at that time, they were the stoic developers, the “adults in the room” who had never hard forked since 2010 and would sit back and let other projects innovate and then simply copy the winners.

PKT has always prioritized the long haul, and when we launched, there was simply no better alternative than a native Proof-of-Work chain. But times have changed, and developments within the Ethereum ecosystem have accelerated to such an extent that I think it’s highly unlikely that other ecosystems will ever catch up. The biggest game-changers that I’ve identified are Proof-of-Stake, Optimistic Rollups, and Liquidity Pools (DEXes).

Proof-of-Stake

In 2019, it was widely believed that Proof-of-Stake could never work. The reason for this was because mathematical modeling showed that as the rich get richer, they would eventually control over half of all coins and then by extension they’d control the whole project. It was also suggested that Proof-of-Stake projects might fork into multiple different chains, both equally valid and with no way for nodes to tell which is correct. Proof-of-Work uniquely has a “connection to reality”. Anyone can trivially check that the work has been done, and anybody can trivially participate in doing it.

What we have learned since the Ethereum 2 launch is that Proof-of-Stake is not actually as dangerous as we had feared, and Proof-of-Work is not as decentralized as we had imagined. The main risk from Proof-of-Stake, that the rich would get richer until they control the whole project, turned out not to be an issue. Once the initial coins have been issued to the community (by Proof-of-Work in Ethereum’s case), the block reward could be cut down dramatically, as stakers do not require nearly as much resources as miners.

The world famous decentralization of Proof-of-Work has also proven to be not what it seemed. It was believed that Proof-of-Work would correspond roughly to the will of those buying into the project. In reality, it ended up representing the will of those who are able to mine at a loss. Most people are not able to mine at a loss for any extended period of time, but there are some who can. These will include scammers, botnet operators, and other underworld figures who typically have no interest in the project except to mine and sell, but they can also include nation-states, intelligence agencies, and other similar power structures that may have significant interest in controlling, influencing, or undermining a project.

Since Ethereum has switched to Proof-of-Stake, the largest staker has only 24% of all the staked Ethereum. 48.7% are “other” operators too small to count. In contrast, Bitcoin mining has largely centralized around two organizations, AntPool in China, and Foundry USA. Both of these organizations are almost certainly mining at a loss, with support of governments who know that without willingness to lose money mining, they would lose their influence over the Bitcoin chain.

The PacketCrypt bandwidth-hard Proof-of-Work has unfortunately proven even more susceptible to centralization. This is because bandwidth is much less costly when it is between mining equipment that’s all in the same room. This centralization risk was known at the time of PacketCrypt’s creation, but it was thought that Proof-of-Work in general was resistant to centralization and this safety margin of resistance would hold.

What we learned was that all Proof-of-Work tends to centralize around those willing to mine at a loss, Bandwidth-Hard Proof-of-Work just does so faster.

In PacketCrypt’s history, there was once a rather flattering suggestion that it would eventually kill the internet. This was around the time when it was fashionable to claim that Bitcoin mining was destroying the planet. Of course none of these things ever came to pass, but what has occurred is that mined coins have proven less competitive than their non-mined counterparts.

With the timestamping problem solvable by Proof-of-Stake, the only justification for Proof-of-Work is fair issuance of the coin. But even that is now solvable by making a coin which yields new issuance to whoever stakes the liquidity pool.

New projects without Bitcoin’s gravitas are almost universally turning away from Proof-of-Work because even if it doesn’t destroy the internet, or cook the planet, it does still create a massive drain of resources out of a project’s ecosystem. With all of the other options available now, I find it highly unlikely that any new projects will become successful on top of a Proof-of-Work validation architecture.

Optimistic Rollups

When the PKT project first started, creating coins and tokens was very expensive. Either you needed to create your own blockchain, or you needed to build on top of a project like Ethereum with its high fees. Creating one’s own blockchain obviously requires an extraordinary amount of effort, and it’s clear that while Ethereum could serve hundreds or even thousands of projects, it will never satisfy the demand for tokens, especially as we in the PKT project envisioned the rise of a bandwidth marketplace where units of bandwidth would be represented as tokens.

We had an idea for a protocol which we called TokenStrike. TokenStrike would allow the scalability necessary for nearly free tokens, each of which would exist on its own micro-chain and would be exchangeable using the Lightning Network.

Much of the PKT Roadmap was predicated on the expectation that the Lightning Network would blossom to become the global standard in instant settlement and cross-chain transactions, but five years later we are forced to admit that the Lightning Network future simply did not materialize.

What came in place of both Lightning Network and TokenStrike was the Optimistic Rollup. Ethereum is obviously quite costly to transact in as it is a well known chain and it has limited block space. It has always been possible for others to create Ethereum-like blockchains, but these would be disconnected from the main Ethereum chain and so they couldn’t be used to hold the actual ETH asset, until Optimistic Rollups were invented.

The essence of an Optimistic Rollup is that one can place Ethereum into a contract where a certain validator (e.g. a company) is then authorized to decide where and when it should be sent. The validator runs their own blockchain, and when you send ETH to their contract, it credits you with the same ETH on its internal chain which you can withdraw back to main Ethereum at any time.

While the validator has the primary right to initiate transfers from the contract, there’s a safeguard against it stealing people’s coins: The contract allows people to challenge the validator’s decision, requiring the validator to then prove that the coins it’s sending went through a legitimate chain of custody on its blockchain. Because the validator’s chain uses the same smart contract language as the main Ethereum chain, all of the transactions made on the validator’s chain can be understood by the Ethereum chain, in case it needs to show its work.

This simple protocol completely changed the game for Ethereum scalability. While there’s only one Ethereum main chain, there’s no reason why there couldn’t be hundreds, or even thousands of side-chains built on variations of this technology. Not only did Optimistic Rollups get out ahead of what TokenStrike intended to become, Optimistic Rollups even got out ahead of Lightning Network as a whole.

Since the beginning of 2023, Bitcoin Lightning Network has stopped growing in BTC terms. The rising price of Bitcoin has brought it up to $400mn of liquidity, but even that pales in comparison with Uniswap’s gargantuan $3.09bn of total locked value. In the world of protocols, network effect is king, and there’s just no metal for coming in second place.

Liquidity Pools

As of this day, 2021 has been the most successful year the PKT project ever had, and it was also the year that Liquidity Pools, or “DEX”es made their debut. The idea of an LP for those who aren’t familiar, is a smart contract which allows people to place the two assets (e.g. ETH and PKT) in the contract, and then people can use the contract to swap (exchange) between one asset and the other without a counterparty.

Based on this relatively simple concept, Liquidity Pools have emerged offering the ability to transact between all different types of assets without all of the bureaucracy, risks, and costs associated with centralized exchanges. If you want to create a joke token to trade with your friends, no centralized exchange will ever list it, but you can trivially deploy a Liquidity Pool contract. Simplicity, flexibility, and low barrier of entry have driven Liquidity Pools to take the exchange market by storm, with the Uniswap ETH/USDT market holding more liquidity than the largest centralized exchanges.

This democratization of token trading is something we described in TokenStrike and the PKT Whitepaper. We just imagined that they would come through the Lightning Network and cross-chain atomic swaps, and instead it materialized in Ethereum based technologies.

The Way Forward

With low cost smart contract platforms, things we could only dream about are just a few lines of code away. We spent five years laboring on the PKT Lightning Wallet, only to find that we were building on a tech stack that was slowly turning into a ghost town.

In the 1990s, Apple bet a their computer business on the IBM PowerPC microprocessor architecture, and this was actually a good idea at the time. PowerPC was the best thing out there, it was backed by IBM, and there was every reason to think it would become the standard. Intel was a relatively small company, and their x86 based processor was a cobbled mess by comparison. But over the decade, Intel began to chip away at PowerPC’s dominance and as their chips got put into more and more PCs, they became faster and faster until eventually it became clear that the PowerPC was not going to catch up.

In the world of competing standards where network effect is everything, there is no prize for second place. Apple understood this and they made an extremely bold move and pushed their entire ecosystem over from PowerPC to Intel architecture. This was not just a change of processor, but in fact a change of byte order. So all of the code written by Apple and Apple developers had to be checked for issues. This kind of bold action is something you only do when you know the alternative is being stuck with a protocol that will get a little bit smaller, and a little bit further behind every year until it eventually dies. Apple was smart enough to take this bold action, and they have gone on to become a trillion dollar company, while the PowerPC architecture has faded into obscurity.

By moving to the the Ethereum based ecosystem, we will have the ability to implement on-chain domain names, bandwidth leases, and bandwidth trading markets all within the year. These things were so far out of reach before, we struggled to even build a good quality wallet. This was because we were the ones having to build everything ourselves.

This transition not only integrates us into a true thriving ecosystem, but will give us the ability to get back to executing the PKT mission as defined in the whitepaper.

Subscribe now

PKT World has given us:

• The PKT World wallet

• The PKT World explorer

PKT Watch has contributed:

• The Packetscan explorer

• The Minr app

• The Watchr app

And Routie has supported:

• The AnodeVPN app

• The Anode iOS wallet

• The cjdns YunoHost integration

That’s not to mention all of the community members who donated their money as well as their sweat, blood and tears, to make the MEXC exchange listing happen. This type of community infrastructure is exactly what the Network Steward was originally intended to support, but for reasons that are elaborated in an earlier post, the Network Steward committee is no longer capable of fulfilling it’s original objective.

After significant effort throughout the year 2023, I was able to establish a new voting system for PKT. This voting system is already in production and the funding rounds are soon to begin.

Stepping carefully into the future

The goal of the PKT project is to democratize the way people interact with the internet. Clearly we must be capable of innovating and learning from our mistakes, but the single greatest innovation of blockchain technology as a whole, is the ability to have an absolutely predictable monetary policy.

The long term stability of a project like Bitcoin or PKT depends on the consensus rules being hard-coded in widely disseminated code, and on a fanatical commitment to keeping the things exactly as they are.

When people buy a coin like BTC or PKT, they are trusting in a set of rules, and it is of the utmost importance that the project community doesn’t “change the deal” of what they signed up for.

Jamie Dimon, the famous CEO of JPMorgan Chase at one point postulated that the limit of 21 million Bitcoin may be increased in the future. As intelligent and insightful as he is, this prediction is wrong by definition. Even if someone were to modify the code of Bitcoin to expand the maximum number of units beyond 21 million, and even if they convinced a lot of people to call their modified version “Bitcoin”, it wouldn’t be Bitcoin.

Every one of those “other” coins beyond coin number 21 million wouldn’t be a true Bitcoin, and the true Bitcoin software would know it.

When blockchain code is changed in such a way that the original code no longer accepts coins produced by the updated code, this is what’s known as a hard fork.

Remembering the Blocksize War

In 2015, Mike Hearn and Gavin Andresen, two of Bitcoin’s most senior core developers at the time, proposed a hard fork of Bitcoin. Not to increase the number of coins, but to increase the number of transactions that could be processed per minute.

This seems like such an obvious technical improvement, and Satoshi himself indicated in his writing that something like this would be necessary. In fact, the limit that they were proposing to increase was only created in 2010 as a temporary measure to deal with an onslaught of spam transactions at that time.

But not everybody saw it that way. Some people rightfully pointed out that increasing the limit would do nothing to solve the long term problem: That there’s simply no way for a blockchain to scale big enough for the whole world, while also remaining securely decentralized.

Others thought that the limit was being raised too much, or too little, or that it should be replaced by a variable limit. Discussions went in circles for years, with nobody able to build true community consensus that their idea was right.

In 2017, a team of three developers proposed a new system called Segregated Witness, or Segwit. Segwit offered a way to squeeze out some additional transactions per minute without really requiring anyone to upgrade anything.

To an old Bitcoin node, a Segwit transaction would look like a strange little transaction which didn’t have any cryptographic keys, so it could be spent by anyone! But an updated node would see the pattern in the transaction and know that it needed to request additional information which would contain the cryptographic signatures (i.e. the Witness) needed to actually validate it.

This segregation of the “witness” from the transaction would slightly reduce the size of the transaction and thus allow a few more transactions per minute without violating the limit that was established in 2010. Segwit also fixed a number of other issues with Bitcoin’s design by creating new rules for these new transactions, but that’s another story.

Because the new transactions would be perfectly acceptable to the old Bitcoin nodes, Segwit is what’s known as a soft fork. A soft fork imposes new rules on the blockchain, but does not change any existing ones.

At this time, the Bitcoin community became embroiled in drama, with different parts of the community insisting that Satoshi’s True Vision was being destroyed, and that their ideas for Bitcoin were the right way forward. Three new projects were formed: Bitcoin Cash, Bitcoin Gold, and Bitcoin SV. These were adversarial hard forks, meaning they not only required an update to the old code, but they also had different project leadership.

Each one of these projects vehemently argued that they were the true continuation of Bitcoin, and as such they alone should bear the name Bitcoin and the abbreviation BTC. Miners, merchants, and exchanges largely disagreed, and today there is a general consensus that these projects are indeed separate forks of Bitcoin.

When the question of which blockchain is The True Bitcoin was finally settled, it was the one that did not ask people to install new software.

Innovation vs. Conservatism

In the crypto ecosystem, few projects are as conservative as Bitcoin.

One good example is the well regarded project Monero. Monero is widely known for it’s technological excellence and for providing financial privacy to its users, but the mathematical trickery needed to achieve private transactions on a public blockchain is still largely uncharted territory. Because of this, the Monero developers need the flexibility of being able to update the protocol from time to time. So every few years the developers plan and announce a hard fork and ask the community to upgrade their software to the new version. The developers are very careful not to change anything which could be regarded as “changing the deal”, and the users generally trust them and accept the hard fork as still being the true Monero.

Another project which has been somewhat less judicious about changing the rules has been Ethereum. The Ethereum project was the first major project to implement smart contracts, but their “value proposition” is perhaps more the team than the technology. People buy into Ethereum knowing that the team might change something later, and that’s ok because people are buying into the team.

The Ethereum project has undergone numerous hard forks, including multiple changes to the mining algorithm and the smart contract language. They even had one rather embarrassing hard fork to revert the theft of coins from a vulnerable smart contract. More recently, the Ethereum project has hard forked away from proof-of-work altogether, opting for a proof-of-stake system instead. What lies ahead for the Ethereum project is hard to say; they are clearly more innovative than most, but as the team changes over time and they explore new territory, there is a risk that they end up in a situation they can’t easily resolve.

In the PKT project, we have one of the most conservative development lifecycles in the whole cryptosphere. In our four and a half year history, we have had exactly one hard fork, which happened just a couple of months into the project to fix a bug that made PacketCrypt not bandwidth-hard. We started off with the Bitcoin protocol because it had been proven, and we don’t foresee needing to ever change it in the future.

We believe that when a person joins the PKT project, what they’re “signing up for” is the project exactly as it is - and it’s not the prerogative of any one person or group to change that agreement under their feet. We have been more conservative than even Bitcoin, taking a “wait-and-see” approach to the Taproot soft fork, one which turned out to have an unintended consequence of enabling large JPEG images to be inserted into the blockchain.

So with our strong tradition of putting stability first, it would look like the idea of a new Network Steward vote would be dead in the water - but in fact the whole thing can actually be achieved through a clever soft fork.

Soft forking to a new voting system

The way to change the voting system through a soft fork is not to actually change it, but rather to impose a new rule upon the existing Network Steward: It can only send coins to the winner of the vote.

This little trick keeps the original Network Steward voting system in tact, and neatly layers the new system on top of it. We must be very careful because any flaw in the new system may create a situation where a hard fork is the only reasonable solution. This is why the new voting system has been in development for over a year.

We have decided that the process will be as follows:

1. A Network Steward “project” is proposed and accepted with the existing Network Steward, the objective of this project is to fund the new one.

2. After the process has been tested and is well understood, we will encourage mining pools to update their PKT-FullNode instances to a version with the soft fork.

3. Once over 90% of the miners are signaling that they support the soft fork, the fork will trigger and the Network Steward will become unable to fund anyone except the winner of the election - though they will still be able to halt funding if something goes wildly wrong.

4. After the soft fork has solidified, the old Network Steward committee will be able to retire, by publishing their private keys to the multi-sig wallet. At this point, anyone will be able to sign transactions from the old Network Steward and only the soft fork will control where those coins can go.

The timeline for this process is not set in stone. It would be nice to be approaching stage 4 one year from now, but this is not at all mandatory. In fact, this process can happily sit in stage 1 for as long as it takes to establish confidence in the new voting system.

PKT-Voter and the Packetscan Vote Explorer

Two exciting new developments have emerged to support the up-coming voting. One of them is the PKT-Voter, and the other one is a new vote explorer developed by KuzuDR, the author of Packetscan and PKT.Watch.

PKT-Voter is a simple GUI application allowing you to cast a vote using a private key from whatever PKT wallet you use. You can download it here: https://github.com/cjdelisle/PKT-Voter/releases/latest

To use it you open the app, paste a private key, and enter the address you want to vote for. You can also check a box to become a candidate. Every vote overrides the previous vote, so if you cast a vote and then you decide you want to change it, you can just cast another vote.

If you want to withdraw your vote, you can cast a vote for “nobody” by checking the “Vote for nobody” checkbox in the app. You can be a candidate and vote for nobody, though it’s recommended that you also vote for someone else so that if you don’t win, you will give them a chance. In case it wasn’t clear already, there is no possible way that your vote can cause you to lose.

A fundamental part of the Electorium voting algorithm is that as a candidate, you always implicitly vote yourself first. A corollary of that rule is that explicitly voting for yourself is meaningless, it is exactly the same as voting for nobody at all.

When you are voting with the PKT-Voter tool, please remember that private keys are sensitive information, if anyone gets ahold of your private key, they can spend all of the PKT on that address.

Once you have cast your vote and the transaction has landed in the blockchain, you will be able to view it in the Packetscan vote explorer, here: https://packetscan.io/election

Packetscan shows the voters and the candidates as a graph. The “leader” is the address that would win in the next election if it happened right away.

Note that the number of votes shown for an address is the maximum number of votes they can possibly get. The address with the most possible votes is not necessarily the leader. Consider the following scenario: I have 100 votes, you have 3 votes, I vote for you. Now you have 103 possible votes, but if I’m a candidate I won’t actually delegate those votes to you because I win.

It’s also possible for a candidate to win even if nobody voted for them - if they have an address balance that is so high, that it is more than the maximum number of votes that the leader can receive. Remember, every candidate always implicitly votes for themselves first, so their address balance is first voting for them.

In the last piece of news: KuzuDR, the author of Packetscan has announced his candidacy! He is the first ever candidate for the Network Steward position. His objective is to use the funding to build a web app for other candidates to explain their platform. You can read all about what he intends to do on https://pkt.watch/election.

To vote for KuzuDR, vote for:

pkt1q6sj0mchq7ltwm8c9tpm2wteqmeldr2ye5lcr60

I am not going to be a candidate (for now), but you can still vote for me if you want, I am currently going to be voting for KuzuDR but I will adjust my vote over time according to what I think is right for PKT.

To vote for me, vote for:

pkt1q3t2aqgyt4v8k69he3mztrl90yynyu6ta333cjd

Lets make this happen!

But a project without founders has a different kind of challenge. In a fully decentralized blockchain project, the best strategy is to mine and buy as much of the coin as possible, then sit back and wait for someone else to build the ecosystem. But if everybody does that, the project will never amount to anything.

I was aware of this challenge when I originally wrote the code, and for this I created the Network Steward, an address which would receive 20% of the block reward and could use it to help the community. Because it is a decentralized project, the Network Steward would be selected by a vote of the community but the voting system had some severe limitations.

If you haven’t already, check out my previous installments to read about the problem and how we are going to fix it.

The purpose of money within any nation is to act as a score-keeper, rewarding those who provide the goods and services the nation needs. This money can be used to enjoy lavish lifestyles, but because it’s allocated in accordance with the provision of goods and services, those with the most of it tend to use it for doing more of what they do: providing goods and services. By this way, the bulk of the nation’s actual physical resources are placed under the command of those who have the track record of servicing the nation the best.

Of course the reality of money rarely lives up to the dream, and people have found multitudinous ways to cheat at this “game”. Theft, fraud, extortion and monopolization are all ways to acquire money without providing the requisite value, and the endless cat-and-mouse game between the nation and its cheaters makes up the history of law.

Just as money alone cannot differentiate between transaction and theft, money also cannot recognize those contributions which everybody needs, but nobody’s incentivized to pay for. A common retort against radical libertarianism is “who will build the roads?” This is perhaps a weak argument because roads can be built privately and funded by tolls, but there are things which everybody needs and which cannot be realistically monetized once built.

But beyond this, there is another type of value that falls even further out of reach of the monetary score-keeper. That is the intangible value of such things as Honor, Integrity, and Discipline. Those who keep on the straight and narrow usually end up materially better off, as the reputations they build open doors for them in the long term. But reputation is a messy business. Unlike money there is no global score-keeper, and between baseless accusations and false claims of innocence, it can take a very long time for the truth to pan out.

From the beginning of the PKT project, the Network Steward was conceived to address the first type of need - those things which everybody needs but nobody is prepared to pay for. And while the introduction of Electorium to the Network Steward vote will undoubtedly bring a renaissance to the institution, Electorium aims to go much much further.

The Electorium delegated voting algorithm asks everybody the simplest of questions: “Who is most fit to lead?”, and by answering that question, people create a web-of-trust. But because this web-of-trust is anchored by the address balances of those who’ve voted, it also creates a global reputation score. A sort of reputation number made up of not just your coins, but those of everyone whose vote could potentially be delegated to you.

Unlike “social credit” which is handed down by a fallible central authority, this is a true representation of the will of the people. And while nothing will ever be a perfect score-keeper, becoming just a little bit better is doing The Good Work.

Voting with pktwallet

You can now vote using the legacy pktwallet command line wallet as well as the PKT Lightning Wallet. In the last installment of this series, I presented a brief how to for voting with the PKT Lightning Wallet and in this version I will explain how to vote using the legacy pktwallet:

1. Download and compile the newest version of pktwallet

git clone https://github.com/pkt-cash/pktd 
cd pktd
./do

2. Create a new wallet to test out the voting

./bin/pktwallet --wallet=vote_test_feb6_24 --create

3. Launch pktwallet

./bin/pktwallet --wallet=vote_test_feb6_24

4. In another window, create a new address so you can vote with it

./bin/pktctl --wallet getnewaddress

5. Send some coins to that address

6. Check that your coins have arrived using getaddressbalances

./bin/pktctl –wallet getaddressbalances

7. Once you see your coins in the address, you can unlock your wallet so that you’re able to vote. In the place of <your password> put the password you configured for this wallet

./bin/pktctl –wallet walletpassphrase '<your password>' 600

8. Send the vote. In place of <your wallet address> you will put your real address in this wallet, and in this example you will be voting for pkt1qpl48jdwyn3t0uj7lu303f5szejgl5dmc0p2vpu

./bin/pktctl --wallet sendvote <your wallet address> \
    pkt1qpl48jdwyn3t0uj7lu303f5szejgl5dmc0p2vpu

9. Once your vote transaction has confirmed on the chain, you can check your vote using getaddressbalances again. This time it should show specific vote information for your wallet address like so:

./bin/pktctl --wallet getaddressbalances                                                                                 
[
  {
    "address": "pkt1qj6nldg0klm5pqyam8cg6lvzcuq432kpc5d9scn",
    "total": 99.99899960309267,
    "stotal": "107373108232",
    "spendable": 0,
    "sspendable": "0",
    "immaturereward": 0,
    "simmaturereward": "0",
    "unconfirmed": 99.99899960309267,
    "sunconfirmed": "107373108232",
    "outputcount": 1,
    "vote": {
      "vote_for": "pkt1qpl48jdwyn3t0uj7lu303f5szejgl5dmc0p2vpu",
      "vote_txid": "4d590a6f45d1f992bea8e97995539c789e942425c40c32f928cc5308f16ccdd2",
      "vote_block": 2336429,
      "expiration_block": 2860589,
      "estimated_expiration_sec": 1737468646
    }
  }
]

You can see who you voted for, the transaction ID of your vote, the block number where your vote was registered, the block number when your vote will expire if it is not renewed (by voting again), and an estimation of when that will happen.

You can learn more about the sendvote command by running ./bin/pktctl —-wallet help sendvote and you can even cast a vote where you register your candidacy to potentially be the Network Steward yourself!

Counting Votes with PKT-FullNode

In a new unreleased version of PKT-FullNode, you are able to count the votes and see who is the winner. Because the vote counting code requires computing the address balance, you can also use this version of PKT-FullNode to query the exact balance of any address on the blockchain.

While this version of PKT-FullNode is not yet released, it is generally considered to be safe to run in most operational environments. To try it out, do the following:

1. Get the code from github and compile it

git clone https://github.com/cjdelisle/PKT-FullNode
cd PKT-FullNode
./do

2. Launch PKT-FullNode, this will take a few days to synchronize with the blockchain. If you already have a synchronized PKT-FullNode then it will use the same data and will just need some time to compute address balances and votes.

./bin/pktd

3. If your PKT-FullNode is downloading the blockchain, you can check from time to time the height and compare it to a block explorer to see how close it is to completion. If you already have a synchronized blockchain and it is indexing the address balance and vote table, then this command won’t work until it’s done

./bin/pktctl getbestblock

4. Once your PKT-FullNode is up to date, you can check the current voting addresses with listaddresses

./bin/pktctl listaddresses '' 1 1

The arguments to listaddresses are:

• Continue From - The listaddresses command will only provide at maximum 200 results. If in the result, has_more is set to true, call listaddresses again but providing the last address from the previous reply, and it will respond with the next page of 200 addresses.

• Current - If this is set to 1, it will yield data from the last block, otherwise it will show data from the last election (once per week).

• Voting Only - If this is 1, it will only yield addresses who have registered votes.

The reply looks like this:

{
  "addresses": [
    {
      "address": "pkt1qpl48jdwyn3t0uj7lu303f5szejgl5dmc0p2vpu",
      "balance": 99.99999986309558,
      "sbalance": "107374182253",
      "is_candidate": true,
      "vote_for": "pkt1qtu5y64ln9n9mw3e88ydt28jgmu327ygme8y54t"
    },
    {
      "address": "pkt1q2yt8djdlykf2d9ukmw0q5z5tur05xm674tq6y8",
      "balance": 3.477373135276139,
      "sbalance": "3733800973",
      "is_candidate": true,
      "vote_for": "pkt1q2yt8djdlykf2d9ukmw0q5z5tur05xm674tq6y8"
    },
    {
      "address": "pkt1qj6nldg0klm5pqyam8cg6lvzcuq432kpc5d9scn",
      "balance": 99.99899960309267,
      "sbalance": "107373108232",
      "is_candidate": false,
      "vote_for": "pkt1q2yt8djdlykf2d9ukmw0q5z5tur05xm674tq6y8"
    },
    {
      "address": "pkt1q6jqalrwahf5atdmu0m2sve36rrvl56vp8m55nk",
      "balance": 666.3360477378592,
      "sbalance": "715472883295",
      "is_candidate": false,
      "vote_for": "pkt1q2yt8djdlykf2d9ukmw0q5z5tur05xm674tq6y8"
    }
  ],
  "as_of_block": 2357058,
  "has_more": false
}

The balance field is the amount of PKT the address has, sbalance is the amount of atomic units of the coin. The is_candidate field indicates whether the voter has declared their intention to candidate, and the vote_for field is whoever they have voted for.

Coming soon, there will be updates to the PKT Block Explorer code which will allow exploring the votes, who voted for whom, who has the highest reputation, and who is most likely to win in the next election.

Be sure to subscribe so you’ll catch the next update, and until then be awesome.

Subscribe now

In 2023 I began thinking about how to design a new voting system. Clearly we needed to stop requiring a fixed percentage of PKT coins to call an election, because as the community evolves, whatever number we pick eventually becomes too high. It also offered a great opportunity to dispatch with the awkward voting process where coins needed to be placed in “voting transactions”.

But I didn’t want to just fix the obvious flaws of the original system, I wanted to create the great voting system. I wanted a voting system which would empower voters more than the traditional first-past-the-post election process.

The problem with first-past-the-post voting is that it only really represents the will of the people when there are 2 options. When there are more than 2 choices, people have to vote for what they consider the lesser evil among the two choices most likely to win. Doing otherwise is "throwing your vote away".

Nobody ever sits down and asks themselves who is most fit to manage the affairs of the nation, the first-past-the-post system has deleted that question right out of people’s minds. Instead people argue over whether it’s going to be the blue guy or the red guy, and they think that’s democracy. It’s quite possible that the entire partisan landscape as we know it is an artifact of this flawed voting system.

There exist systems like Single transferable vote, Ranked-choice voting and Approval voting which aim to offer more agency to the voters, but these systems are conceived from the same limited mindset. In particular, they come from the perspective of the third party candidate.

The dream of the third party candidate is that if enough people would vote for him, he would no longer be “third party”. But to get there, he needs to somehow overcome the objection that voting for him means losing a chance to vote against The Bad Guy. Even the third party candidate does not ask the voter who is most fit to rule!

If we could just cast all the politics and partisanship aside and get to the real heart of the question, everybody’s answer would probably be different. We’d most likely have a beautiful patchwork of nominations including businessmen, professors, soldiers, clergy, and other people of distinction.

Now you might wonder what good that does if we still have no consensus on who it is that will actually lead. But at this point everybody who has been nominated could be considered a representative. So what if we simply delegated the votes to the representatives? If they don’t win, the votes would be passed along to whoever they voted for.

You might wonder what happens if you want to vote for somebody, but you don’t like who they would vote for. Well you can’t have it both ways, either you trust their judgment or you don’t, and the beauty of this system is that it forces you to reconcile that.

You also don’t get to evade moral responsibility by choosing a lovable candidate who's guaranteed to lose. The question before you is who is most fit to lead, and you cannot vote without answering it. If you do vote, it is highly likely that your vote will somehow help elect the final winner.

The Electorium algorithm

This computation of delegated votes is not as simple as it might seem. If Alice votes for Bob, and Bob votes for Alice, it is not immediately obvious who should win. Not only that, it is important that the counting process be fast, so it doesn’t impose significant performance penalty on the PKT FullNodes and mining pools.

To address this, I created a new vote counting algorithm which I call Electorium. It is in essence a search algorithm, it finds the candidate who cannot be beaten by anyone else, if we were to pretend that neither they, nor their challenger, voted for each other. So in the case of Alice and Bob, we pretend Alice is not voting for Bob, and Bob is not voting for Alice and we can easily find the winner.

There is also another case where perhaps Alice votes for Bob, but Bob does not vote for Alice. It might seem that Bob is the clear winner, but if the majority of his votes have been received from or through Alice, then by these rules Alice still wins. However, if there is another candidate who receives more votes than Alice but less than Bob, Bob becomes the winner because Alice loses and is forced to delegate her votes.

In Electorium you can vote for anyone, but no one is required to be a candidate. If you vote for someone who’s does not wish to be a candidate, your vote is simply delegated to whoever they vote for.

Everyone who chooses to be a candidate automatically votes for themselves. If they vote for someone else, that vote is secondary to their implied vote for themselves. To put it differently, voting as a candidate will never cause you to lose.

If a candidate explicitly votes for himself, his explicit vote is meaningless. It is the same as indicating his candidacy without voting at all.

The Electorium algorithm has been implemented in Rust and Golang both and has received extensive fuzz testing to verify correctness. If you are interested in how it works, you can learn more about it here:

• https://github.com/cjdelisle/Electorium

• https://github.com/cjdelisle/Electorium_go

Connecting Electorium to PKT

As with the old voting system, the new one values each vote by the amount of PKT the voter holds. This is of course unlike a standard national election where every citizen gets an equal vote. But like almost all blockchains, PKT has nothing analogous to the concept of the citizen.

One person can trivially pretend to be thousands, or even millions, of unique individuals. So PKT must by necessity adopt the model used in public corporations, where votes are weighted based on how much of the coin is held.

This idea of weighting the vote based on skin in the game actually makes some sense as well. In a national election, every citizen could be considered to have the equal skin in the game, it is their life and family that is at stake. But in the case of a project or online community, a person with little investment can easily walk away, so they cannot be expected to make decisions with the same level of care as someone whose involvement is greater.

Another limitation that would be carried over from the old system is that voting cannot be done anonymously. The right to vote one’s conscience without fear of repercussion is a fundamental part of the modern democratic process. But anonymous voting on a blockchain is largely uncharted territory, so it is not clear how, or even if, this could be achieved.

In any case, there is one advantage to public voting, and that is public voting of the delegates. When you choose who is to represent you, you certainly should know what decisions they make. Secret voting, while important for the general public, is abhorrent when done in the senate chamber.

In the Electorium system everyone is a potential senator, and everyone’s vote is a matter of public record.

As with the old system, the votes would be based on transactions, but rather than changing the transaction in any non-compatible way, the far easier solution was to simply make a payment of zero PKT to a special address. Like the Ordinals stored in Bitcoin, votes are not seen by FullNodes as anything other than strange but completely valid payments.

This means you no longer need to make sure all of your coins are in “voting transactions”, you simply cast one vote with your address and the entire balance of that address is then considered to be voting. Of course what simplifies the usage complicates the code, and this necessary change required implementing new logic to track the balance of each address - including non-voting addresses which might vote in the future.

And to get rid of the broken rule that 50% of all coins must call an election for one to occur, the new implementation uses the obvious choice - an election once per week. The choice of a fixed time period also has a technical benefit because it means there will never be two elections in rapid succession. Therefore it is allowable for the counting of the votes to take a longer time, so it can be done in the background without interrupting the all important processing of blocks.

You only need to vote once, and your vote counts in every election with whatever balance you have at the time of the election, until you either change it, or it expires. On the advice of a community member, I implemented an expiration time of 1 year so that lost wallets will not affect the outcome of elections forever.

The code for voting has been completed and is sitting in the unreleased PKT-Lightning-Wallet so you can be one of the first people to vote!

Casting a vote

To cast a vote, you need to install PKT-Lightning-Wallet on your computer.

git clone https://github.com/cjdelisle/PKT-Lightning-Wallet

cd PKT-Lightning-Wallet

./do

Then you can create a new wallet to test the voting system:

./bin/pld --create --wallet=voting_test_jan24_2024

Once you have created it, start pld using:

./bin/pld --wallet=voting_test

After it is running, open another window, navigate to the same folder, and make a new address:

./bin/pldctl wallet/address/create

Once you have the new address, send yourself a few PKT in order to vote with it. You can check your balance using:

./bin/pldctl wallet/address/balances

Before you can vote, you will first need to unlock the wallet:

./bin/pldctl unlock

And after you have unlocked the wallet using the password you configured earlier, you can finally cast your vote:

./bin/pldctl wallet/transaction/sendvote \
--from_address=<your wallet address> \
—-vote_for=pkt1q2yt8djdlykf2d9ukmw0q5z5tur05xm674tq6y8

If all goes well, you should see a transaction ID as the result, and within a few minutes you will be able to look up that transaction on any of the block explorers.

Here is a vote which I created while writing this document: 57d29c6662c7b12d96551418738f2bee77631266d8a1dfdd8982d467e11f5b88

You can see it takes 100 PKT (it will use the smallest amount it has available), and it cycles all of the PKT back to itself as change (excluding the minuscule transaction fee). It paid exactly 0 PKT to an address identified by the explorer as “Custom Script”. It did not even pay 1 nano-PKT, it is actually zero.

A few words of caution: If you use the CLI pktwallet, PKT-Lightning-Wallet will open your same wallet.db file and it responds the same way to the --wallet flag. PKT-Lightning-Wallet is still in development do not use it to open a large wallet yet!

To be continued…

In the next installment, I will explain the address balance and vote counting logic, and show you how you can look at the address balances and winners using the unreleased code in PKT-FullNode. Make sure you subscribe so you will receive that as soon as it comes out.

In the mean time, check out all of the other features that PKT-Lightning-Wallet has using:

./bin/pldctl help

You can also learn how to become a candidate by reading:

./bin/pldctl help wallet/transaction/sendvote

However, there was one component which did not work as well as we had imagined, and that was the voting mechanism designed to control what is known as the Network Steward.

The PKT Network Steward is an address which automatically receives 20% of all PKT that is created when new blocks are mined. It’s purpose is to ensure that there would be funding for the necessary infrastructure upon which the community depends. By rule, the Network Steward was required to use the coins it received in 90 days or else those coins would be “burned” (becoming unusable forever). While the original Network Steward was configured as a multi-signature address with myself and four people who I knew to be of high moral character, good discernment, and technical excellence, it was not meant to stay that way forever.

It was intended that this Network Steward would eventually be replaced by different ones, who would vie for community support through the voting system. Unfortunately, limitations of the voting system prevented that from ever happening.

One might say that the voting system was built too hastily, but the reality is that building a proof-of-work algorithm from scratch and launching a blockchain around it is already a heavy burden to bear. Any mistake made anywhere could lead to the type of devastating bugs which crash the blockchain or create hidden loopholes in the mining algorithm, allowing one miner to seize control of the project.

However, the effort to “harden” the code against these disastrous bugs led to a deeper problem - the election system was so awkward that it was essentially unusable!

The original voting system

In an effort to make the vote counting code as simple as possible, I made it only use the UTXO set that exists in the blockchain code, and not create or manage any new database tables. But this meant a vote would have to be attached to each individual transaction. If you voted and then someone sent you more coins, you would have to re-send those coins to yourself in a new transaction with a vote attached.

Secondly, SegWit transaction outputs could not contain votes because SegWit outputs are required to have an exact format and the addition of vote metadata would make them invalid. This was not a concern at the launch of the project, as we didn’t use any SegWit addresses at that time. However, in mid-2020 the whole community transitioned to SegWit for the superior performance it offered, creating a new challenge: in order to vote, one would need a special address just for voting.

But by far the worst decision, and the one which undoubtedly doomed the voting system, was the requirement that 50% of all coins in existence must call for an election in order for one to trigger. At the beginning, the PKT community was very small and there were single individuals controlling significant parts of the coin supply. It seemed too risky to allow a change of Network Steward without overwhelming consensus that the current one was unfit. But as the community grew and the PKT coins became more and more distributed, what began as perhaps a prudent safety mechanism morphed into an insurmountable barrier.

In retrospect this should have been blatantly obvious, of course a fixed % of the coins would become more difficult to amass as the project matures. But hindsight is always 20:20; all bugs look stupid once you see them. What you don’t see is all of the bugs which didn’t occur.

As a result of these issues, nobody ever really engaged the voting system. None of the PKT GUI wallets integrated the voting capability, and people just didn’t take it seriously. There are at present 2 active vote transactions (one and two for those interested), both created by me for testing purposes.

The Network Steward Committee

While the voting system was not one of our best choices, the initial Network Steward committee most certainly was. The people chosen for the role continuously showed a level of moral character that can only be described as saintly. While most people only knew the Network Steward through their often disappointing messages on github, I can personally attest to the long and often harrowing discussions about what is the right thing to do.

When I think back to all of the people who have come and gone in the community, and all of the little dramas that have occurred, I dare not imagine what might have happened if the choice of Network Steward had been different. But the centrality of the Network Steward to the PKT project created another problem, which like the 50% rule, would manifest as the project grew.

We in the Network Steward became aware that if we were ever to fund a initiative which failed to produce a result, it would be impossible for us to prove that we hadn’t been bribed to accept it. The mere suspicion of this would cast a shadow over the Network Steward and thus the PKT project as a whole. So for us, it was not enough to do what we thought was right, we in fact could never make a mistake.

In the face of this reality, we were still surprisingly effective at allocating funds. The system we used was based on competitive grant-making where anyone could propose a project. Generally the only projects that were accepted had a specific and measurable technology outcome and were for the most part not paid until after delivery. Our entire history of decision making and all of the projects which we funded can be found in The Network Steward github repository.

As time went on, the we felt the need to adopt more rules and procedures to protect our reputation and the reputation of the PKT project we were tasked with supporting. But while each of these rules made sense in isolation, in aggregate they ended up dissuading the community from participating.

Just as jumping through the hoops became too much for the community, applying the rules became increasingly burdensome for the (all volunteer) Network Steward. The last call for projects was in February of 2022, and it is unlikely that there will be another one. However, a new Network Steward voting system is in development to give everybody a more direct voice in voting, I will be publishing about that soon.

The Network Steward is dead, long live the Network Steward!

Continued in part 2