Regarding the logo, we are sticking to the one created by our hungarian friend who designed it, it's very nice, and most people agree. We will be petitioning the artist who created the Go Gopher (and Plan 9 rabbit) to design us something in the future but unless a very talented artist shows up and we can pay them that's that for now. However side projects will get their own design. That gopher is just a rough concept melding the current logo and the gopher together but we will reserve such changes for the future when we can afford such luxuries as nitpicking over a graphic design. Protocol and utility and elegant, smooth GUI interface is our focus right now.

No coin using scrypt and sha256d can possibly get anywhere with the hostile mining environment. It's not possible, also, to downregulate difficulty without a new block being found as such behaviour cannot become a consensus.

The new difficulty regime currently has a distance of interval ratio between the shortest and longest interval currently of about 20. I have been thinking it needs to be made wider, currently I have derived the prime number based intervals using a simple algorithm that I can compute from a prime number table, a much longer one could have some interesting uses, and create a wide range of reward schedules depending on the amount of hashpower a miner has. I believe I have already coded in a bias that lets you set a threshold level and above or below as desired in the miner configuration.

Regarding the mining algorithm, nothing is more democratic than a CPU algorithm. This one should indefinitely resist attempts to make it faster. Its bottleneck process is very large integer long division, which is a mathematical process that has not been significantly improved in cycles-per-bit to calculate in ever. Intel famously tried to make a faster long division unit and created a nasty bug as their tables were wrong and the implementation, baked into silicon, could not be fixed once minted. The only way to dominate the post Hard Fork DUO will be to buy a shitload of computers, and though the caches of most CPUs could swallow the size of the eventual numbers the proof requires, I'm not aware of any motherboard that runs without memory installed. This may change but it's the smaller part of the cost anyway so the effect will be minimal. I correct myself, it can't be done without remaking the CPU, as all modern CPUs integrate their memory controller. So even, you have to buy at least a gigabyte of memory, even though your miner will never use it.

More complex scripting patterns can actually already be written, if you have the inclination to do so, but they have to depend on block heights not on timestamps, as it is timestamps are only checked to be within an hour or two of the consensus, and are set in stone once the block is mined on (6, of course, probabilistic finality).

You may be familiar with similar time-based systems as used in the Graphene chains, that is because they are Proof of Stake and 1 block basically is 3 seconds so you still are counting block numbers, they use it to great effect, and there's no reason it can't be done on a nakamoto consensus chain, with that constraint. Again, this can be done with scripting. The new chain does no changes to the script engine aside from switching it after the fork to Schnorr signatures (saving time in validation and space for multiple inputs) so any scripts you may know of used with any other bitcoin fork can be equally implemented. If you wanted such a new transaction type to be on the chain it is just a matter of formalising the script template and putting up an issue on the github, we would be happy to implement such things in the wallet especially if it is rather clever, useful, most importantly, useful, or popular (and practical at the same time). I'm a big fan of 'savings and disbursement' regimes like the power up/power down of Steem, that is a script I would be keen to see integrated into the chain in the future, besides that, I am adding Cosmos Inter Block Chain (IBC) protocol capability to the chain, to at least validate signatures, so later on we can roll out Tendermint/Cosmos SDK based sidechains for specific application types. These have far more flexibility than the Satoshi - designed scripting language, and run faster than Ethereum so don't forget that's on our roadmap once we roll out the hard fork and get some funding to continue work (even if that is just by you all buying every DUO you can get your hands on and increasing the value of our holdings).

He is still alive, and let the little black kitten into the office, who immediately went kinda spastic wanting pats. I am feeling blessed this last day. I am optimistic about the future.

Just a brief update, since I think it is good to give people an idea of progress and always a good plan to bump with a meaningful update on these threads to keep them visible.

I have almost finished the update to the parallel-prime difficulty regime update. The most persistent bug I have dealt with so far has been related to the block template generator, which of course in the much maligned `btcd` from which we are building, has not been used by many of the ... ahem... bitcoin core users - and for good reason since it's slow as molasses at synchronising.

Well, the block clearance rate during sync now averages around 800tx/s peaking at 2000tx/s which I think is related to the network limit, I am pretty sure this is well above what BTCD achieves and is not far from par with bitcoin core. I already fixed this issue, it was mainly caused by c++ programmers (my surmise) ignorant of the light weight and utility of Go's inbuilt concurrency systems, and far too expansive delineation of critical sections. At least one minor bug has been reduced that I am sure was caused by synchronisation with the production of block templates for miners.

We here at Plan 9 Crypto (ie me and @marcetin) have been contending with various kinds of parasites due to my unfortunate exile from serbia and exile from even a computer I could code on, last I saw him he was in a foetal position with a really nasty 39`C fever and I hope he comes out of it soon. I had the fever also a couple of days before and this morning I woke relatively feeling better. No, it's not coronavirus. Plain old Rhinovirus, aka common cold. What he has may be something more, some sort of stomach or throat or sinus bacterial infection causing the fever, but I am confident he will recover soon and I will be able to update.

He has now constructed most of an RPC console that will be used in the final GUI and we are finally adopting the use of github's issues and project management tools, which you can see here: https://github.com/p9c/pod/projects/1

Things are pretty intense for us at the moment. We have nearly no funds and the devil's whip has never felt closer at our backs in our lives. So rest assured, we are aiming to hit a target of beta release by the end of february, we are gonna do our derndest to reach it.

We will be updating more regularly now that the final destination is looming. No, not that Final Destination, dammit!

I'm back! I got a bit of a chill when I first came back due to needing to wash and the weather was like 15`C and then back down to 10`C so I am a bit slow and headachey at the moment, but I have a series of minor adjustments. I published them on the facebook page for parallelcoin, here it is:

------

ParallelCoin
Published by Loki Verloren · February 1 at 3:10 PM ·
Our lead developer, Loki, is imminently returning to work.

Among the news for the project, the GUI is now in early prototyping, the primary developer being Djordje, and confirmed to build on Windows, Mac, Linux and FreeBSD, with confirmation of such coming soon for Android and iOS. In the plan is to form the beginnings of a truly cross platform GUI framework, built on the principles of pure Functional and Concurrent programming paradigms.

While in hiatus, Loki has not been idle and has several planned changes to the post Plan 9 hard fork consensus:

First being a novel multi-interval parallel block timing and reward scheme that uses prime number based dithering in order to produce a more regular clearance pattern;

Secondly all transaction signattures after the fork will be Schnorr signatures, that produce a consistent 64 bit size for every transaction no matter how many inputs are involved;

Third is the use of Blake2b hashes for all post hard fork block hashes, which have a very fast processing time (blake did not win the SHA3 standard - the less prettily named keccak won but it is slower and about equally secure from collisions)

Last is the integration of the required recognition and validation required to become Cosmos IBC compatible, in preparation for and to avoid a second fork to attaching a Tendermint Protocol sidechain, which will provide 3-5 second clearance time and a throughput capacity that will not be so dwarfed by interbank and international payment clearinghouses, and enabling further integration with the rapidly growing Cosmos internet of blockchains.

This is the minimum target and paves the way for future deployment and readies Parallelcoin to ascend the ladder of market capitalisation and transaction volume.

We should be starting beta testing in early March with all these features in operation, and have hard fork height set in stone by May.

-----

I am starting to work on the first thing in my part of the work now, just getting comfortable and recovering from my exile from Serbia, making a more precise specification. It's essentially going to be somewhat a return to the origins of Parallelcoin's difficulty regime in that there will now be 9 different algorithms, but they all run at a different timing, specifically:

9, 15, 33, 51, 123, 177, 201, 249

This is, first, take the first 9 primes, then select the primes indicated by each of these first 9 primes, then multiplied by 3 (as 3 seconds is unreasonably short)

This creates an intentionally non-repeating pattern which I estimate will take about 39,000 years to repeat. My hypothesis is that since finding blocks is random, a randomised timing pattern will yield a more regular pattern of blocks. Chaos is fickle like that, when you do things randomly you can leverage capabilities that are otherwise impossible, and you can stretch the bounds of probability. Besides all that, everyone would be familiar with the concept of 'Dithering', used to increase the precision of a mathematical system by adding noise to it.

The new scheme is considerably simpler than the old one, which was pretty nice already, but it should produce a more even clearance time and be resistant to any of the known ways to perform a timewarp attack, since to do so you have to craft your mining output to fit with nasty indivisible prime numbers that have a very long period of repetition, the same thing will work at one time but maybe even 10 seconds later conditions will not be ideal.

The other things I am doing are about improving performance. I have been interacting with the upstream btcd repository relating to the initial sync process and improving the throughput. In the last couple of months of my work before I had to stop at the end of november, I already improved the transaction clearance rate to around an average of 800tx/s for validation, peaking around 2000, and this is quite improved compared to the reference implementation. The post-hard fork chain will use Schnorr signatures which are faster to compute and allow you to create multiple signatures all within the same 64 byte signature size, no matter how many inputs (probably there is some practical limit but beyond what would be typical, in the hundreds or thousands of inputs.

I am not yet aware of any attempts to implement Cosmos IBC on a non-Tendermint chain, so this last task is probably the most challenging. However, the purpose of making Parallelcoin IBC enabled is that without a hard fork, we can roll out new tendermint based sidechains, for fast transactions, for other types of data transactions (IPFS, onion routing), and for that latter other type, implementing sidechains running Mimblewimble privacy protecting transaction mixing based on new technologies related to cryptographic recognition filters.

I will go back to my work now, I am just getting back to being comfortable and back in the programming mindset, circumstances literally stopped me from doing any significant amount of code, laptops died, phones had several functions fail... it has been a really difficult time for me. But I am confident I can roll out all these features and be in beta testing soon, and @marcetin is now significantly progressing towards having a usable GUI interface for users.

I have not been active here much except related to my former work on Parallelcoin. The project hit some severe funding issues, and as a result of the consequent immigration compliance issues I am now looking for something else to get working on.

I realise probably I may be stepping on some forum rules in making such a post, of course I will redact this post if so.

If anyone is looking for someone to write back-end, protocols, libraries, and suchlike, specifically in Go, and I am familiar with such as Tendermint/Cosmos SDK and distributed systems in general, and values the benefits of concurrency in the systems level, I have written many concurrent handlers, codecs and data analysis code in the Parallelcoin pod suite.

I am available for contact via messenger, skype and email, and I am willing to work on an internship basis if necessary immigration costs are settled. I have a Schengen passport and so any project in the EU this is no issue.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Here are the crypto addresses to donate to support the completion and release of the new wallet and server with hard fork... See the github at https://github.com/p9c/pod

btc segwit address: bc1q2nxsp5ytx32pes4x52ap8e2hkymf6sqrzpulpp
btc legacy (p2pkh): 1L1YowKjicbj9BUmjJn7vNQyb5rda7Eymc
bch (bitcoin cash): qqmtpm6wh527rx7as075xuep065kz3wpkq960yj27w
xlm (stellar lumens): GBWSGZVHJFSCNYZPSCWWXF3SFDLWTRAYKATFZX2FDSZDTXIKYCWA4FMZ
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSJkSa7RckFbMM89pocmzTvOpJBnQUCXfOSUQAKCRAcmzTvOpJB
ndlCAQCwJXLOuMxhbvfVXI9tTpjQavpvSAR6taue2Hukc+uB9gD/a2hvXtpeqjIJ
N/15r888t1Z/v8zmfo/ecKatf1VFrwM=
=Qv3U
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I am currently in a situation where I cannot significantly advance the progress of the main project, its github is now at https://github.com/p9c/pod

I am the main developer of the new codebase there.

It includes:

- - a new proof of work based on very large integer long division (with numbers in excess of 4kb in size) has 9 different finalising hash functions, and should be the first truly ASIC resistant proof of work protocol ever written to date.

- - a new difficulty adjustment regime that corrects the lack of relationship between the SHA256D and Scrypt hash version blocks, instead there is 9, and it uses daily/hourly/quarter-hourly, per-algorithm and all-time average block time with exponential moving averages and is very resistant to more than about 10 blocks of fast mining, if anyone can even assemble such a mass of Long Division processing hardware that it is as hugely out of scale with the average user's hashpower.

- - a new IPv4 multicast based, fully parallel mining controller and worker system I call 'kopach' (slavic word for miner), it uses a pre-shared key to prevent snooping and interfering with the operation of the protocol, and has automatic failover so you can run two or more full nodes with controller enabled, and if one or others of the controllers fail for some reason, within seconds all clients of the offline node can switch to taking work from the remaining functional nodes.

The GUI is currently still a work in progress but is pure Go apart from the GLFW library which targets opengl on desktop and GLES on mobile devices.

I am currently, literally stuck on the streets of Amsterdam, a place I am familiar with and have access to sufficient services to stay alive and healthy, but it will be difficult, nigh impossible for me to coordinate the necessary beta test which is only a short distance from where the project is currently at. I have to make small minor changes to reach beta target, maybe a few days work, but then I need better hardware and regular, all-day access to a computer so I can work with the volunteers/contributors on the beta.

It is my intention that the first round of closed beta testers who we accept and complete to the end of the process will be entitled to a disbursement of DUO that activates when the hard fork kicks in and the new protocols take over (and forks to a new chain, essentially).

But right at the moment I need help.

Due to poor advice relating to immigration, work visas and taxation and corporate registration rules, and the fleecing of @marcetin by scammers associated with RoboForex, funding is nonexistent... I was working exclusively in his office with my PC up to now, but due to being 2 days late paying the taxes, I was exiled from Serbia by the Vojvodina judiciary. It has, as it is, cost us over 2000 euros in taxes to cover 2 years back taxes plus penalties, and I cannot return to Serbia until 2nd of February.

What would resolve the problem is about maybe 300-400 euros, which would cover most of my costs to set up temporarily set me up in some place like Tilok or Sharengrad, near the Backa Palanka border crossing into Croatia, to keep working until I can go back to Novi Sad. This would include my transport costs. I set up in Serbia because of the lower living costs and I have been working entirely as an intern, in 15 months I handled maybe 300 euros total.

I am open to in-kind contributions instead, and of course if interested I would be happy to spend some of my time teaching the donor something they want to know about cryptocurrency programming, Go and distributed systems in general.

I hope someone wants to help. The project is currently basically me, @trax0r and @marcetin. There are (were) others present in the old Discord chatroom, but nobody other than those two have contributed anything of their own resources, and even worse, asking really stupid questions like somehow we are the operators of Cryptopia or Yobit and that we have any influence, especially now before the hard fork is released, over what others have done in relation to the horrible series of events that has been Parallelcoin's recent history.

Loki
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSJkSa7RckFbMM89pocmzTvOpJBnQUCXfORowAKCRAcmzTvOpJB
nYhIAP4tHMHvO/LI378st88T4NqwoG8NtvcWXw8Wk+kXDdpiDAEA9g2QpcxNIc7m
41h8jYLGWUvbatnPWyULWespPW6X4Qo=
=h9Yd
-----END PGP SIGNATURE-----

I object to Grant Thornton not distributing the DUO back to the rightful holders. Do you think lawyers are not going to just dump them on the market and line their pockets? None of the DUO disappeared in the hack, it's just that NOBODY will get a peep out of judgey-poo who isn't in the lawyer club. But I have to say that it looks like virtually nobody is interested in making a claim anyway.

I personally don't support blacklisting yobit, i think everyone knows well enough by now they likely won't upgrade and will try to rip off the users with it in their accounts, which is the justification for doing that.

The thing with cryptopia is that I'm pretty sure NZ cops seized everything and cryptopia never had the option to distribute unaffected tokens back to users. Then some assholes who were supposed to be keeping a backup ransomed the user list.

The situation is extreme. We have the ability to block them and for the holders of DUO, not having 118,000 duo get dumped on the market unceremoniously would be a good thing.

I don't think yobit really presents that much of a threat. I am writing blocklist code anyway for cryptopia, whether we add yobit cold wallets depends on whether the member of the team promoting this action can get adequate data to conclusively be certain their cold wallets are frozen.

Very well said. This is why Bittrex doesn't list coins for a fee. They know from the history that more than a few times malicious code has been put into coins, that coins lost userbase completely and went offline. They don't want to associate themselves with this nor expose their users, and investors, to this risk.

I am aiming to make sure that once we have new software and the new protocol ready, that they will be able to easily review it, and determine that it is a lower risk. The fact that they do list Decred is a big plus in our favour, because our codebase is based on the same basis.

So, be patient, we are making sure that we do this right and I concur 100% with marcetin in that, once we get listed on bittrex, a lot of things are going to change.

Well, I think it would be good to focus on Nova.

 I have part way finished registering there and I'll be putting some DUO up to bring buyers to it.

I think if we focus on it as our trading venue we have a better chance of getting noticed in the noise of the crypto space.

Due to the interesting nature of trading at Nova, I am seriously considering getting signed up, I would have done so sooner but they require mobile phone number and I don't have one. So I am getting one sorted out today and plan to place about half my remaining stack at quite decent prices to encourage some liquidity to develop there. However I will stick with Altilly if it seems a wiser option.

Direct prohibition of accounts doing both sides of a transaction doesn't stop sybil attacks for those who are determined to do this, it just takes another person to collaborate or to use a stolen identity if there is KYC limits on this kind of size.

But one does have to wonder what is in mind... Anyone who follows the chatter at our discord would know that the 'total supply' is for sure under 200,000 (118k is from cryptopia liquidation) and probably is realistically more like half what coinmarket cap says.

I'm selling part of my dev payment stack so I can finally pay my tax bill here in Serbia and finish getting my work permit sorted out. I am almost there, just need a few hundred more euros worth of bitcoin in my hands and that is settled at last.

I figure I should also make a quick update here too... I have been bashing my head against the horribly tangled dependencies and mess that I worked from for some time, so I decided to go back to the foundation and break apart its tangle and separate things as much as possible. First task is already done, it is now possible to write another application that deploys a btcd node as a concurrent process inside it.

Once I have split everything into bite sized pieces I will be branching it to reintegrate all the changed parts that make it into a Parallelcoin node. The changes are mostly all ready and tested since months but I was getting snagged on the final integration because of this mess.

On another topic, one of the things that will be changing after the hard fork is the block reward will adjust by a fixed percentage per block (blocks will be regular, unlike the current steady slowdown) that amounts to about 9% expansion of supply per year, compounded every 36 seconds.

I calculated the theoretical supply growth rate for the existing chain *if* it were to stay at a steady block rate, but however, it has been slowing down at a rate so far it has 60% of the number of blocks each subsequent year. But in theory its supply rate was about 24% In actuality, it has been closer to 4% and will steadily get worse. There is no question it has to be fixed if the chain is to survive.

This is the curve I am planning, each of the vertical lines represents a year (and it will stick to the schedule like glue with the averaging formula I have written), and works out to about 9% per year. It probably seems shocking to look at but for comparison, the supply growth rate of Steem is 10% which is not far different.

https://i.postimg.cc/hSw-tg55k/Screenshot-from-2019-06-28-16-04-47.png

Economies and supplies of durable materials (eg gold) typically have rates somewhere around 3-5% per year annual increase of supply. For comparison, the supply of US dollars has been running at around 12-15% per year so in the long run, given a stable demand for more currency, you can see the basis of the 'deflationary' value of most cryptocurrencies.

9% is a good steady rate and the other side of the equation comes from promoting the growth in demand to hold. The more people hold, the tighter supply is pushed and the effective growth of circulating currency is reduced even more.

At this point we have no concrete business proposal that makes the demand grow, but so long as we continue to work and promote it, there will be a relatively steady growth in demand, and price will 'moon' in any case, more or less, but we will be making sure that the demand gets stronger over time.

The plan involves using the DUO as a security deposit, so combined with this new supply rate, it should see a very healthy growth of price against other currencies. We will be building

Yeah, it's unfortunate that people still (even smart people) leave way too much in exchanges and not in paper wallets cold and offline.

It is only for those who can prove some connection to that pool, basically, otherwise it's yeah, sorry, you are in the cold.

But what matters more, to me, is that we cut off that new york court at the pass, because they are gonna sell most of it at a low price, affecting everyone, and paying the piss remaining mainly into administration.

The actual victims will not get anything either way. At least this way those who still have some DUO won't have a haircut thanks to a government court.

edit:

Of course, there is risk of putting money back in people who lost it's hands, and those who as you say, bought it but didn't draw it out...

I'm up for whatever solution seems most reasonable hence this proposal. But if there is going to be nobody happy with *some* redistribution versus none maybe it is better to burn the lot because I guarantee it is not going back to anyone based on past history of exchange liquidations.

edit 2:

Alternatively, we could put that pool in the hardfork, into a multisig account with 3 of 4 with me, marcetin, trax0r and nWo as signatories and then we can play hardball with the court on behalf of our coin holders, and refuse any deal that doesn't see at least 90% go back to our users.

Have your say

Come join the Parallelcoin DUO discord chat and in #agenda you can react to our proposals and have your voice heard.

https://discord.gg/sW8WPkP

This invite is good for 100 new users, if we need more we'll make more later.

After I am finished with getting the server app `9` completed with its hard-fork switch, the exact details of the hash functions in the new proof of work, and we have the GUI sketched out, I will be assembling the verifications for any users making claims to recover funds lost to Cryptopia.

The details will be more clarified in the next week or three, but this is basically what we need:

1. Amounts deposited and the deposit address at cryptopia
2. Signed message proving control of the addresses that were the inputs for the deposits to cryptopia
3. An address to have the recovered DUO sent to as part of the hard fork switch process

With this information, and tracing it all back to the single address that now contains over 118,000 DUO, if everything looks correct we will encode into the hard fork to have the full amount that is provable returned to the accounts as requested by the holders.

The complete process will be published and the documentation proving the justification to do this will be published when the code in the hard fork is ready to go.

I am not sure where these filings should be going, I am just writing this to explain how we will run it and ensure that nobody gets a satoshi they don't have a legitimate right to.

edit:

It was just highlighted to me that it is possible that a user who deposited a sizeable amount on cryptopia may have in fact sold those duo on the platform. As such, based on the odds that I will posit, 50% chance they are trying to recover what they mistakenly sold, that we will only issue half of the value claimed as an insurance against this.

It sounds like a good idea but it requires capitalization, and involves careful risk management systems.

We are planning to create applications that use the coin as a security deposit instrument with intentionally deflationary token issuance rates, such that these deposits grow in value over the time bonded. Very likely this could support hundreds of chains doing this, and there would be a huge utilisation with low bandwidth overall. It is part of a strategy to deploy a specific model on a Tendermint based chain and using the Cosmos Inter-Blockchain Communication protocol, to create a model for masternode-like tokens to form networks, as a protocol for bonding server operators and acting as an economic incentive that can't be attacked and operated directly by the nodes to impose penalties and release bonds.

If you have some model for how to build this market maker application we could make one where people can invest together to run a group of servers that operate it across to other services (and chains).

This should be updated when the new main landing page is online soon, but this is the current main home for the legacy client:

https://git.parallelcoin.io/dev/parallelcoin

These are 'AppImage' universal binaries that you can run on

https://github.com/parallelcointeam/parallelcoin/releases

The second one (parallelcoin-qt) is the graphical wallet that you will probably want to use.

We are also hosting it here: https://git.parallelcoin.io/dev/parallelcoin-binaries

Basically, download it for any linux (I made sure it will work for any version released after april 2014 or later), assuming it is 64 bit, right click on the icon and select 'properties' and make it executable, and voila. I'm not sure how to explain that any better than that. Oh, a picture will help I guess:

This won't be visible unless you click on it:

https://i.postimg.cc/jdvmB89J/Screenshot-from-2019-06-20-17-40-47.png

For mining:

Usually you would use the other one (without -qt) for mining, though it is possible to use the -qt version if you manually edit the configuration.

But actually, most people would mine using a pool at this point. It can be mined the same way as you would mine bitcoin or litecoin, and including the same hardware as you would use for either of them, SHA256D or Scrypt.

In the future, after the hardfork, at first there will only be CPU mining and probably in a few months after that there will be an OpenCL and Cuda kernel to use GPUs. I doubt there ever will be an ASIC because I am designing the algorithm so that where a CPU is faster, a GPU is slow, and vice versa, and the complexity of the algorithm will make an ASIC essentially a computer anyway.

The only way to deal with that would be to have significantly more  in your 'float' than you turn over on a daily basis (spend and receive).

If the question is relating to the block time, this is unfortunately the result of very wide variance in hashpower mining the coin due to its still-small miner userbase.

I am working on an upgrade that should see a massive improvement in the regularity of blocks as well as opening up mining to people who might just happen to have a few computers laying about, as it is designed to be equally fast whether it's GPU or CPU mining.

The upgrade should be in beta testing within weeks and maybe mid-to-end of july it could be switching over.

Hi again...

Yes, I was diverted due to circumstances beyond my control, I went away for a while, maybe it was going to work out, I didn't know but it was the opportunity I had. I won't go into details, but let's just say that as with most corporates, they don't understand that it's not some new framework or wingding and it's not going to lead them to lambos, at least not if it's not thought out from top to bottom.

I am currently confined to my blackview BV6000 smartphone, with a keyboard plugged in via an OTG cable the electronics wizard who picked me up on my way to Sarajevo to investigate my possibilities of going back to australia. Well, that turned out pretty poorly, the going back part... the australian embassy had shut down and it was not until end of the month even to start the interview of the first step sorting it out...

I can do some basic things with this setup but it's not enough to really do what I need to... but then since I haven't got any option I might as well learn some things... I found a great search app called 'fuz' - written in Go, and the text editor 'micro' - wow, it's amazing... I think probably before 2 years time you will have a Go IDE running over text console, I only really needed a better interface for the debugger and I would be working almost as effectively as on visual studio code.

I should be back full time at the work within a week or so.

parallelcoin developer first beta release (sans GUI): https://git.parallelcoin.io/dev/9/src/tag/v0.9.0

It's probably rough around the edges and documentation isn't nearly done yet but it works!

If you want to play with it and want a little help getting to know how to start with it, come visit the discord https://discord.gg/nJKts94

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 schedule

Another 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