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

[chey]

I'm speechless

[kurbeks]

I'm speechless

+1 to that. Sadly Cryptopia sees forks as new coins and Yolobit isn't keen on updating wallets and listing new coins.

[chey]

Sadly Cryptopia sees forks as new coins and Yolobit isn't keen on updating wallets and listing new coins.

You raise a valid point. 

[MiguelEl]

Greetings, DEV's. I wish you success

[marcetin]

I would like to introduce myself, since my boss has been so busy he didn't think of it - I am the new lead blockchain engineer/dev in the project now.
.....

True


Sorry to all on that ... I am without excuse


Beside many things questioned here one is sure, the whole system will be writen in GoLang. Everything in our project will be GoLang at end.

+1 to that. Sadly Cryptopia sees forks as new coins and Yolobit isn't keen on updating wallets and listing new coins.

It is not like that. Many people are confused with meanings of that "fork" word.
I think for Cryptopia as long as blockchain is same all updates on a wallet are ok, even it is rewriten to another language. Yolo is out of any talk.

[lokiverloren]

At this point there is not actually a fork, simply I have updated the repository to build on current versions of things on a current linux system.

This repository below is now fixed to build on more or less any current version of linux. I don't know if the mac or windows builds work or not, I didn't touch them because I don't know anything about them.

https://github.com/ParallelCoinTeam/parallelcoin

It's not a new version, it's just a version that you can build on any linux. There is a script in src/linux-build.sh that will ease all the painy bits, building the server, qt wallet and dropping the necessaries into your home folder to add them to your favourite linux desktop application menu (for the Qt app, anyway).

For the technical details, what I did was embed openssl 1.0.1 into the repository (just so you don't have to and you need to install berkeleydb 4.8 and boost 1.59 beforehand. For linux users, this will give you the parallelcoin-qt GUI wallet and the daemon you can run how you want to. I fixed all the code so it all builds out of the 'src/' directory, both the daemon and Qt wallet, and it took a few changes here and there, many of which had already been made on other bitcoin-based clients previously (well, I had figured them out mostly beforehand by reading the errors).


I have some parameter changes for the chain worked out, 30 second blocks, lowered minimum difficulty to be reasonable for scrypt, and an increase in the maximum amount of difficulty adjustment when hashpower changes and causes blocks to break the block time pattern. 30 second blocks is an optional change, I am looking to hear arguments for and against. I think 1 minute would be enough, 30 seconds shaves it a bit close to the limits of blockchain systems.

These are changes that will cause a fork. These are changes we have to tee things up with pool operators and exchanges to get pushed through. I suspect that most reading this would be glad to have this update. Shorter blocks and a more aggressive difficulty adjustment will reduce the arhythmia the chain has developed significantly.

I am looking into how to distribute the new version better - I am looking at flatpak for the GUI, which greatly simplifies installation for casual users on Linux. We will need a mac and a windows person to check if the builds are still working for these platforms, I suspect they will, but the mac version in particular might take a little more work. I am attempting to get a static binary built now that will just run on any recent linux version without any installation, something we can put on the 'releases' page alongside the binaries for mac and windows. I think Marcetin might be able to work with me to get the mac version sorted out tomorrow or the next day.


I have diverged from the main mission of building a Golang based client for the network temporarily because I think current and recent builds should be available, and there is a small amount of tweaks I have made that I think will improve the performance of the network. We have some, one or a few cloud miners dumping hashpower sporadically on the network which is exposing a serious flaw in the protocol - it only adjusts difficulty when someone finds a solution at the elevated difficulty. The lack of scrypt pool and generally low level of hashpower on the network contribute to this but if I dig around a bit I may be able to figure out how to trigger difficulty adjustment checks in between blocks and have the difficulty drop fast enough between these attacks to let other users actually win blocks.

I have been getting so far into this that I might actually be able to make this change myself fairly easily, before the new client is written, and I probably can tune it so that it progressively lowers difficulty until it hits the surface of the available hashpower and gets 5 minute blocks regularly, even with such a wide difference between maximum and minimum hashpower on the network over time.

So, to set the agenda for the next bits of work the dev team will be doing, we need someone to help with getting the windows and mac versions compiling, we need to launch a scrypt pool. I will be getting a static binary for the server and qt wallet built in the next day or so, that hopefully I can easily turn into a flatpak or at least most people will be able to just dump in their executable path and use on any linux.

The one thing that would be really nice to be able to get happening is to integrate merge mining so we can get some free hash power to reduce the vulnerability of the chain, but I'm not sure what's involved with that exactly. I know several sha256d and scrypt coins based on bitcoin have this, so it might not be so difficult to integrate.

I just checked a static build I started, and I found that the upnp and berkeleydb libraries didn't have objects to link. I think I'll be able to fix that tomorrow and then I can push up binaries for the new 1.3 build. I bumped the version number because I think it's overdue and the parameter change version will then be 1.4... we'll be still two versions behind bitcoin and litecoin but whatever! The golang client will be 2.0, and it will be significantly better, and I will make it modular so we can add numerous other merge mineable algorithms to further reinforce the hashpower security of the system.

[kurbeks]

I would like to introduce myself, since my boss has been so busy he didn't think of it - I am the new lead blockchain engineer/dev in the project now.
.....

True


Sorry to all on that ... I am without excuse


Beside many things questioned here one is sure, the whole system will be writen in GoLang. Everything in our project will be GoLang at end.

+1 to that. Sadly Cryptopia sees forks as new coins and Yolobit isn't keen on updating wallets and listing new coins.

It is not like that. Many people are confused with meanings of that "fork" word.
I think for Cryptopia as long as blockchain is same all updates on a wallet are ok, even it is rewriten to another language. Yolo is out of any talk.

Yes was expecting regular swap and new chain. But looks like coding skills here are higher than in regular shitcoin. So yes Topia will update their wallet as long as it's on same chain.

[lokiverloren]

hehe... and the more I work with it the more things I understand, even if I still hate the evil C++ and the evil Boost. I didn't know if I would even manage to be able to fix the code to build with GCC 8 but it's all 100%.

Nothing yet requires getting any exchanges or pools switched over though. I think I should do some testing to tweak the parameters as much as I can and definitely I will look into adding something to the network tick to reset difficulty as it gets slow. If I can at least bring the rhythm back to the chain that would be a huge improvement. I will hold off on merge mining for the revamped client. Marcetin has pointed me at some other work that has been done in this direction, now I know there is at least 4 proof of work blockchain clients written in Go.

Since the changes are not really that big, I think we should be able to get cryptopia to upgrade their node with not too much persuasion. We will get a test net running and torture it for at least a week before we confirm it's ready.

As regards to forks, they can happen unintentionally. It took a lot of coordination by the Ethereum guys to make sure that geth and parity didn't desync, there was a big issue recently and the C++ client was at risk of causing the chain to fork because of problems in the code.

[chey]

The one thing that would be really nice to be able to get happening is to integrate merge mining so we can get some free hash power to reduce the vulnerability of the chain, but I'm not sure what's involved with that exactly. I know several sha256d and scrypt coins based on bitcoin have this, so it might not be so difficult to integrate.

I'm not aware of any multi-algo coins that allow merge mining. DUO would be the first if you could pull this off?

[trax0r]

The one thing that would be really nice to be able to get happening is to integrate merge mining so we can get some free hash power to reduce the vulnerability of the chain, but I'm not sure what's involved with that exactly. I know several sha256d and scrypt coins based on bitcoin have this, so it might not be so difficult to integrate.

I'm not aware of any multi-algo coins that allow merge mining. DUO would be the first if you could pull this off?

This will get awesome.... mine DUO together with Litecoin or Bitcoin.

[joes021]

But mining DUO right now is still big problem.

[lokiverloren]

Indeed. It's not just bad for mining it's also bad for transactions. I really have to fix it before moving on to the new version is written.

I've currently got a weird problem with the build, it's working 100% perfect on my home pc's system but the system I am running at the lab is not working properly for some strange reason.  I will be working on fixing this and adding to the consensus a lowering of difficulty and changing how the difficulty is computed. It needs to more aggressively raise difficulty when hashpower rises, maybe as much as 4 or even 8 times as aggressive, and after the space between blocks rises over about 20 minutes it should aggressively lower difficulty until a block is found.

The attacker on the chain is exploiting the fact the difficulty does not return to match the hashpower that is present most of the time, so they are monopolising blocks and causing them to come in a short burst every 3-12 hours. If we could stop them getting more than half of their blocks as they dump hashpower on the network, then slowly lower the difficulty, accelerating it, back down over the hour after these rises, the miner would either have to run on the network for longer, lowering their profit, or go elsewhere to exploit flaws in cryptos for profit.

I think I can probably make a solution for it, but it will also require us to get the exchanges and other services related to the coin to accept the change to the consensus.

I may have to add the merge mining before any new client is worked on also, to allow more hashpower to be on the coin and reduce the fluctuation that would be caused by coin-hoppers like the one we have on our chain.

[tigerwhit4]

Ok kievpool Is up and running with Parallel Coin added. We have found about 5 blocks come and join us you may even get a bonus  
make sure to sign up and create your worker.
just set your miners to this

Code:

 -o stratum+tcp://pool.kievpool.com:4266 -u worker name -p x 

you can also join the pools discord by going to discord.gg/XUzCsdZ

Happy mining

[kurbeks]

Well If its still SHA256 I am willing to add it to my pool that i have just opened.

Add also scrypt, plz

[lokiverloren]

I have started on fixing the difficulty adjustment. It amazes me that both bitcoin and litecoin and many other early coins have no defences against a very wide variance in hashpower over time. Once a block comes in at a very high difficulty, the only time it adjusts the difficulty down is when another block, which must be as high as the previous one according to the difficulty. Essentially it averages the last 10, but it can only bump the difficulty up by 2% each time a new block comes in so the attacker can just show up for 5-10 minutes a day, bomb the chain with blocks, and know that likely at least 3 hours before anyone else on the network might find a solution as high as the difficulty has got. I think this is known as the 'instamine' problem.

So, I have been busy searching through the code, following the execution path from starting, and located the place where difficulty is adjusted and where I can potentially add a timer triggered event that I set to exactly 5 minutes, and then it sets a new one for every minute afterwards, that recalculates and propagates a difficulty change.

The other measure I think is required is to massively accelerate the rate at which difficulty rises in response to blocks less than 1 minute apart. These adjustments really should go up fast, I think 4% at the second block in 10 seconds, and each subsequent block less than a minute apart the difficulty adjustment doubles, so next block under 1 minute pushes the difficulty up 8%, the 4th will trigger 16%, 5th at 32%. This should at least slow the second block to the root of the interval between (so if it was 4 seconds between the next will be likely at least 16, after that 256, and then by this time we are at close to a normal block period).

This adjusts to the massive jump in hashpower quickly, and then after that the previous timer triggered event will lower the difficulty by 2% every minute past 5 minutes time. It should lower to actual available hashpower within 20-30 minutes which will be long enough to at least double if not quadruple the cost of this attacker compared to their profit. They would need to keep mining at least for half an hour to get more than 3 or 4 blocks, and they don't even seem to hang around longer than about 5 minutes. This makes sense since this is the averaging period and after 20 blocks it has risen by 1.02^10 at least, 21% higher, but the longer the gap the more likely the chain is to adjust downwards.

Essentially the chain doesn't currently have a strategy to deal with a sharp decrease in block time and this means that the target is woefully incorrect most of the time. When being attacked, it isn't high enough, when the attack is over, it has no way to adjust back to normal hashpower.

In fact, another measure could be an option, to simply disallow any block arriving less than 1 minute since the previous. This should not be based on the block timestamp, but instead simply the accept block function can be set to reject anything sooner than 60 seconds since the last and just drop the block. This might be even simpler to implement than adding a timer triggered event. All the necessary variables are already in scope where I would add it. There is absolutely no benefit to blocks arriving closer than 30 seconds anyway, and one minute is a reasonable minimum.

The process by which servers in a distributed network decide what to accept and what to reject has a built in subjectivity. The transactions do not propagate instantly to all nodes at once, every node has a different memory pool, most of the time, to any other, at any given moment in time. By disallowing a subjective 1 minute time limit after a block that any block arriving before 60 seconds after the last was received, we are not trusting the timestamps on the blocks, which can be post-dated by some period (I think with bitcoin it's an hour either way), but rather just how the blocks propagate. If a block comes in close to this boundary, it may be that say 25% of the nodes reject the block if it arrived sooner for them than the previous arrived, the block will still succeed because most nodes didn't see it until after they saw the previous one.

Anyway, I need to set some agenda items here in the Lab, hopefully I will see the boss soon.

[litecoinricky]

I have started on fixing the difficulty adjustment. It amazes me that both bitcoin and litecoin and many other early coins have no defences against a very wide variance in hashpower over time. Once a block comes in at a very high difficulty, the only time it adjusts the difficulty down is when another block, which must be as high as the previous one according to the difficulty. Essentially it averages the last 10, but it can only bump the difficulty up by 2% each time a new block comes in so the attacker can just show up for 5-10 minutes a day, bomb the chain with blocks, and know that likely at least 3 hours before anyone else on the network might find a solution as high as the difficulty has got. I think this is known as the 'instamine' problem.

So, I have been busy searching through the code, following the execution path from starting, and located the place where difficulty is adjusted and where I can potentially add a timer triggered event that I set to exactly 5 minutes, and then it sets a new one for every minute afterwards, that recalculates and propagates a difficulty change.

The other measure I think is required is to massively accelerate the rate at which difficulty rises in response to blocks less than 1 minute apart. These adjustments really should go up fast, I think 4% at the second block in 10 seconds, and each subsequent block less than a minute apart the difficulty adjustment doubles, so next block under 1 minute pushes the difficulty up 8%, the 4th will trigger 16%, 5th at 32%. This should at least slow the second block to the root of the interval between (so if it was 4 seconds between the next will be likely at least 16, after that 256, and then by this time we are at close to a normal block period).

This adjusts to the massive jump in hashpower quickly, and then after that the previous timer triggered event will lower the difficulty by 2% every minute past 5 minutes time. It should lower to actual available hashpower within 20-30 minutes which will be long enough to at least double if not quadruple the cost of this attacker compared to their profit. They would need to keep mining at least for half an hour to get more than 3 or 4 blocks, and they don't even seem to hang around longer than about 5 minutes. This makes sense since this is the averaging period and after 20 blocks it has risen by 1.02^10 at least, 21% higher, but the longer the gap the more likely the chain is to adjust downwards.

Essentially the chain doesn't currently have a strategy to deal with a sharp decrease in block time and this means that the target is woefully incorrect most of the time. When being attacked, it isn't high enough, when the attack is over, it has no way to adjust back to normal hashpower.

In fact, another measure could be an option, to simply disallow any block arriving less than 1 minute since the previous. This should not be based on the block timestamp, but instead simply the accept block function can be set to reject anything sooner than 60 seconds since the last and just drop the block. This might be even simpler to implement than adding a timer triggered event. All the necessary variables are already in scope where I would add it. There is absolutely no benefit to blocks arriving closer than 30 seconds anyway, and one minute is a reasonable minimum.

The process by which servers in a distributed network decide what to accept and what to reject has a built in subjectivity. The transactions do not propagate instantly to all nodes at once, every node has a different memory pool, most of the time, to any other, at any given moment in time. By disallowing a subjective 1 minute time limit after a block that any block arriving before 60 seconds after the last was received, we are not trusting the timestamps on the blocks, which can be post-dated by some period (I think with bitcoin it's an hour either way), but rather just how the blocks propagate. If a block comes in close to this boundary, it may be that say 25% of the nodes reject the block if it arrived sooner for them than the previous arrived, the block will still succeed because most nodes didn't see it until after they saw the previous one.

Anyway, I need to set some agenda items here in the Lab, hopefully I will see the boss soon.

Great to see such detailed updates, keep up the good work 

[tigerwhit4]

Any idea when we will get a discord or telegram? I like discord better

[lokiverloren]

The discord is here:

https://discord.gg/nJKts94

Heh, you can all point at laugh at my folly with the 'no block sooner than 150 seconds' idea now... It made the chain fork very quickly More orphans than a Charles Dickens novel.

I am going to test just raising the difficulty adjustment window so it averages over a longer period next.

[trax0r]

New Parallelcoin pool and Parallelcoin explorer available:

http://kievpool.com
http://explorer.kievpool.com/

[Konowitz James]

I think it is a good project. Impeccable vision, a rather interesting website, wise project.