Bitcoin Forum
June 18, 2019, 06:17:58 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33 34 »
  Print  
Author Topic: [ANN] ParallelCoin - DUO - SHA256 + Scrypt | Community Takeover  (Read 50117 times)
lokiverloren
Newbie
*
Offline Offline

Activity: 68
Merit: 0


View Profile
June 08, 2018, 06:44:59 PM
 #521

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560881878
Hero Member
*
Offline Offline

Posts: 1560881878

View Profile Personal Message (Offline)

Ignore
1560881878
Reply with quote  #2

1560881878
Report to moderator
1560881878
Hero Member
*
Offline Offline

Posts: 1560881878

View Profile Personal Message (Offline)

Ignore
1560881878
Reply with quote  #2

1560881878
Report to moderator
1560881878
Hero Member
*
Offline Offline

Posts: 1560881878

View Profile Personal Message (Offline)

Ignore
1560881878
Reply with quote  #2

1560881878
Report to moderator
chey
Sr. Member
****
Offline Offline

Activity: 367
Merit: 250

I'm a miner not a minor.


View Profile WWW
June 09, 2018, 12:53:19 PM
 #522

I'm speechless


██
██
██
1st Stake
Android Wallet
████████████████████████████████████████████████████████████████████████████████
Transfercoin
████████████████████████████████████████████████████████████████████████████████
              ▄▄█▀▀▀▀▀▀▀▀▀▀▀█▄▄
          ▄█▀▀▀ ▄▄▄▄█████▄▄▄▄ ▀▀▀█▄
       ▄█▀▀▄▄█████▀ ▄▄▄▄▄ ▀█████▄▄▀▀█▄
     ▄█▀ ▄████▀▀▀ ▄███████▄ ▀▀▀████▄▀▀█▄
   ▄█▀ ▄███▀  ▄██ █████████ ██▄  ▀███▄ ▀█▄
  ▄█ ▄███▀ ▄████▀ ▀███████▀ ▀████▄ ▀███▄ █▄
 ▄█ ▄███  ████▀     ▀▀▀▀▀     ▀████  ███▄ █▄
▄█ ▄███  ███▀                   ▀███  ███▄ █▄
██ ███  ███▀                     ▀███  ███ ██
██ ███  ███                       ███  ███ ██
██ ███  ▄▄▄▄▄                   ▄▄▄▄▄  ███ ██
██ ██ ▄███████▄               ▄███████▄ ██ ██
▀█ ▀█ █████████               █████████ █▀ █▀
 ▀█ █ ▀███████▀               ▀███████▀ █ █▀
  █▄ ▀▄ ▀▀▀▀▀ ▄██▄▄       ▄▄██▄ ▀▀▀▀▀ ▄▀ ▄█
   ▀█▄ ▀███▄  ▀▀█████████████▀▀  ▄███▀ ▄█▀
     ▀█▄ ▀████▄    ▀▀▀▀▀▀▀    ▄████ ▄▄█▀
       ▀█▄▄▀▀██████▄▄▄▄▄▄▄██████▀▀▄▄█▀
          ▀█▄▄▄ ▀▀▀▀█████▀▀▀▀ ▄▄▄█▀
             ▀▀█▄▄▄▄▄▄▄▄▄▄▄█▀▀
██
██
██
kurbeks
Sr. Member
****
Offline Offline

Activity: 924
Merit: 255


View Profile
June 10, 2018, 12:40:44 PM
 #523

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
Sr. Member
****
Offline Offline

Activity: 367
Merit: 250

I'm a miner not a minor.


View Profile WWW
June 10, 2018, 02:42:56 PM
 #524

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

You raise a valid point.  Undecided

██
██
██
1st Stake
Android Wallet
████████████████████████████████████████████████████████████████████████████████
Transfercoin
████████████████████████████████████████████████████████████████████████████████
              ▄▄█▀▀▀▀▀▀▀▀▀▀▀█▄▄
          ▄█▀▀▀ ▄▄▄▄█████▄▄▄▄ ▀▀▀█▄
       ▄█▀▀▄▄█████▀ ▄▄▄▄▄ ▀█████▄▄▀▀█▄
     ▄█▀ ▄████▀▀▀ ▄███████▄ ▀▀▀████▄▀▀█▄
   ▄█▀ ▄███▀  ▄██ █████████ ██▄  ▀███▄ ▀█▄
  ▄█ ▄███▀ ▄████▀ ▀███████▀ ▀████▄ ▀███▄ █▄
 ▄█ ▄███  ████▀     ▀▀▀▀▀     ▀████  ███▄ █▄
▄█ ▄███  ███▀                   ▀███  ███▄ █▄
██ ███  ███▀                     ▀███  ███ ██
██ ███  ███                       ███  ███ ██
██ ███  ▄▄▄▄▄                   ▄▄▄▄▄  ███ ██
██ ██ ▄███████▄               ▄███████▄ ██ ██
▀█ ▀█ █████████               █████████ █▀ █▀
 ▀█ █ ▀███████▀               ▀███████▀ █ █▀
  █▄ ▀▄ ▀▀▀▀▀ ▄██▄▄       ▄▄██▄ ▀▀▀▀▀ ▄▀ ▄█
   ▀█▄ ▀███▄  ▀▀█████████████▀▀  ▄███▀ ▄█▀
     ▀█▄ ▀████▄    ▀▀▀▀▀▀▀    ▄████ ▄▄█▀
       ▀█▄▄▀▀██████▄▄▄▄▄▄▄██████▀▀▄▄█▀
          ▀█▄▄▄ ▀▀▀▀█████▀▀▀▀ ▄▄▄█▀
             ▀▀█▄▄▄▄▄▄▄▄▄▄▄█▀▀
██
██
██
MiguelEl
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
June 10, 2018, 02:53:34 PM
 #525

Greetings, DEV's. I wish you success
marcetin
Legendary
*
Offline Offline

Activity: 1068
Merit: 1002


Crypto Radical-Utopist-Techno Freak-Border Tester


View Profile WWW
June 10, 2018, 04:28:50 PM
Last edit: June 10, 2018, 05:03:40 PM by marcetin
 #526

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 Smiley



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



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.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  BITNODES   MANAGED NODE VPS HOSTING SERVICES    SUPPORT YOUR COIN WITH A NODE 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
My fellow members, ask not what the community can do for you, ask what you can do for the community. CCW-WebRes-BitStickers-Freshcoin-AnonStickers.shop-ParallelCoin

The Secret of Success is to find out where people are going.. and get there first! - Mark Twain
Bitrated user: marcetin.
lokiverloren
Newbie
*
Offline Offline

Activity: 68
Merit: 0


View Profile
June 10, 2018, 07:47:07 PM
 #527

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 Smiley 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
Sr. Member
****
Offline Offline

Activity: 924
Merit: 255


View Profile
June 10, 2018, 09:17:35 PM
 #528

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 Smiley



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



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
Newbie
*
Offline Offline

Activity: 68
Merit: 0


View Profile
June 10, 2018, 10:09:06 PM
 #529

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
Sr. Member
****
Offline Offline

Activity: 367
Merit: 250

I'm a miner not a minor.


View Profile WWW
June 11, 2018, 04:50:50 PM
 #530

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?

██
██
██
1st Stake
Android Wallet
████████████████████████████████████████████████████████████████████████████████
Transfercoin
████████████████████████████████████████████████████████████████████████████████
              ▄▄█▀▀▀▀▀▀▀▀▀▀▀█▄▄
          ▄█▀▀▀ ▄▄▄▄█████▄▄▄▄ ▀▀▀█▄
       ▄█▀▀▄▄█████▀ ▄▄▄▄▄ ▀█████▄▄▀▀█▄
     ▄█▀ ▄████▀▀▀ ▄███████▄ ▀▀▀████▄▀▀█▄
   ▄█▀ ▄███▀  ▄██ █████████ ██▄  ▀███▄ ▀█▄
  ▄█ ▄███▀ ▄████▀ ▀███████▀ ▀████▄ ▀███▄ █▄
 ▄█ ▄███  ████▀     ▀▀▀▀▀     ▀████  ███▄ █▄
▄█ ▄███  ███▀                   ▀███  ███▄ █▄
██ ███  ███▀                     ▀███  ███ ██
██ ███  ███                       ███  ███ ██
██ ███  ▄▄▄▄▄                   ▄▄▄▄▄  ███ ██
██ ██ ▄███████▄               ▄███████▄ ██ ██
▀█ ▀█ █████████               █████████ █▀ █▀
 ▀█ █ ▀███████▀               ▀███████▀ █ █▀
  █▄ ▀▄ ▀▀▀▀▀ ▄██▄▄       ▄▄██▄ ▀▀▀▀▀ ▄▀ ▄█
   ▀█▄ ▀███▄  ▀▀█████████████▀▀  ▄███▀ ▄█▀
     ▀█▄ ▀████▄    ▀▀▀▀▀▀▀    ▄████ ▄▄█▀
       ▀█▄▄▀▀██████▄▄▄▄▄▄▄██████▀▀▄▄█▀
          ▀█▄▄▄ ▀▀▀▀█████▀▀▀▀ ▄▄▄█▀
             ▀▀█▄▄▄▄▄▄▄▄▄▄▄█▀▀
██
██
██
trax0r
Full Member
***
Offline Offline

Activity: 278
Merit: 101

Coinz-Universe


View Profile
June 11, 2018, 05:30:21 PM
 #531

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
Jr. Member
*
Offline Offline

Activity: 55
Merit: 2


View Profile WWW
June 12, 2018, 12:58:16 AM
 #532

But mining DUO right now is still big problem.

https://bitstickers.net ◆ https://anonstickers.shop ◆ https://bitnodes.net
lokiverloren
Newbie
*
Offline Offline

Activity: 68
Merit: 0


View Profile
June 12, 2018, 07:37:29 AM
Last edit: June 12, 2018, 07:50:50 AM by lokiverloren
 #533

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
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile WWW
June 13, 2018, 09:26:36 AM
Last edit: June 22, 2018, 01:27:33 AM by tigerwhit4
 #534

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  Wink
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
Sr. Member
****
Offline Offline

Activity: 924
Merit: 255


View Profile
June 13, 2018, 09:35:54 AM
 #535

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

Add also scrypt, plz Smiley
lokiverloren
Newbie
*
Offline Offline

Activity: 68
Merit: 0


View Profile
June 13, 2018, 12:24:29 PM
 #536

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
Jr. Member
*
Offline Offline

Activity: 170
Merit: 3

I need a break!


View Profile
June 14, 2018, 01:16:22 AM
 #537

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  Grin

I'll take any freebies on offer Smiley
tigerwhit4
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile WWW
June 14, 2018, 04:07:51 AM
 #538

Any idea when we will get a discord or telegram? I like discord better
lokiverloren
Newbie
*
Offline Offline

Activity: 68
Merit: 0


View Profile
June 14, 2018, 06:34:55 AM
 #539

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 Smiley 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
Full Member
***
Offline Offline

Activity: 278
Merit: 101

Coinz-Universe


View Profile
June 21, 2018, 04:29:06 PM
 #540

New Parallelcoin pool and Parallelcoin explorer available:

http://kievpool.com
http://explorer.kievpool.com/
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33 34 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!