good coin but seems to me slow blockchain((( I was waiting confirmation of 1 mined block for 24 and more hours((((
Good to see a new name appear on this thread.
Yes, the Parallelcoin network has a small but very widely varying hashrate due to opportunistic mining from pools, combined with its hard-limited simple diff adjustment that reacts only to the last 10 blocks *average interval*.
This regime leads to clusters of blocks coming 1-5 seconds apart in clumps of around 20-30, and then the miners switch away from the network until the remaining, far smaller constant hashrate baseline of faithful miners finally finds a block or two again, difficulty adjusts back down and the cycle repeats.
In fact, in the long term, this fluctuation is causing the difficulty to always stay above what it should be to hit the target, and the average block time has been slowly dilating over the last 4 years from 5 minutes to now at about 12.5 minutes.
How we are going to fix this:I have a mostly developed and tested new algorithm (9 different ones, to be exact) that uses a complex 4 part averaging scheme that tries to keep long term average flat and correct, both all-time and for 24 hours, and two exponential moving average based formulae that gently bend the hashrate towards target, and a weighting curve that should reduce the number of blocks under 1/4 of the target.
The test protocol has been running on a 9 second block time but after much deliberation I think I'm going to set the target to 36 seconds, which interestingly happens to mean 100 blocks per hour. I know for sure that there are chains that have proven down to around 30 seconds isn't *too* expensive in the form of high rates of chain splits, and 100 per hour is a nice round number. (days also can split into 100x 14 minutes 24 seconds, I discovered also the other day, but 100 blocks per hour sounds kinda cool).
To reduce excessively fast drops in difficulty, which can be an opportunity for coin-hopping big miners and pools, the difficulty adjustment is cubed on top of the 4 averagers only for downwards adjustments. Difficulty adjustment is not capped, so with the new regime when a 10x or greater rise in hashpower occurs, the difficulty is raised quite quickly, in tests so far about 10-20 blocks come in shorter and then another 10-20 a little slower and it stabilises again.
At 36 seconds the latency premium is relaxed quite a lot, but even so, the process of retargeting when a new block comes in has a fairly fixed time period, but inherently a pool has double the latency for changing work. CPUs have the lowest on/off switch cost (warm-up time) followed by GPUs followed by FPGA and ASIC.
Thus also in the mining controller/worker setup I have partially implemented, I will be balancing cost in several ways. I will be altering the default block template to try to divide the transactions more evenly over time, so that it issues new blocks that have a good chance of not being stale (specifically, having transactions that just made it into a block) so some of the workers continue while those whose work contained newly bundled transactions get new ones built and they sit idle, not using power, until the template is ready.
The multi-algorithm scheme will have a built-in trigger threshold that stops work based from a randomly generated nonce (hashing from a random point and incrementing nonce each time), grabs a new random starting point and picks a new algorithm. This selection/switching scheme can be tweaked by the user to either prefer the higher difficulty algorithm, the lower, or some balance between them. Targeting high difficulty would help smooth out block time fluctuations, targeting low difficulty has higher odds, but in both directions there is a dilemma. High target can less blocks overall, maybe, but during changes between high and low network hashrate, high target may mean longer time to get the first one but if the second highest is a lot lower, then the balance goes the other way. Likewise, low-targetting will advantage more those who already have lower latency to the network. Both directions are equivocal and all 9 different algorithms are 'more or less the same' except for their different per-algorithm interval (1/4 of the difficulty adustment regime).
Further, the mining controller will also account for the transaction-distributing pause-prevention strategy as well into its criteria for pushing new work to clients. The transaction sets divided amongst workers such that, assuming a common use (by default configuration) of this pattern, nodes run a surplus on transactions. So if there is 10 in the mempool, let's say, and a miner has 5 workers, 20% of the transactions are put into each worker's jobs (randomly, of course), and then, assuming most of the network accepts this default, when a new block comes in, around 50% of the workers are not mining transactions that are now settled, and don't have to wait for the dispatch, they can just roll over the previous block hash value in the header to the new chain tip and keep on hashing, no need to regenerate the transaction merkle since the transactions are not yet in blocks.
I think all of these features will make it into the final release. One of my core goals in this upgrade is exactly towards defanging the selfish/malicious miner vulnerabilities, as the diff adjustment of parallelcoin really demonstrates how to not do it.
In every practicable way I can, opportunities for parallelisation and optimisation in mining are reduced as much as possible, the lower initialisation overhead for a CPU compared to other types of hashing devices, an ultra-reliable streaming UDP that is intended to be used by miners located near a backbone running clusters of miners, and of course, as you will be able to see soon, when we begin beta testing, is an extremely approachable and easy to use application.
With luck, this new regime will end the poor network liveness (blocks should *never* be more than an hour apart!).
New reward scheduleAnother incentive for miners will be the new block reward scheme. Firstly, the absurdly primitive and not-modelling-anything-in-the-real-world halving scheme, on Duo being at 250,000 blocks (not even to first halvening yet, but it should have been), is being replaced.
Just to flesh out the rationale, it is generally understood in economics that the rate of supply over time has a strong influence over price. Sudden changes in supply rates cause shocks in markets, driving a mania or panic, and increasing volatility. Combined with a low overall liquidity, cryptocurrency markets have, in my opinion, 100% for certain, a driving oscillation in its long-term price cycle that is caused by halvenings.
Here is the data for the last 7 years or so regarding the growth of the global economy
https://www.statista.com/statistics/273951/growth-of-the-global-gross-domestic-product-gdp/Currency makes up 50% of all exchanges in the marketplace. If its supply is higher than the growth of goods to be priced in it, the prices will steadily rise, more difference more rise. Theoretically, money should be about par with the market. I think a figure around 9% is good. Many cryptocurrencies have higher rates than this, and you can see it in their little first-release burst and quickly the amount of supply is priced in as the baseline for the coin.
So, from hard fork, parallelcoin will target a 9% annual constant supply growth rate. The rate will be lower than now (current is around 18% or so), within 6 months it will have dropped to near half the per-day amount up for grabs, but this reduction of supply continues continuously, so nominally the reduction is always reducing. The rate is calculated on a per-block basis, with each subsequent height, multiplied by the previous reward, divided by the next block height, and calibrated to close to the 9% target based on total supply at hard fork block. But to keep things even and lengthen the time of bigger blocks, the reward curve will flattened for the first 6 months blending between the old supply rate and morphing gently into the new in 6 months time. This will be a relatively linear change to keep things fair and to reduce the supply shock from the regime change.
A second change is that the block maturity time will be changed. Currently it is at 100 blocks, or about 8-9 hours. The same period on the new schedule would be 800-900 blocks. But I think 1 day is too soon for miners to be allowed to spend their minings. A friend gave the idea of using delay of maturity as an incentive for miner loyalty. I of course extended it immediately to the idea of a year long maturation where the value depends on that formula and how many blocks since the block was mined.
I'm not sure if it would be practical to incorporate that directly into this upcoming release without further delaying things, but I will have a little look at it. The idea would be that instead of an abrupt block-wise boundary to determine when a coinbase can be spent, that instead the value of the coinbase starts at 1% of nominal spendable value, and let's say at 3 months it reaches the nominal rate, and if someone hodls for 12 months, their coin has double the face value.
It's my opinion that saving, critical to credit markets in a hard currency regime (no rubbery figures 'fractional reserve' counterfeiting loans). The idea would be that miners would then, in addition to mining, park their coins on offer for collateralised, low risk, short term margin lending, after letting them fester for 6-8 months (people will probably thus slightly expand the supply rate by doing this.
I'm not convinced about the idea just yet but I will say that the coin maturity will be set at 2400 blocks, at least (1 day). If in the time I am doing the rest of the work it is decided to try a maturity-based coinbase multiplier hodling incentive, I don't think it will be *that* difficult to add the feature, the most complex bit will be in revising the wallet balance periodically as the spend value of mined coins grows.
I think it can be said that time preference correlates fairly closely with honesty. Honest people tend to also consider timescales beyond their own life and days and be more comfortable with a reasonable unwinding regime such as I am proposing. The kinds of people who mine 50 different coins using cloud miners are often also chasing little blips in prices caused by listings and news that draw a crowd to a coin. These opportunistic miners form a very large, and sometimes maliciously manipulated mass that can and has attacked smaller coins.
But as I said, I'm still early in the process thinking about it so I'm very interested in other people's opinions. I have this idea of using a sigmoid curve on the maturation rate so that at one point it matches equal to 1:1 based on the supply rate target set (9%), around 3 months, I figured, and then the curve decelerates towards a full 2x amount. So I guess the first half of the curve has to accelerate, and then decelerate at the same proportion out to 12 months full maturation at potential 2x nominal value compared to ....
Well, you know, it feels all kinda shop-keepery talking about this kind of discount incentive deal, but they work very well in real life.
It's my intention that I'm at the front of the development for this project for 2-5 years, bearing that in mind, a hodling incentive value maturation, that hopefully we attract miners and speculators who want a token that has the potential to push forward fast.
In my opinion, the amazing potential of automated, network-enforced disbursment/savings procedures have barely even been touched. Crypto's 'sorry but you signed it' is more rigid and strict than any third party business can practically do. It's not even profitable, probably, unless the customers have huge balances. Well, there is term deposits, and they are strictly enforced and have high penalties. It used to be that these deposits were more influential over interest rates, and fiscally strict banks do try to keep their reserves high, but others go out and buy up ridiculous, sneaky derivatives products, and blow out their margins ridiculously. I remember reading during the peak of 2007 insanity some banks were leveraged over 300%, that is, they had 0.033% of the money of the amount they are 'lending'. And as most of you will know, that little scheme fell apart at a certain point.
I think if a cryptocurrency network could completely replace all personal banking services, and especially, a cryptocurrency that emphatically rewards *not* spending the currency, and is able to implement intermediary-less collateralised lending like margin lending, that the liquidity would provide a big advantage to holders of DUO. So I have things like this in mind when I talk about building a multi-ledger causal consistency network system, one of the things is an 'on-chain' full exchange order book and clearance procedure/consensus, another would be in the creation of very short term lending contracts, and built on that base, traders, then hedge fund, and finally, big ticket mortgage style long term lending based on it.
Like the existing money market, but without the guys at the top front running the market with loan approvals, and then swooping in and grabbing undervalued assets as the inflation boom flows in...
Anyway, much too much rambling, I guess I'm catching up... More code less jibber jabber
