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

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

More of this topic now on bitmax.io,too. There you can even see the ICO of duo.network, which is in my eyes a try to scam people, as they are using the well known DUO name for their ICO. See:
https://bitmaxhelp.zendesk.com/hc/zh-cn/articles/360022073753-DUO-Network-DUO-%E9%A2%84%E5%94%AE%E5%85%AC%E5%91%8A

I also wrote an email to bitmax.io regarding this topic of confusing danger, asking them to either remove or rename this ICO immediately.
Let´s see which answer I will get.

I need to inform about a serious topic I came across today:

Some guys in Singapore started an ICO with the name DUO.Network (webpage is also duo.network).

Not only that they called their ICO DUO, they also started now to go public and adding their ICO to specific coin exchanges and info pages.

Today i found DUO on hotbit.io, an exchange in Asia. They added trading-pairs DUO/BTC and DUO/ETH. These trading pairs there have nothing to do with DUO/Parallelcoin, as they belong to duo.network.

WARNING: Do not try to send any DUO/Parallelcoin to any duo address generated on hotbit, as your coins will be lost forever.

What I did do today about this topic:
- I wrote an email to Hotbit.io, sending proof of DUO/Parallelcoin and explaining the situation, including asking to remove immediately their false DUO trading pairs from their exchange, OR to rename the trading pairs to something else/another name, so there is no confusing danger.
- I wrote a message to duo.network to ask them to stop using the short name DUO on coin exchanges and other info pages.

Let´s see what I will receive as answer from hotbit.io and from duo.network.

Well, the only DUO scrypt pools I know of are:

https://www.mining-dutch.nl/pools/parallelcoin.php
http://zergpool.com/

On mining-dutch.nl someone was mining DUOs today...

BTW is there any scrypt pools available? As ones listed on ANN are only SHA256. thanx!

currently not many mining... so low block times....
I think after the planned fork there will be many trying to mine the coin, as even CPU multi-algo mining will be possible again....
let´s wait and see...

good coin but seems to me slow blockchain((( I was waiting confirmation of 1 mined block for 24 and more hours((((

I wrote today to Cryptopia to check, when DUO will be readded as active market. Let´s see what I get as answer.

Yes all my DUO, I should of known better but got a bit Lazy

At least they are not gone forever, I just have to wait until Cryptopia open withdrawals 

Rick

Crazy.. you have all your DUOs stuck on Cryptopia?

I think the problem with DUOs being stuck in Cryptopia will be solved within the next one or two months.

Yesterday Cryptopia posted that half of their coins on the exchange have been secured and a lot of coins can already be traded again. Withdrawel on Cryptopia is another topic, I guess we will have to wait much more to have successful withdrawal at Cryptopia again.

Wow looking good guys

I have not posted in a while because my DUO are still stuck in Cryptopia

I really cant wait to see what the next year brings for this project, lokiverloren's hardwork is sure to be noticed by the mainstream soon.

Rick

Congrats ... and thank you for all the dev work you have done by now... i am looking forward to the release

Really short quick one -

I just finally got all three main components working

- Full node so far mostly reliably syncs and responds to RPC

- CLI RPC client works, connects to node and wallet, prints help correctly

- Wallet now connects to and syncs with full node.

There's lots of little niggles amongst it, as you would expect, but maybe within a day or so I will have it stable and the combined node/wallet "shell" mode working, the bottleneck that has been holding up the show for the last two months.

Well, it is my first time building a working blockchain application

I think I am now past the top of the hill, work-wise and patience-for-dragging-on-wise. I'm pushing myself from now extra double hard to make the milestones and catch as many of the clangers as I bump into.

Something that makes me think of as relates to the new suite going live - I will build a small webserver and run it behind a tor hidden service (for your privacy) that will receive crash reports. I'll have to add a setting for it, enable/disable automatic submission of reports. The reports will be just tracebacks sufficiently long to point me in the direction of the probable causes, and yes, you will have to manually set it to on and the GUI will also have an alert when pending reports can be checked and manually sent in if the user has opted in to help with this. No, I won't want it nagging you, just one 'dismiss' popup on first run and that's all, at least during the first three months it goes live.

We are getting closer to the release....
It is time to save some DUOs now - even our dev loki started yesterday to fill his wallet
The DUO price is currently so low, you will not find DUOs later again at this low rate ....

while I am in pause mode, I elaborated a bit more on the hashing algorithm.

https://git.parallelcoin.io/dev/9/src/branch/master/doc/complexpow.md

https://git.parallelcoin.io/com/assets/raw/branch/master/complexpow.jpg

Sorry, image isn't previewing because of my newbie status. But you will be able to see even with this provisional process graph that asics would have problems getting around the need for sending hashes between processing stages as a bottleneck, as well as squelching a lot of the possible optimisations from convenient ordering. I think we may yet put an Equihash Pow into the graph in a parallel stage connected to some of the other graphs in a messy-as-possible way.

It only really needs to see the chain through until we have the next generation asynchronous protocol working, I think it should happily succeed at giving us a year's grace.  Very probably minor changes, like pushing results from stages into even more intermediate stages likely would further reduce any working asic's efficiency, even if its processing path is fully programmable, and maybe by then Fluffybunny and other asic warriors will probably have got even better hashes to add to the process.

I can increase the complexity quite a lot without increasing the total time per hash. You can conceive easily of further complexity by adding logic gates that send hashes to different processing stages depending on part of their value... But I think it doesn't have to go much further than this to the point the proof is of bus interconnect and nothing else bigger constrains it. This is the most complicated and expensive part of any motherboard, the PCI express bus and the cpu-memory interconnect. No matter what way you slice it, the algorithm will congest this channel and leave a lot less options for improvement open.

maybe a whitepaper

I started writing this as a roadmap but ended up blathering on and decided that it's almost right for the white paper.

The TL;DR version is basically that we want to implement a proof of causality logic-clock based ledger, and build a framework to replicate the ledgers of other coins, including retaining their proof of work for issuance rate control purposes. Coins that do this get the sub-second transaction finalisation of the new protocol while keeping their issuance control and development of their ledger protocol is entirely independent.

We want to build a new network that can support a swarm of affiliated cryptocurrency projects, small, low cap, poor resources, with enthusiastic people.

By implementing several coin ledgers on one base protocol, it becomes simple to enable cross-coin atomic swaps in-band. The network can track the exchange rates and produce price charts as well.

Ok, just a brief report...

I now have got the full node launching though the ctrl-c interrupt handler isn't properly wired in. I should have all of the servers running again on the new 9 repository by tomorrow. The critical thing is getting the combined 'shell' launcher done, this is a combined full node and wallet node connected to the full node.

Once that launcher is done we start on the wallet GUI and I can finish the hard fork transition code and finalise the proof of work (I think I may make it a little more complex still, put some more simple hashes with more complex directed graph of processing steps disrupting linearisation.

I know it's not going to be perfect, proof of work is just the first working open-entry protocol architecture, it's pre-model-t grade, but even if for some reason every asic maker were to suddenly want to make miners for duo, we still have 6 months grace for their production cycle and either it will be structurally rearranged at that point or we might have got to a new protocol (i doubt it).

The essence of what we are doing next is fairly simple - think of Lightning and its cross-chain transactions, and then flip that upside down. Put it inside an environment a bit like Bitshares, with multiple, user issued tokens, except instead of just making a proxy for trading the token, we emulate it down to the last detail, as well as creating a PoW regulated coinbase issuance consensus, but this PoW does not regulate processing of blocks, only the timing of new coinbases being issued.

In other words, what we want to do next is build a proof of causality/logic clock based consensus, which can run a token without a PoW to stop double spends, and then create a PoW anyway, but it is only for issuance control and not for double spend security. Then with two or more such different ledgers implemented on the same platform, it is far simpler to add a cross chain settlement protocol and the network keeps track of the ratios of values between different subtokens.

Or in other words, we intend to build a base protocol that can be used to implement the ledger format and proof of work of other coins, and, of course, selecting other small cap and nearly-abandoned coins, offering to add their token in a coinswap process and our chain becomes the master, but their protocol plugin remains under the control of the user community and devs.

It's an excellent deal: share exposure to exchanges for the other coin, and a new market for parallelcoin.

The idea is that it allows the usually hodge-podge of dev skillsets available on each project could merge related work together, effectively growing a development team by mergers.

Forget bitcoin maximalism. How about network integration. Lightning is a nice idea but settling cross-chain transactions actually doesn't really solve any problems relating to latency. It does allow faster clearance when both sides of an exchange are using lightning but those on main net still have the congestion and scalability problem.

With both chains on an underlying common platform, the platform can be the site of implementing these token exchanges, it can track the price and history and you don't even need an exchange if all your trading partners are using tokens on the same protocol.

Ok! well, just don't keep asking for news if you don't mind.

no candyx is not me.

I am still banned have never seen a direct reply to me
I am not a heavy discord user, so I don't know how to access my dm's if you have I have not seen them.

My intentions are to support, have never done anything bad.

Good news today:

Parallelcoin (DUO) was listed on Altilly today:



You are welcome to visit Altilly exchange and exchange there your BTC and XQR to DUO:
https://www.altilly.com/market/DUO_BTC
https://www.altilly.com/market/DUO_XQR