So much of what the PKT project has been able to achieve has been thanks to the heroic efforts of such community members as Routie, PKT World, and PKT Watch.
PKT World has given us:
PKT Watch has contributed:
And Routie has supported:
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:
A Network Steward “project” is proposed and accepted with the existing Network Steward, the objective of this project is to fund the new one.
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.
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.
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!