Introduction

It has recently been brought to our attention that a masternode collateral change would be proposed to the community as a means to fix networking issues within the $PAC network. The main issue that was brought up was: fixing the ongoing chain forks seen on the network. The assumption is that the large quantity of nodes on the network is causing these forks because it has too much chatter between nodes and that it takes too much time for a block to propagate throughout the network, thus, creating forks. This paper wants to clarify the issues and spark the discussion on possible solutions as the community becomes more aware and knowledgable on the issues and proposed solutions. Other concerns have been raised and arguments have been formed directly or indirectly related to the collateral change. Some of such concerns are lowering the cost of running a masternode and the foreseeable scalability issues in a 3, 5 or even 10 years span, as more and more people reinvest and create masternodes, which could bring the network size in the tens or even hundreds of thousand nodes within those time span, potentially diminishing the performance of the network. So let's dig into the issues at hand and analyze the proposed collateral change solution and related concerns.

Costs of Servers

Costs of servers have been invoked in favor of increasing the collateral requirement for running a PAC masternode. As a collateral increase would bring down the total number of nodes on the network, this will effectively be reducing the costs of operation for masternode owners (MO). But how much of current server costs are really an issue for MO? Even at current lows seen in exchange rates, revenues per nodes per month are still over twice the costs in most cases, when the masternode is operated and maintained by it's owner. Doing a fundamental network change like that on the basis of costs, is, in my opinion, pulling away from the core issues at stake, like adoption rate, use case, increasing demand, coins velocity. Plus, this could potentially open the door to other issues that are non existent today (for instance, would the collateral be so high that the impact on liquidity becomes an issue?).

Focusing on the core issues and being successful at reaching our targets would naturally bring the value of PAC up and at the same time, reduce the effects of costs for MO.

On the other hand, at some point in time, the blockchain size and/or minimum CPU and MEMORY requirements to run a stable network might push the costs up as more and faster resources usually means higher price tag. At which point a collateral change might prove a viable solution, but so would database pruning or other code optimizations that would require less HDD space or computational power.

Also, even if Moore's Law tends to be at the end of it's curve, computer hardware still tend to be cheaper with time, or, at least, more performant for the same price level. Adding to the mix advances in technologies such as virtualization, it makes it possible to keep the costs relatively constant and get bigger HDD, faster CPU and more RAM for relatively constant price levels.

So this is not an attempt to ignore the real possibility that running a masternode would cost more at some point in future times, it's simply an attempt to put in perspective that for next 1-2 years, it's relatively safe to assume that hosting prices are not going to be much different than they are today and that costs of hosting is not the biggest threat/issue that we are facing now or within that time frame.

So why bring this issue up when there are bigger and more urgent matters to attend to?

Higher Exchange Rate

An argument often seen within the community and a conclusion that people naturally tend to make is that raising the required quantity of coins to operate a masternode (MN) would help raise the price PAC is traded at.

This conclusion is simply wrong and it becomes apparent once we analyze the situation. The biggest driver for any price movement is demand. Without it, there is no volume, no velocity, no movement.

So how would raising the collateral required to operate a masternode affect demand? Well that factor simply has no impact on demand. Demand is driven by five determinants. Price, income of buyers, prices of related goods/services, tastes of consumers and expectations¹.

So, collateral change might have a short, positive, impact on expectations, but it would also have a negative impact on the income of buyers determinant, as people would have to pay more for acquiring a masternode but their income would likely remain the same. So new investors wouldn't have more available budget to put into the project, yet we would be asking for more.

Plus having a steady and relatively fast inflation rate (read supply) hardcoded into the Paccoin network parameters, without an increasing, or to a minimun constant, demand, it's simply normal to see the price fall as supply is higher than demand. Since a higher collateral doesn't affect the supply, the trend would remain the same either ways.

I'll try to illustrate that with a simple mathematical example.

Let's say current daily Bitcoin volume for PAC is 10BTC and the exchange rate is 10 satoshis. At those levels, 100,000,000 PAC are traded each day. That 10BTC is what people are willing to pay, be it 1 individual or a group of many people. You could also view that as the risk level, this individual, or group, is willing to take.

We get those numbers by dividing BTC volume by PAC price: 10 (BTC/day) / 0,00000010 (PAC/BTC) = 100,000,000 PAC/day

Now, assuming that all daily traded PAC is turned into masternodes then at 500,000 PAC / MN we get 200 new MN each day. If the collateral required is now 1,000,000 PAC / MN, then we now get 100 new MN each day, and so on.

But nothing as influenced the total daily PAC volume, which remains the same at 100 MM PAC or 10BTC. We would just see less MN created each day, but no higher prices. This is directly linked to the fact that a collateral change doesn't affect the inflation rate (supply). So if supply and demand remains the same, price trends also remains the same.

But higher collateral means people would need to buy more to operate a MN, effectively raising daily traded volume, no? The simple answer is no, it won't.

Higher collateral means we ask for new investors to take a higher risk investing in the project. This is analogous to the traditional banking system. If you ask for a loan and you have a risky borrower profile, banks are going to ask for more collateral before they lend you money. So, when we put this into perspective, asking for more collateral is like saying the project is more risky than it used to be. We impose on new investors to put more of their money upfront ( negatively affecting their buying power ) and all that without giving them much more in return, and I'm not talking more $PAC/month, I'm talking about more value driving expectations, since everything else within the project remains the same. It becomes clear that higher risk signals won't translate into higher demand.

In fact, raising collateral might even have the opposite effect as it was seen from other crypto projects^{2 | 3} that have raised their MN collateral, just to see their price plummet further down, even if, in some cases, they enjoyed a brief price appreciation. To be fair, a higher collateral when combined with a well executed plan to roll out better use cases, could make the price rise. But the price rise would not be directly related to the collateral change, it would be linked to the increased demand influenced by higher perceived value that comes from better use cases.

So collateral requirements have no direct correlation with demand. And without a proper strategic development plan in place, the collateral change could have either no influence or an inverse relation with price.

PAC, as a community, should focus on value rather than price, which are often related to one another, but not always in perfect sync. So creating value should be the top priority, and when value is constantly added to the project, price should follow positively as the value created is perceived as steadily increasing over time.

Less Dumping With Higher Collateral Requirements?

People might think that having higher collateral requirements would mean that people would be less likely to sell. If we use the same basis that collateral and demand are not correlated, then it's unlikely that we would see less sell pressure with a collateral change. Assuming that people need to sell 10 BTC worth of PAC each day to pay for various things (hosting costs, mining costs, income taxes or simply taking profits) then, the same level of volume should be observed on the markets, regardless of the collateral requirements.

Again this is because neither supply or demand is affected by collateral requirements.

Taking our previous example of volume and price, it would still be 100MM PAC traded each day, either way. The people's need to exchange 100MM PAC / day to pay for various things shouldn't be affected by the collateral requirement.

Masternode Investment Rate

A metric that is directly related to the quantity of masternodes (MN) on the PAC network is the investment rate of newly created coins. The numbers will vary depending on how many nodes your wallets sees on the network when you make the calculation, but it is around the 60% mark at the time of writing this. Points have been made that if the investment rate stays the same, in a year from now, we could see as much as 12,800 MN on the network.

That is 576 blocks/day * 18400 coins/block * 365 days * 60% + 8200 current MN if the collateral stays at 500,000 PAC/MN. It's a 4600 MN increase per year. I agree that within 5 years, that number becomes pretty insane and would be more than is necessary to operate a strong, reliable and stable network.

But why I find this to be a non issue, at least at this stage of the coin's growth, is because it is assumed that the investment rate would remain constant at 60%. But that rate would tend to get lower as more adoption and use cases are seen for Paccoin.

Raising the collateral won't push people to invest/reinvest more or less. Current masternode owners (MO) would likely reinvest at the same rate regardless of how much collateral is required. Utility and usability, beside running a masternode, is what would change the rate of investment.

I'd like to propose here that we use the investment rate ( coins locked in MN / total supply ) combined with the daily number of network transactions and the daily traded volume as a gauge of performance of the success of PAC. If the MN investment rate goes down and daily transactions and volume goes up, then it would mean that PAC is fulfilling it's goal to become a transactional coin. If the reinvestment rate stays the same or goes up, and volume and transactions remains constant or plummet, then we have much deeper issues then the size of the network in my opinion. As a high reinvestment rate is a symptom of lack of usability for the coin.

In other words, the high reinvestment rate is a symptom of a much deeper root cause, rather than the cause itself. Fixing the root cause is known to fix the symptoms and is the way to go if we want to build a strong, great and lasting product.

So while lowering the investment rate should be among the long term objectives for PAC, it's currently, at this early stage of development, a natural phenomenon and not that big of an issue.

I believe that giving more use cases to the coin, should, incentivize people to spend more than they invest, naturally bringing down the number of nodes on the network and, by the same means, organically fixing the "over sized network" issue.

Blockchain Forks: Is Block Propagation The Issue?

At first, I assumed that block propagation wasn't heavily affected by network size. Or more precisely, I thought that the effect of network size was negligible on the block propagation. I was somewhat right, but that depends on what you consider negligible. So I had to dig into the way blocks propagate on a blockchain network and also to find statistics to get a better sense of the picture.

Let's start by stating that blockchains forks will happen. That is inevitable as the reality of network latencies makes it that way. Unless a fundamental change is made in the way blockchain technology operates, this is going to be a reality for the foreseeable future. In the paper Information Propagation in the Bitcoin Network, an analysis of actual forks on the Bitcoin network was made and the relation between network size, block size, quantity of transactions and block times are clearly explained. This makes it easier to transpose the concept to the Paccoin network as the technology is mostly the same at that level.

In a nutshell, the bigger the network, the longer it takes for a block to reach everyone, that makes sense. Also, the bigger a block is in size, the longer it will also take to reach everyone, which also makes sense (10MB takes more time than 1MB to travel across networks). Another key element that affects the probability of having a blockchain fork is the wasted computational time, which is the time spent by some miners on mining a block that was already found by other miners, but have not been made aware of yet. This happens because of the delay between the time the found block was broadcasted to the network and the time the distant miner receives the message so it can start mining the next block instead of keeping mining the already found one.

This is the equation that gives us the probability of getting a fork:

The is the probability of finding a block. For Bitcoin, that probability is 1/600, since the network is set to find a block every 600 seconds on average ( 10 minutes ). For the Paccoin network, that would be 1/150 since the network is set to find a block once every 2 and a half minutes. The part of the equation would be the wasted time the network spends on mining the wrong chain because it's not aware that the chain as advanced yet, due to the time of propagation (caused by network size, network latencies and other hardware limitations). That number would tend to be higher the bigger the network gets. For the Bitcoin network, at the time of the experiment, that number was found to be 11.37 seconds

I do not have the actual number of wasted time for the Paccoin network, but for the purpose of understanding the issue, the actual number is not required. Once we plug the Bitcoin's values into the formula we get:

Where 633.68 is the actual time between blocks measured in the sample used for the experiment, it was longer than the 600 seconds target, most likely due to a decrease in hashing power during that period.

So calculating the actual probability, we get about 1.78% chance of having a fork on the network.

Now, how is this relevant to the Paccoin issue? Well, we don't have the actual wasted time as I said, so the percentage of probability we get a chain fork will be wrong, but we can use that same logic to understand how a change in block timing and network size would affect the probability of chain forks.

So I'll use the same 11.37 seconds of wasted time and plug our 150 seconds target time in the formula.

Then we get about 7.29 % probability of having a fork. Without being accurate, we still see that having a block time of 4.22 times faster than bitcoin, we get about 4.1 times more chances to get a chain fork on Paccoin's network.

Now that probability just sky rockets when we are facing fast blocks of 10-20 seconds intervals. So if I replace the 150 seconds target time by 20 seconds that probability becomes about 44 % chances to get a blockchain fork. Which correlates to what we have been experiencing lately on the network. Lots of forks.

Now let's examine the influence of larger a network by increasing the wasted time. Just for illustration purposes, I'll double the 11.37 to 22.74 and I remind you that this is by no means the real values experienced on the Paccoin network.

So the probability of a fork, when we double the wasted time and keep the target time at 150 seconds, becomes about 14.11%. Which is about twice as much (1.94x). By the inverse logic, cutting in half the wasted time would cut in half the probability of getting a fork.

So what have we figured out here? Well, we now know that more wasted time and faster blocks increase the chances of a blockchain fork on the network. Inversely, reducing wasted time and longer blocks reduce the chances of blockchain forks.

So what's the takeaway then? Well, if we raise the collateral, then we effectively reduce the number of nodes on the network, thus reducing the wasted time spent mining and reducing the chances of forks.

But, what we don't fix by raising the collateral is the irregular mining interval and extremely fast blocks. Referring to the example of 20 seconds blocks vs 150 seconds blocks, the increase in probability of experiencing network forks goes up as much as 604%. Even if we cut in half the network size, we would get at best a 50% decrease in the probability of network forks, and I say at best, because propagation time is not only affected by network size, but also by hardware and Internet link performances. So it becomes clear that tackling the mining issue would yield better results than focusing on the network size.

The paper Information Propagation in the Bitcoin Network also proposes ways to minimize blocks propagation times such as minimizing verification, pipelining block propagation and connectivity increase. While we should be exploring ways to minimize the block propagation time, we should keep in mind that the propagation time is one factor having little influence in the mining issues currently experienced on the Paccoin network.

Size of Network

So continuing in the same frame of mind, how big is just too big? Is the actual number of nodes a real problem?

Well the actual number is hard to define, but as a comparison, the Bitcoin network has over 9400 full nodes within it's network at the time of writing this⁴. Apart from the services that masternodes render to the network (instasend, private send, etc.), Bitcoin full nodes and masternodes support the network in a very similar way.

They both keep a full copy of the blockchain locally, they both strengthen the network by providing numerous access point for clients to connect to and no single point of failure, they both relay transactions on the network, they both propagate the blocks found by the miners, they both don't generate new blocks but rather validate the ones created from miners.

Yet, Bitcoin, with a larger network than PAC (which had over 7600 enabled masternodes at the time of writing this), doesn't experience the same blockchain forks issues encountered on the PAC network. The orphaned block rate is much lower on the BTC network then it is on the PAC network⁵

So without going over the logic behind the probability of blockchain forks, as we just went over it in the previous section, we know one factor influencing the lower Bitcoin forks rate is their target time of 600 seconds compared to 150 seconds for PAC. Plus their huge hash rate makes it more difficult for one large pool to simply insta mine a bunch of blocks, as it currently is the case within the PAC network.

Another fact that I want to bring forward is that the Bitcoin network has more nodes than the Paccoin network (about 12% more), yet, it doesn't experience the issues PAC is experiencing. Which leads me to conclude that the current number of masternodes on the Paccoin network is not an issue.

So all this to point out that a collateral change won't have much effect on the issue of blockchain forks and that the current PAC network size is far from being the cause of the issues we currently see on the network.

In the future, maybe 2 to 3 years from now, if PAC fails to be mass adopted and that the reinvestment rate doesn't go down, then maybe the network size would become a more pressing issue. And then, a change in the collateral required to run a masternode would become a consideration.

But in my opinion we are far out from that scenario and if we do achieve a more mainstream use case, I believe the natural orders of things would push masternode owners to sell part of their investment at a much higher rate then we see today, effectively reducing the number of active masternodes on the network. If that is the case, then the network size issue might never be something we have to deal with.

It seems a waste of time and energy to try and fix that now, since other factors, such as adoption rate, would naturally temper with the size of the network and that a collateral change don't seem to have a major impact on the root cause of the problem at hand.

Too Much Chatter On The Network

I've seen in the chat room people using the term chatter as the cause for delays of block propagation. I don't believe this to be accurate, and without going over what has been discussed in previous sections, let's clarify this assumption.

Chatter would imply that having more nodes would add noise on the network. That is where the term sends a misleading signal. Adding more nodes would add some sort of delay to block propagation, like extensively explained in a previous section, but it's not chatter that's causing orphaned blocks.

In the current state of the network propagation algorithm, a block propagates to the network in n hops, and would reach all the network in about 13-15 hops as the propagation speed fallows an exponential curve of 2ⁿ. So 2¹³ = 8192 which is about the current number of nodes on the network, at 14-15 hops, every nodes should have received the newly created block message.⁶

So how much time does it take to reach all the network? On February 1^st 2018, DNS Bitcoin Monitoring tested the speed of propagation of an arbitrary chosen block on the bitcoin network and it took 5 seconds for the block to propagate to just under 9000 nodes.

That same test shows that it took 1.5 seconds to reach under 8200 nodes and 750 ms to reach under 6800 nodes.

Now, improvements can definitely be made under that area of the blockchain technology. And it does seem that it takes about twice the time to reach the last 800 nodes than it took to reach the first 8200 ones. Decreasing performance can clearly be seen as more nodes need to be reached.

But the topology of the Bitcoin network is somewhat different then the one of the Paccoin network, as they don't have the masternode network layer. So this could influence the results by a lot if the same test was done on the Paccoin network, as the poor performance of those last 800 nodes could be attributed to less performant hardware or slower Internet links located in remote location of the world. Which, for PAC, shouldn't be an issue as most of it's network is located within datacenters with strong backbone connected to the Internet and server grade hardware.

Another major point that needs to be brought to your attention is that the mining layer and the masternode layer are two separate things. And masternodes don't cause forks, as they do not mine blocks. So reducing the masternode network size, while maybe improving propagation time, won't help those miners nodes connected to the network and who are at the center of the blockchain forks issue.

In other words, the miner nodes would still be located on the same servers, in the same location of the world and with the same Internet connectivity, if we assume that the same people would be mining before and after the collateral change. So if an insta-mine-pool generates blocks too quickly for those other miner's nodes to be notified in time, a network reduction won't necessarily have the expected effect as those miner nodes could still potentially be the lasts notified, hence still creating the forks we are trying to avoid. So chatter is not the issue, and is the wrong term to be using in this context.

Mining Issues: Irregular Blocks

The biggest threat Paccoin faces concerning network forks issues is the irregularity in network blocks. This is mainly due to the known practice of large mining pools rapidly changing their miners from one network to another while monitoring the difficulty changes.

For those unfamiliar with the issue, these pools manage a lot of miners, thus a lot of hashing power, and what they do is monitor the difficulty of a number of different blockchain network running a specific hashing algorithm. For the PAC network, this proof-of-work (PoW) hashing algorithm is called X11, which is the same as a few other network, (Dash, for instance, also use X11 as their hashing algorithm). So when these pools send a big number of hashing power towards a given network with low difficulty, then they rapidly find a bunch of blocks within a few seconds of interval between each block. The network's algorithm then tries to adjust the difficulty to keep the network's block generation within the given parameters. For PAC, the target is set to one block every 150 seconds. So when the network as adjusted it's difficulty to bring back block generation within the target range, these pools pull off their miners and point them to another X11 network, leaving the current network they were mining with insufficient hashing power for the newly increased difficulty. This leads to long blocks of over 30, 40, 60 and even 90 minutes apart. Seeing that no blocks have been generated in a long interval, the network will bring down the difficulty (sometimes more than necessary to enable catch up) to catch up to the targeted interval. That will start a new cycle for those mining pools that will now see a very low difficulty on a network they left earlier, which now makes sense for them to send back a large amount of hashing power to scoop up a few blocks in a short amount of time.

This is the real issue at hand, because it greatly affects the probability of finding a new block and will cause a high risk of network forks.

Even if it took 10 seconds or even as much as 20 second for a new block to reach all of the network, it would still be way under the target block time of 150 seconds. So a long propagation time for one block ahead is not a big issue and is something that can (and will) happen due to the luck component of mining. Normally, that one fast block would have enough time to propagate before the next block is created if luck was the reason it got generated fast. But if the quick chain is now 5, 10 or even 15 blocks ahead, the issue is more problematic because of the weight the longer chains carries and the short amount of time it took to be generated wasn't long enough to notify all of the network.

So it's not as much the large network, that is as the center of the issue, then it's those rapid blocks mined by one or few pools, with massive hash rates, while other miners (and note that I'm not saying masternodes) are having difficulty to catch up.

When we look at it this way, it's becoming apparent that the problem lies within the lack of mining stability and not as much as in the size of the network. The size, while playing a role in network latency, is not the root cause of the issue at stake.

In this regard, maybe a different approach to mining that is more sustainable, predictable and less energy intensive should be explored and implemented before thinking of forcing a node count reduction on the network.

Diminishing The Inflation Rate

One effective way to stabilize the price, and masternode creation would be to lower the inflation rate. I must admit that while this would be an effective way to control price fluctuation, after analyzing the average inflation rate over the 25 years period of coin creation, which stands at about 4%, I find the rate to be slightly high but also somewhat reasonable.

It is not an excessive rate but I still believe a lower inflation rate would create a more stable economy over time. If by period 3 of the block reward table found in the PAC whitepaper, we would cut in half the reward and extend by double the time period of coin generation, we would be seeing an average inflation rate of 2.1% over the period, still generate 100 billion coins and still reward masternode owners with a healthy 26% to 39% ROI, while masternode count is between 8000 and 12000 nodes and that 65% of the block reward still goes to masternode owners.

This would bring the 25 years of coin creation to 48 years instead.

There is still about 10 months until phase 3 of the block reward schedule, so there is plenty of time to further debate this point within the community.

Conclusion

Overall, I'm not in favor of a collateral change, at least not for the time being. With this (rather long) paper, I wanted to set a few facts straight and explore the real issues at hand in a way that would be easy for community members to refer to and debate on. Instead of having the same points debated over and over as conversations get lost on Discord, having this piece here and a way to comment on it makes it more efficient to manage and to direct people here to follow and contribute to the debate.

I believe a collateral increase, at this point, would negativaly impact smaller investors as this change would have a bigger effect on them then on the larger investors who own multiple masternodes. Plus, it would also negatively impact prospect investors that think about getting on board with PAC as it would require for them to invest much more than they would normally have to with the current collateral requirements.

I also wanted to point out that the network size, mining issues and market price are not related to a collateral change in the way people might assume at first.

I've also tried to do some more digging, so it's not just my personal opinion based on assumptions, but my opinions formed from facts that were researched. If some of those facts are wrong or misinterpreted, than by all means voice your concerns in the comments and enrich the community with more accurate facts.

In any way, I believe this would bring better and stronger decisions that would translate in a better and stronger project that PAC is slowly becoming.

And finally, I wish that we take, as a community, the existing issues as opportunities to propose innovative solutions on block generation, multiple tiered network and algorithm improvements for instance, rather than focus on short term fixes that cost time and ressources and don't properly address the root cause of those issues.

1. Five Determinants of Demand with Examples and Formula - https://www.thebalance.com/five-determinants-of-demand-with-examples-and-formula-3305706
2. Collateral change - http://www.bifrostcoin.io/wallet-masternode-upgrade/
3. Collateral change - https://github.com/anonymousbitcoin/anon/commit/c39e6acfaecc52eb6e8ec1350a67f9f8490bce82
4. Bitnodes - https://bitnodes.earn.com/
5. Bitcoin orphaned blocks - https://www.blockchain.com/btc/orphaned-blocks
6. Block Propagation, Scaling and Adoption — Maturing Blockchains - https://medium.com/coinmonks/block-propagation-scaling-and-adoption-maturing-blockchains-99218260b7b8