Topic: [ANN] ParallelCoin - DUO - SHA256 + Scrypt | Community Takeover - page 17. (Read 61159 times)

But mining DUO right now is still big problem.

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

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

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.

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.

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.

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.

---

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.

Greetings, DEV's. I wish you success

You raise a valid point. 

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

I'm speechless

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. My name is Loki.

I have been working on a golang version of Parallelcoin, based on Piotr Narewski's Gocoin, and I had just reached a point where the new client was sucking up blocks from the network, and I became aware there was some kind of problem with the network.

As a result of this bit of edification, I switched over for a couple of days to just messing with the ancient version as on Marcetin's repository, and I explored how the thing works between a couple of machines in my apartment (a slow old laptop and a desktop with an i5) and determined with many experiments and changes and staring at server logs, that there will be a number of pre-go-fork changes that will help encourage people to actually use this coin. I have these changes all ginned up on another repository and I've even worked up the required push but I wasn't given any access yet to the main repo so it's sitting idle on my hard drive.



1. Maximum percentage of difficulty adjustment *will be* doubled.

The reason for this is some lazy-ass bugger has taken to dropping in on the network and spewing blocks at it. The doubling of the difficulty adjustment will reduce the spewiness of their little farm of SHA256D miners a tad, well, by twice as much as it is now, per block. I considered making the adjustment more aggressive but then discovered the chain requires a block to arrive before it recomputes difficulty (more on this in a little). This will raise the cost of their slovenly grasping by about double, over the 10 or so blocks they typically grab, and maybe that will mean they go away. Well, it's not enough to make them go away, I think. The issue is simply that for hours, sometimes half a day afterwards, nobody else wins a block.

(This is partly you all's fault for not mining it with scrypt)

2. Minimum difficulty has been lowered. I dunno how many other blockchain engineers there are reading this, but scrypt is like 10-100x slower than sha256. On my i5, at minimum difficulty (bits=1e00ffff) I find a solution with 4 cores on average about every 3-7 minutes. This is way too high a minimum difficulty, considering nobody is actually mining it with scrypt.  Lowering it to this more reasonable level will mean that even just a few people running the node with -gen turned on will disrupt these long bouts of silence from the network. It's not a change that will affect sha256 mining, unless suddenly everyone turns off their miner, which is unlikely, although it seems like there's not many mining anyway.

3. We can change the chain to have 30 second blocks. Why not? Along with this tenfold reduction in block time, the block reward will also be reduced by the same factor, but you can get the same number of tokens in the same time, just that there will be more blocks involved.

I really wish I could quickly and as easily add a consensus rule that downgrades difficulty after the block window passes, but I am not really a C++ programmer and as a programmer in general, the cryptic nature of C++ is quite repulsive to me (I was hired to code in go, so, as expected). This is a change that will be first cab off the rank when I finish the gocoin fork. I simply had no idea how much of an abandoncoin, exactly, that I was dealing with, and it's amazing, and probably a testament to the loyalty of you all, that it's still not been completely delisted into nonexistence despite the glaring problems with the network.

Anyway, to give a teaser of what is planned other than such dry and dowdy things as the above (which are still pretty cool, really):

1. Masternodes - not staked! Simply, you will be able to get a share of the block reward for keeping the p2p network and make available the blockchain data to anyone who requests it. Anyone caught running a masternode that seems to be alive and serving data within a short time period will be eligible for winning the next block reward share. I am tentatively setting it at 10%, and the network will reject blocks that don't pay a masternode, or try to pay one other than the deterministically selected one (based on a hash of a specific recent block, maybe 20 back, maybe the head, I'm not sure yet).

Marcetin and I both agree that staking is an artificial incentive and market-manipulation attempt, so simply you will get paid to configure one of the new DUOD nodes to serve the chain up.

This is an interim step towards further enhancements, of course. This is a site in the architecture where I see an opportunity to start developing a SporeDB-based BFT type system. After the change is implemented, syncing to a new node will only require selecting a trusted node, and then it will slurp the whole chain directly in the form it is stored by the server (The gocoin fork squashes the data about 30%, btw, so not 128Mb but more like 90Mb right now) and the chain index, and no need to actually replay it. At your option - this is one of the reasons for doing this - you can always just sync the old fashioned way, but with this new feature, after about 150Mb of download, at most, right now, your node is up and running and answering queries. For most of you that means about 10 minutes. Replay takes about 90-120 minutes currently, and if these features make this a desirable cryptocurrency, that's indubitably going to get way worse in the next 2 years.

2. Progressive Web App GUI wallet delivered directly from your node. No more scratching around for a GUI wallet to use. Literally you will be able to point your browser at it, and tell chrome to install it as an app, and it will work also offline. The Gocoin codebase includes a fiddly CLI cold wallet as well, this will be beefed up to become a browser app also, so despite being offline, you will have the convenience of 30 years of WWW experience delivering you cold wallet functionality without forcing you to learn how to type. We likely will think about enhancing this app further to enable it to be the basis of a web wallet, that anyone can spin up in an hour and serve. I personally am wary of foreign code, so you can be sure that I will be making sure you know it's the legit, real version that you can read or pay someone to read the source of to assure you that it's not stealing your keys.

And that's just the beginning. It is Marcetin's plan also to leverage the power of this community towards growing the system to more than just a cryptocurrency. I have been working on a design for over a year now, for an extensible, modular, HARD (ie native) smart contract platform system that will include a democratically monetised forum, messaging system, distributed exchange network (including tools to help people bind in other cryptos), and the thing that is my most favourite, a gitlab type application that runs on the network that lets you get paid to code, and of course, a distributed marketplace. But we don't stop there, next stop after this is an anonymous routing system, the option to get paid for providing anonymous relay service, and eventually, the ability to launch a whole application on the network, that has the smarts to be able to run a multiplayer action game at sub 100ms latency in a massive (probably continent-bound) environment.

It is now possible to use cloud mining on Parallelcoin - check out this link:

https://www.cryptostar.asia/miner/ParallelCoin

Hint: I have no idea if this service is any good. I just found it on the net. Maybe if someone tries it, please post a review on it.

Thank you Marcetin, and good work, it really does look like DUO has a great future, I just cant wait

Hi Rick,

Glad to see more people show interest in ParallelCoin

https://join.slack.com/t/parallelcoin/shared_invite/enQtMzYzOTU5OTc0NzkwLTZhZWRmZDUyYjUxNzJkM2UxYjJkODM3Mjk2ODJkNjk1M2E4ZDM5NTkxMTZjODdmMjljNDE2MTkwM2FjMTg3YmM

Hi Guys
I can't join https://parallelcoin.slack.com It says I need an invitation, can an admin please send me one ?
Thanks
Rick

Great news, the future is looking great for parallelcoin

The new dev joined today the team... his name is l0k1.
He will be doing the update of DUO wallet and fix latest security issues (and more).
 
Join Parallelcoin on Slack to see latest developments and news:
https://parallelcoin.slack.com

Yes, really good to see things are moving. I am very excited of all the things to come over the next year.

Good to see that communities take over and try to revive a coin, wish more communities could do that!