[ANN] ParallelCoin - DUO - SHA256 + Scrypt | HardFork Soon!!! We are going Go!

[yuluxugi32132]

the blockchain explorer is not working anymore. The project looks dead

[1714957031]

1714957031

[trax0r]

the blockchain explorer is not working anymore. The project looks dead

only in your eyes... 
Block explorer will return soon.
Check out discord for news on the project, too... https://discord.gg/N8hfCX

[FreedomCoin]

Best of luck to Parallelcoin, great to see them on other platforms like Bearshares.

[trax0r]

Best of luck to Parallelcoin, great to see them on other platforms like Bearshares.

The link:
https://bearshares.com/whitepaper/@loki/parallelcoin-whitepaper

[lokiverloren]

Best of luck to Parallelcoin, great to see them on other platforms like Bearshares.

Just so you know, I am an advisor to Bearshares and I was the first after the founder to set up a witness. It's really just one guy working on it right now, but we now have another 3 witnesses and the crypto-social celebrity Halo will be online with her witness shortly also.

I was just informed today that EasyDex, a BTS based DEX that friends of mine started up in second quarter 2018 will be listing the Bearshares tokens, which is nice for me because it means I might have a little extra capital for funding my work. I will also be working towards gluing all the things together, hopefully with a new asynchronous PoW blockchain system that I have just started designing.

And about the actual project at hand - I am currently building the stand-alone miner app for the new chain, and for this I need to write an extension to the websockets notification API that the miner subscribes to to be notified when a new block has been found on the network, and provides the caller with all of the data (prevblock hash, merkle root, timestamp and difficulties for all 9 algos). It is possible to do this without the extension but the response time for the data is much too slow. It needs to basically be instant, chain connects a new block, and then miner has what it needs to directly build and solve a block. Because of the 9 second block target,  every millisecond counts towards a miner finding and submitting a block to get to all peers before another miner does.

I had hoped the websockets latency would be better than what it is, but them's the breaks. In the future I want to abandon the HTTP and TCP protocol completely, they just have so much handshake overhead compared to UDP streams. After the release of the hardfork I plan to be working on everything non-consensus related. Particularly the peer to peer protocol, which I would much prefer if it was multicast UDP, so nodes just stream new gossip to each other without requiring acks (but accepting resend requests) to further tighten the timing and decrease coinciding block solutions.

Orphan rate is somewhere around maybe one in 60 in testing so far. Considering that there is 400 blocks per hour, this does not work out to a lot of wasted hash power really, but I know that improvements in message propagation would cut that down dramatically, maybe as much as 10x, as miners far less frequently have stale blocks to work on after a new block has arrived.

Transaction latency and throughput are important metrics in this technology, and it's my opinion that it is still an unresolved question. There is better gossip network protocols existing than the quite aging system used by most bitcoin forks and most anything else, but the technology to leapfrog past the limitations of TCP is not widely deployed yet, and maybe a little immature, and to some extent, the existing network systems are not *so* friendly with these. If we had IPv6 available to everyone, that would change a lot, enabling many to many multicast routes. This can be achieved to a significant degree with UDP, however.

As I see it, the real winner in the tech race hasn't really shown up yet. Bitcoin and most bigger forks are still on laggy, long delay, narrow channels, and bitcoin's incumbency has stifled its development. Smaller coins with better devs working on them are going begging for funding to improve the work rate and put the better programmers in the job. Even though crypto engineering work has quite a decent pay rate against the market in general, the reason why is in part due to the fact that even programmers involved in developing distributed, centralised systems look down their noses at this tech, and it's quite ridiculous because actually the need for resilient distributed database applications is greater than ever. Especially in payments, where especially social network systems are being 'herded' by players like Mastercard and Visa into supporting their political backers agendas... But I am quite sure that if there was an open protocol that could run rings around Mastercard's capacity, the situation would be very different. It's this that they are trying to stave off and continue to milk their investors as long as possible. There's more conspiracy theory junk I could talk about related to that, but it's quite simply self-interest on the part of those with the biggest existing stake in the market who don't want to lose their top position, everything else is just evidence.

[lokiverloren]

the blockchain explorer is not working anymore. The project looks dead

It's back online again... I am gently pushing to get the infrastructure in focus now, since I am closing in on a release complete with the hardfork and new mining protocols, it will be 100% reliable soon but for the moment it is working and you'll be pleased with how fast it is compared to most explorers. @marcetin is really good at writing super fast web apps using Go and AMP...

https://explorer.parallelcoin.info/

[lokiverloren]

I'm going a bit slow at the moment for various reasons, but just wanted to  make an update as I have achieved something...

I am building a miner worker controller that will interface with the kopach miner to coordinate work for anyone running more than one machine (If you only mine with one machine you can use the built-in CPU miner).

It took a few tries to figure out what way would be the best to work it, and forking the cpu miner code was the simplest, as basically what it does is exactly what I need, except for to instead of run miners directly inside the main server process, it runs a server that clients send a subscription request, and then the worker tries to solve it, when a new block is received from the network, it pushes out new work to the clients, who then should abort current jobs and start on the new.

The miner controller service will be using KCP, a reliable UDP protocol with forward error correction and optional encryption. For miners running on a lan, the small extra reduction of latency not using encryption is an option, and if the workers are connected over insecure paths, it can use AES encryption to prevent mischief, and the pre-shared key used for the encryption also acts to prevent snooping and spoofing from a potential attacker.

Of course I don't advise using the internet as the transport for mining, as it will cost equal to several solution attempts in latency. This is because with 9 second average block time there is only a small window of opportunity to solve a block and submit it and have it accepted before other miners, and this acts as security against both pool miners and botnets, both of which will have a significant disadvantage in potentially up to 2 seconds delay in assigning new work after their main node receives a new block forcing a work restart.

CPU mining has different issues to deal with compared to other types of mining, and long block times allows a lot more scope for attackers to corrupt the data on the network. Plus, it is generally considered in the web application business that after 10 seconds delay, users feel that the remote system is unresponsive, and thus first confirmations typically being under 10 seconds means that real applications, and not just monetary ledgers can be used from this same base.

[lokiverloren]

Just a little, super-short update:

I have been finding it very confusing trying to work with the KCP protocol for this task, so I have been learning how to program UDP sockets directly.

I now have an important part of it worked out, the 'reliability' part in the Reliable UDP - a fully working Reed Solomon error correction codec. It uses a 9/3 scheme, where you send out 9 separate packets, but only 3 have to make it to the other side intact to deliver the message.

This is very pessimistic about corrupted packets and dropped packets, but it should ensure that almost never a retransmit is required. Being that transmission can be up to 400ms on a good day from the opposite ends of the internet, the extra 5-10 ms for encoding and the triple amount of data sent hardly seems like a bad price to pay.

This reliable UDP protocol is for pushing work to miners in the case of a mining farm, since at 9 second average blocks, every millisecond counts towards finding a solution before someone else. But later on, I will be adding this messaging protocol also to the chatter between nodes, and nodes that have this facility will be able to identify each other and switch to this ultra-low latency gossip protocol transport. This means that Parallelcoin will be one of the fastest proof of work blockchains on the internet.

Oh! In other news, our lead web developer marcetin is back on the case, I had to update some of the wallet server parts that I hadn't updated to match the new hard fork block version scheme, but he has the required wallet server to go with the full node. Oddly, it turned out that the parts that needed fixing were not directly in the 'mod' wallet code at all, but rather, in the 'sac', which is an SPV node based on the SPV wallet being developed by the Lightning people. I didn't recall there being a dependency between them, but there you go.

The SPV wallet is something that I will be also working on after the release of Plan 9 hardfork. It's not so important now since the chain is only about 150Mb in size but it will grow faster after the hard fork and having a light version will be essential especially for mobile devices.

[lokiverloren]

As @marcetin started working on the wallet GUI, it became clear I needed to clean up the logging system and launch system to enable one binary to run both node and wallet alongside the GUI.

It took some searching to find the simplest and cleanest solution, but I had already written a logging framework, so step by step I will be stripping out the old  logger, putting in the new one, and everythting launches from one nice CLI with sub-commands, automatic self-configuration with sane defaults and later some more utilities and extensions of the components.

The new logging system is based on goroutines and channels, so it minimises context switching, reducing the processing cost of logging.

The all-in-one structure will mean that distribution can be done just with the binary, at least to start with, and with a installation script for each platform, it can be installed where it will be immediately accessible. Possibly I will make installer packages that download and place the binary and create any necessary user interface shortcuts rather than contend with many different installers. It's usually just a few files in the user's profile and the GUI would be accessible by the system launch menu.

It may take a little while for me to finish the launcher/log changes, it's pretty heavy going repetitive stuff, lots of details to account for.

I have been thinking about installations and defaults... I think it will default to running the GUI with no options given, and prompt you to install it, it is easy to put different parts in for different operating systems.

I'm not sure about how to copy the binary in windows but maybe it has some 'do this when I finish' special thing that lets you do exactly that, move the binary to its proper place. Or for windows maybe just download it again and put the file in the right place. On mac the dmg package is the whole thing. Writing installers for multi-platform is a pita, but hey if we can have a GUI launch on all platforms we can be the installer. Also later on such things as running at startup and whatnot, which also has implications with the server versions as well.

Also note that it will have integrated explorer webserver and extended GUI that links to the wallet GUI. No more wondering where to check if a transaction has made it into a block!

[trax0r]

As @marcetin started working on the wallet GUI, it became clear I needed to clean up the logging system and launch system to enable one binary to run both node and wallet alongside the GUI.

It took some searching to find the simplest and cleanest solution, but I had already written a logging framework, so step by step I will be stripping out the old  logger, putting in the new one, and everythting launches from one nice CLI with sub-commands, automatic self-configuration with sane defaults and later some more utilities and extensions of the components.

The new logging system is based on goroutines and channels, so it minimises context switching, reducing the processing cost of logging.

The all-in-one structure will mean that distribution can be done just with the binary, at least to start with, and with a installation script for each platform, it can be installed where it will be immediately accessible. Possibly I will make installer packages that download and place the binary and create any necessary user interface shortcuts rather than contend with many different installers. It's usually just a few files in the user's profile and the GUI would be accessible by the system launch menu.

It may take a little while for me to finish the launcher/log changes, it's pretty heavy going repetitive stuff, lots of details to account for.

I have been thinking about installations and defaults... I think it will default to running the GUI with no options given, and prompt you to install it, it is easy to put different parts in for different operating systems.

I'm not sure about how to copy the binary in windows but maybe it has some 'do this when I finish' special thing that lets you do exactly that, move the binary to its proper place. Or for windows maybe just download it again and put the file in the right place. On mac the dmg package is the whole thing. Writing installers for multi-platform is a pita, but hey if we can have a GUI launch on all platforms we can be the installer. Also later on such things as running at startup and whatnot, which also has implications with the server versions as well.

Also note that it will have integrated explorer webserver and extended GUI that links to the wallet GUI. No more wondering where to check if a transaction has made it into a block!

Thank you for the update.
I would make a stand alone .exe to run and the user will know where to copy their stuff to run it again and again.
The old Parallelcoin wallet is also stand-alone .exe and comes with no installer....
So I guess to make an installer for the new one would be a total extra, which could be done some time after the initial release....

[trax0r]

List of stolen tokens on Cryptopia:
https://github.com/elementus-io/cryptopia-hack/blob/master/README.md

DUO is not on the list.

[kurbeks]

List of stolen tokens on Cryptopia:
https://github.com/elementus-io/cryptopia-hack/blob/master/README.md

DUO is not on the list.

It's just ETH and ERC-20 tokens. Really exchanges should start avoiding them if they can't apply required security measures for then.

[lokiverloren]

Good to hear that probably DUO hodlers will not be affected considering how much DUO landed in Cryptopia shortly before the hack. Who knows how long they will take to resolve it, I mean we are only just now seeing the last loose ends tied up for the MtGox crash never mind BitFinex and the Nicehash heist... people really need to get their priorities straight on security.

I have been making steady progress since my last report. I have now got the bits together for the actual block time change of the hard fork, and a testnet hard fork test with a much earlier height of activation. I just need to start debugging it and soon there will be not much left to do except finish the GUI.

The hash algorithms are going to remain in flux until an undetermined time before the hardfork kicks in. The provisional height for activation is 199,999 but this may be extended forward, though I think it's possible it will be able to stay on this schedule. The hash functions have been revised and changed.

Watching the spectacle that is the Grin release, I can safely say that I doubt that Parallelcoin will have as much nonsense associated with issuance rate, distribution, or secret development of faster miners. It is astounding to me that almost 4 years after Cuckoo Cycle was invented it has taken this long for any chain to adopt it. The lie-sensing nonsense of the cabal of GPU programmers and ASIC makers has marred their release quite badly.

The algorithms being used for post-hardfork parallelcoin should not be easily accelerated. There is about 11 or so hash functions used in the entire thing, but one of them is Cryptonote 7, version two, which is slated for the next Monero hardfork, this is inherently a cache-locality-focused PoW, and runs fastest the more cache the processor has. AMD makes GPU and CPUs with the biggest caches hence why monero mining has been able to hold a small contingent of CPU miners despite how big its market cap.

The other unusual hash function is the Argon2i hash. Argon2i is based on Blake2b (or it might be blake2s) and in a similar vein as Scrypt is actually a 'key derivation function' designed to slow down bruteforce attacks on human-memorable passwords used for symmetric encryption. Just as Cryptonote has an optimal hardware platform in the Ryzen processor family, Argon2i requires a lot more memory and so its strategy here is to exceed onboard cache and bottleneck on the system memory bus. Again here is a place that the AMD will be better, as its memory bus latency and throughput are significantly higher than Intel and other processors.

The anti-asic strategy I am applying is not absolute, but rather the structure of the chain of hash functions intentionally intersperses functions with a significantly different optimal hardware. CN7v2 runs best in a Ryzen. Argon2i runs best the faster the memory bus (so yes it would be a candidate for GPU acceleration and possible specialised processor with large onboard cache). So we have two separate processors that are connected at best by PCI-express, meaning their throughput is bottlenecked by PCI-e bandwidth.

I anticipate the best strategy for ASIC makers working to increase power efficiency for the new Parallelcoin PoW scheme will basically be in a compact AM4 motherboard with a ryzen CPU, blake2 accelerator with large cache for Argon, sitting on the PCI-e bus, and a multi-algorithm simple hash processing accelerator for the rest of the hash functions.

Or, in other words, not much distance from commodity hardware, and therefore also commensurately lower efficiency increase potential. Plus an increased complexity burden by requiring at least 3 separate processors (CPU, GPU, ASIC) coordinate their processing to stream the data through in a pipeline.

I am not bothered by ASICs so much as I consider it to be a fact that most blockchain developers do not spend enough time working on improving the low level protocol or the complexity of the PoW algorithms, and too much time cleaning the boots of symbols like bitcoin and satoshi. Blockchain tech people and distributed systems researchers are two sets that have far too small an overlap. CS researchers have a wealth of knowledge that could benefit blockchain tech but sadly it seems to take a long time before anyone actually adopts the technology. This is normal, I guess, but the tech must become fit to purpose and the purpose itself still is unclear to some extent.

I will update again when we reach the next milestone of a functional, usable multiplatform GUI wallet interface.

PS:

I just finished writing a command to automate setting up a localhost testnet cluster. Manually setting all the configurations is tedious and error prone so this will help accelerate testing a lot. Likewise the GUI needs a live network to test on so this makes that easier for @marcetin who is the main UI dev (years of web dev experience)

[trax0r]

We plan to go to Altilly.com (www.altilly.com) as new exchange for Parallelcoin (DUO).

So we contacted them for adding Parallelcoin (DUO) to their exchange.

Currently we are waiting for an answer. I keep fingers crossed that DUO will be added.

[trax0r]

Parallelcoin (DUO) on Coinstats:
https://coinstats.app/liveprices/parallelcoin

[lokiverloren]

I am once again fully back on the case. The last few weeks I have been quite off track but I have got myself back on task now, after finally getting a few minor detail type things more in the way I want them in my dev environment.

My current task is finishing the implementation of the hard fork, and getting the servers back into the state they were when I was last working on it, in the first week of february, I of course looked again at the difficulty adjustment.

Out of curiosity, I had a bit of a look to see what the probabilistic distribution of block times was, and as I had suspected, it is exponential. Many bitcoiners parrot this nonsense that the odds of finding a block do not change from one minute to the next, but this is not true. They are confusing poisson distribution with the distribution of a poisson point process (PoW is the latter).

This led me to look at how I can bias the adjustment to reduce the incidence of blocks shorter than 1 second, and I think I have got something on it now that works. Basically, now the adjustment has a full soft limiter that works on the basis of an exponential reduction of influence at the margins.

Previously it was flat against a complex averaging, now, it has a final stage where whatever the adjustment is, the wider it is, the less it changes the difficulty. It works like a hard limit, except it's soft and squishy. The important thing is that it doesn't too aggressively adjust even in the case of a very divergent clump of blocks.

The most likely time a block is going to be extremely short or extremely long is at the time after a really big change in difficulty and its inverse correlate, hashpower. This new adjustment step helps ensure that the difficulty adjustment doesn't jump too quickly and directly, itself, cause long or short blocks. I was more concerned about short blocks, in this case. Ideally if we say 9 second block time, then we want under 30% of the blocks to come under 4 seconds. This should be the case now.

I am starting on adding the full hard fork block target time adjustment. Previously it was just selected by using testnet, it runs the 9 second blocks. I have to write the code that changes the mainnet block time after the hard fork activation.

Once that's done and tested we will be focusing intensively on the GUI, the final stage before pre-release beta testing.

[lokiverloren]

Oh, by the way, speaking of exchanges, I am good friends with the operators of the easydex.net bitshares based DEX. I am unsure of the protocol level fees (in bitshares) for issuing tokens, but they have a standing offer to add DUO to their bridge, which includes all the majors plus also EUR and USD. Though right at this very moment it seems the bitshares network is undergoing some kind of maintenance as many nodes have been offline recently.

However, I expect this situation to improve fairly soon, and so yes, the idea was in my mind that when the release is done I would do the work of consulting/administering to attach DUO to their bridge just prior to the release, to help improve the potential liquidity of DUO as well as expose another section of the crypto community to the project.

I am not in a position to do much before I finish the beta, but afterwards, I will be available to help with any other listings people can organise. With the crypto market in a dip and 'apparent' bottom, there isn't great urgency to do this work right now nor funds for it, but I think once the thaw has started we should be poised to rapidly take advantage of the improvement.

Like many projects, of course we have our eyes on implementing new technologies that mesh with our platform. My main wish is that after release I can devote a smaller part of my time to maintenance and a greater part of my time to developing the asynchronous protocol that I intend to develop. No blockchain yet has async protocol, and this is the biggest obstacle to low latency high throughput processing. Money is the smallest use case for distributed databases, as important as it is, it is other services that monetise the tokens, payment is not a killer app nor is blockchain really suited, in its current shape, to be much more than this (PoS type protocols cut latency down but trade it for trust, which is an unacceptable compromise, but it does mean more effective non-monetary database applications. Async protocol would make every type of database a valid implementation target for a trustless, decentralised network.

[lokiverloren]

Crypto winter is now fully biting this project. I have just looked again closely at the tax bill that I am supposed to pay so that I can stay here, it's about 1100 euros.

I see absolutely no sane reason to pay this when a few hundred kilometers in any direction I can be inside EU jurisdiction.

I have no idea what to do about this. Sure, it might have helped if I'd finished sooner, and I'm really not that far, given no big new things become needed, from completion. Right now I am working on replacing the CLI/configuration library, as the code that I have written for this, has turned out to be much too error-prone and really there was no available library that really makes any better - the new library handles loading the configurations to spawn the node and wallet at the same time automatically, and I think I'd be finished on it within a week if everything wasn't so nerve-frazzling with this visa situation.

I have friends in Bulgaria who have offered to help out, and I guess probably their project wouldn't suffer from a little help right now, though the current issues on their agenda don't specifically need my coding skills - well, I don't know. There is also people who might be able to help in Bosnia too.

To be honest, I feel a little unworthy considering the poor rate of progress I was making during the first 3 months here. It's my first time taking on such a project, and the conditions in the market also dictate that really, the level of changes I have put together are nearly almost not quite the necessary baseline. From here, unto maybe the next 5 years, probably a lot of projects are going to be working under much tighter regimes than anyone would have expected during the end of 2017.

But hey, it can't be all bad. I'm pretty sure that you could fit the number of people in the world who can write go-crypto apps into an average loungeroom/dining area, uncomfortably.

Any suggestions most welcome. Something has to be done in the immediate short term.

[lokiverloren]

We have got an immigration specialist looking into what options we have, something like a payment plan would be doable, and maybe some other way (I don't have much in the way of collateral but maybe something can be arranged). We are again back fully on the case.

There is a project, relatively small in scope and, although the path got a little wide of the original target before we re-acquired the target, being that of a managed crypto nodes hosting service, bitnodes.net, which needed a substantial overhaul of the back-end to get it working. I am helping also with this right this moment, just a few issues involving build environments, but the automation of boot and control of which node gets what image is mostly done.

This one is the self-funding avenue, and maybe we can get the (two years total and overdue) tax bill paid for my serbian legal entity that will allow me to continue my work without further disruption.

Regarding the actual server software, I have completed what is definitely the most complex API/syntax validation unit tests I have ever written, and I am currently drafting the map of the remaining parts to complete this self-validating, automatic CLI/configuration library, that will replace the climax library that it currently has, with a simple declaration syntax and collection of handlers, that will complete the baseline and necessary 'shell', being a dual-server launcher that is needed to implement the GUI wallet as a combined unit of node, wallet and GUI interface.

Every programmer hates tests, but especially in this case, it is necessary to check the definition of the application is fully correct in its syntax and semantics, before using the values it gathers and composits to launch the individual component(s) for a given sub-command (cli controller, full node, wallet, the combined node/wallet 'shell', and GUI, which includes the shell).

I think within the week I will be back at the point where all of the command stuff is working and this time, without any difficult bugs to chase down. @marcetin should at that point be ready to merge this new back-end for bitnodes with the front end he already wrote, and if we can stay on track well, I'll have my tax bill paid, I have to fully complete the hardfork logic, which is about half done, and  then the GUI, and we will finally be into beta. Maybe a month now, until people can really see it as it is intended, and start to have opinions about what we actually did, which up to now isn't really possible.

[trax0r]

We plan to go to Altilly.com (www.altilly.com) as new exchange for Parallelcoin (DUO).

So we contacted them for adding Parallelcoin (DUO) to their exchange.

Currently we are waiting for an answer. I keep fingers crossed that DUO will be added.

Good news:
I just found a posting, that Altilly has Parallelcoin (DUO) on their list and that we have passed the first step to be accepted for listing on Altilly (approved listing).
Now we need to wait some more days - until DUO will be added to Altilly Exchange. I think this will happen somewhen now in March 2019.

On this website you are able to see the progress of Altilly:
https://t.co/5naLnTAo5F