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

[trax0r]

need peer list. my wallet stuck at 20 hours left...or what happend with it?  Parallel coin Explorer looks also dead..

Chain is at block #211463 here.
No new block since a few hours as somebody jiggled up the diff to ~30k.

Current addresses, listed from my running wallet:
157.161.128.62:11047
194.135.88.119:11047
89.40.12.55:11047
185.69.55.35:11047
103.254.148.9:11047

and yes, my wallet is also 10 hours behind. This happens sometimes, when noone is finding a new block....

Last block:
{
"blocks" : 211462,
"currentblocksize" : 0,
"currentblocktx" : 0,
"pow_algo_id" : 0,
"pow_algo" : "sha256d",
"difficulty" : 352261065.45774931,
"difficulty_sha256d" : 352261065.45774931,
"difficulty_scrypt" : 23521.46422410,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 7,
"testnet" : false
}

Quite high diff for sha256.

[1597327499]

1597327499

[1597327499]

1597327499

[1597327499]

1597327499

[1597327499]

1597327499

[1597327499]

1597327499

[four3200]

well is there a way to make it less clunky?

I don't want to say more aggressive Gravity Well.

Because the SHA & SCRY can only be the DUO.

I have always wondered if a masternode with the option to lower diff after X time can call a block with no more reward than POW producers is functional.

Also MN just requires 2 DUO.  (But phased towards timed LOCKED)

For the unitinated.

That just means MN can call down diff, yet earn minimal rewards.

[marcetin]

well is there a way to make it less clunky?

Gopher, don't know it?

Do you know what that represents?


All other soon will be different, from algos to diff retargeting. The chain will be the same, so the hard-fork soon...

[lokiverloren]

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.

[lokiverloren]

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!

[lokiverloren]

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.

[lokiverloren]

well is there a way to make it less clunky?

https://media.discordapp.net/attachments/452386929103601666/651884886961029123/download-svg_1.png?width=120&height=120

I don't want to say more aggressive Gravity Well.

Because the SHA & SCRY can only be the DUO.

I have always wondered if a masternode with the option to lower diff after X time can call a block with no more reward than POW producers is functional.

Also MN just requires 2 DUO.  (But phased towards timed LOCKED)

For the unitinated.

That just means MN can call down diff, yet earn minimal rewards.

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).

[marcetin]

Finally, we are able to compare the amount of our work on new ParallelCoin code with others.

Remember, price is a consequence, development is the cause!

So, please check on which place by measuring the amount of work on code we are:

https://www.cryptomiso.com/

Hard fork time close.

Join our Discord channel to be tuned

https://discord.gg/6GzHz5x

Cheers!

[trax0r]

Our former dev loki is currently busy in another project, so we are searching for a new go dev to finish the new wallet, which loki started.

The wallet is at 98% finished, so basically development is done, but bugfixing is needed.

There is pot of DUOs available for the dev finishing the job loki started.

Check out the git:
https://github.com/marcetin/parallelcoin

If you are interested, please reply here or join discord and write the core team there.

[trax0r]

Sooooo....
We still have not found yet a new go dev to finish the wallet job... Is there anybody out there?

Well, DUO/Parallelcoin is not my own coin or marcetin´s own coin or any other core members or whatever discord member status owned´s coin.... it is a community coin ... so basically everyone owning DUOs might/could help to find a new go dev to finish the wallet development.

There was no premining and so there are no funds available to share for jobs on the coin... marcetin and me, we already paid a lot of crypto/money for the last dev, but still wallet have not yet got finished.
But the go dev, which would be willing to finish the wallet development job, would be able to get a DUO payment for his dev work when the fork is done. Part of the fork will then be a "premine" with his coins for his dev work.

I am not a programmer and i cannot fully judge now what still has to be done, but I have seen the wallet already running and working, and it looks like it is 97% finished. Here and there in the gui you need to fix some stuff, and maybe also in the "back" of the wallet of the working code.

But still marcetin and I were not able to find a dev yet, which can program in go language (google language)

So if you know one go dev out there which might/could help to finish the project, we would be very thankful and also the dev would be able to make a small fortune on DUO coins when the wallet is released and the fork is done.

If you are a go dev and are interested, please reply here (or write me a personal forum message, or join our discord to write me there...) Thanks.

[trax0r]

Sooooo....
We still have not found yet a new go dev to finish the wallet job... Is there anybody out there?

Well, DUO/Parallelcoin is not my own coin or marcetin´s own coin or any other core members or whatever discord member status owned´s coin.... it is a community coin ... so basically everyone owning DUOs might/could help to find a new go dev to finish the wallet development.

There was no premining and so there are no funds available to share for jobs on the coin... marcetin and me, we already paid a lot of crypto/money for the last dev, but still wallet have not yet got finished.
But the go dev, which would be willing to finish the wallet development job, would be able to get a DUO payment for his dev work when the fork is done. Part of the fork will then be a "premine" with his coins for his dev work.

I am not a programmer and i cannot fully judge now what still has to be done, but I have seen the wallet already running and working, and it looks like it is 97% finished. Here and there in the gui you need to fix some stuff, and maybe also in the "back" of the wallet of the working code.

But still marcetin and I were not able to find a dev yet, which can program in go language (google language)

So if you know one go dev out there which might/could help to finish the project, we would be very thankful and also the dev would be able to make a small fortune on DUO coins when the wallet is released and the fork is done.

If you are a go dev and are interested, please reply here (or write me a personal forum message, or join our discord to write me there...) Thanks.

We might have found a new go dev. Currently he is checking the source code and project details to see, if and how long it would take to complete the wallet and start a beta test.
I keep the fingers crossed.

[trax0r]

We have found our new dev for Parallelcoin, which is willing to complete loki´s work: Welcome saniales! 

He can only code on the new wallet part time/some hours a week, as he has also other projects currently running, but as the majority of the new DUO wallet and features were already done by loki, the time of a few hours a week would be enough to complete the rest of the work.

In the next days we want to discuss which features will be included in the first release. So it might be that we do a two or three step release with upgrades until all features, which were developed, will be available and useable to the public. More of this in the next days.

Let´s hope we can get a public beta soon.

[four3200]

2cents on up-dates:

1.  it is not a bug but a feature.  Related to the fact that DUO takes some time to produce a block, but the duo algorithm is reliable in that eventually and consistently it sputters on!  In time I would predict that all POW chains [even BTC someday future] will hang depending on economic factors.  So DUO is already time-tested.

2. However it would be better to not be "clunky".  So any diff adjusted improvement would be okay.  BUT.  Fucking with protocol has its hazards.  Less is better.

3.  THUS.  Moving off SHA and SCRPTY is suspect.  And alternative POW algos over time likely will be captured by ASIC.  It's the LAW.  And attracting alt POW miners is fickle.  SHA and SCRPTY are industrial standards.  

4.  Whatevers.

5.  I applaud any dev work / active participation.  But do exercise caution.  Protocol is key.  

6.  If I had a wish.  Maintain SHA and SCRPTY as is, but update to POW/POS as the "duo", SHA and SCRPTY get the 1st rights to produce a block, but if they fail, a POS node could produce one in say after "duo" hours, and also drop diff to get the POW going again.

_{*the "DUO" SHA and SCRPTY is resilient in that even though it hangs the dual algo has sustained participation whereas singular algos that hang can be abandoned, therein contains a fundamental principal that multi-algos resolve overtime once caught in difficulty adjust predicaments whilst singular algos tend to be abandoned and wither.   Therein the problem is maintaining the "duo" identity.  Hence I suggest POW/POS, alternative is perhaps POW-asic vs. POW-not-asic.}