[ANN] [POW] [MSR] Masari - simple, scalable, and secure cryptocurrency

[thaer]

@jbmustaq that's typical behavior of exchange bots if there's low volume to try and suppress the current price for their buy order, this is normal

MSR is currently underpriced on the exchange (https://www.southxchange.com/Market/Book/MSR/BTC). There will only ever be ~18 million total of these minted, and we're currently at around 1 million - adjusted for average mining costs (at this time, and historically it has been much higher) it's currently worth at least 1100 satoshis each so this is a great opportunity to buy!

[1714969114]

1714969114

[1714969114]

1714969114

[1714969114]

1714969114

[1714969114]

1714969114

[1714969114]

1714969114

[jbmustaq]

Yeah I already have ample coins but I am not going to sell them. I have spent money and time not going to sell them for less at all.

[normanski]

We have a work-in-progress landing page that is much better than what we had before! You'll find useful links, and in the future will get live information about network hash rate, prices, etc., and there will be a section for announcement updates!

http://www.getmasari.org/

nice design, great work dev!

I'm glad you have a mobile wallet in the roadmap, introducing mobile integration is  great since it can lead to mass adoption.

[Xeon_Xeon]

Interesting project, installed and am currently mining with wallet-cli.

[suports]

I had no experience with the purse, I'm a noob. whether it is possible to recover the wallet? there's not a lot of coins, but all I would like to get them back to your new wallet.

[cryptomaxsun]

 what API-port the https://masari.superpools.net/ for http://msr.ms-pool.net.ua/#network

[thaer]

I had no experience with the purse, I'm a noob. whether it is possible to recover the wallet? there's not a lot of coins, but all I would like to get them back to your new wallet.

if you know what your seed is (the 25 word mnemonic), you can recover your wallet with the following command

Code:

 ./masari-wallet-cli --restore-deterministic-wallet  

and paste/type in your seed when prompted.

[nanona]

This chain is about to get stuck for many hours. Some idiot is attacking it right now with 20x its global hashrate to push the difficulty to the moon.
Once it is done, the moron will piss off and laugh at the 80kH/s of genuine miners wasting their electricity for hours and hours.
Since the attacker is not willing to mine 24/7 and pay the cost for the difficulty he is creating, it is indeed an attack and it should be countered by banning the fucking moron.
The pool operator should be able to see it in his backend. Let me guess, a monkey with a rented gun from nicehash.

What good is ASIC resistance and its implied decentralisation for if an idiot can rent 20x the global hashrate of a coin from nicehash to wreak havoc.
Fortunately he is too stupid to set up his private pool and do other kind of attacks which would be much worse.

Here, I found him.
https://www.youtube.com/watch?v=GhxqIITtTtU

[nanona]

The attacker remained a bit longer this time and mined at high difficulty. But once he noticed he couldn't drive it higher, he left.
The chain is now mined by 60kH/s and blocks will be very slow for quite some time.

The last such large attack happened 24h ago. I am not counting the many smaller attacks within the last 24h.
Yesterday the attacker left around block 35300 when the difficulty was around 50M. However the difficulty adjustment
behaved very badly because even though hashrate was low after the attack and blocks were coming in at only
one per hour, it increased the difficulty without any sense until 160M and the chain became stuck for several hours.

We know that the network hashrate is derived from the difficulty and it does not reflect the real hashrate at any moment.
The pool hashrate however is accurate since it is derived from the real shares submitted by the workers.

I suggest therefore that the dev and the pool operator of superpools go over the pool's logs to see exactly
when the attacker entered and when he left and how the difficulty adjustment reacted or rather how it should react better.

Clearly it makes no sense whatsoever to increase the difficulty when the last block was an hour ago, no matter how fast the blocks
were coming previously. There must be a long window and a short window to monitor, as well as the time between the last very few blocks.
Depending on how the measured average block times in each of these windows match or rather not match, priority must be given to the one closer to present time.

[thaer]

@nanona

Thank you for your feedback, I'm aware of the mining adversary in the Masari network. The current difficulty calculation in place is based off a linear combination of the average and median timespans, and it does effectively address these flash mining issues. However, it could be improved on, and will likely see updates in future protocol upgrades that would include as part of the equation a percentile from the timespan distribution. This is a statistically tricky problem, as we can't simply skyrocket difficulty and spin it back down since this is a decentralized system, and can only estimate difficulty based on block timespans. In consultation with a statistician, any future improvements will have to involve mining simulations to get the correct linear combination of observed parameters, which may also include adjusting the block timespan and cut windows.

With all that said, since the new algorithm in place is doing well (derived from and thanks to Sumokoin), an alternative solution is to add more features which will increase demand and organic hash rate, effectively muting these flash mine attempts.

If you have any suggestions, or more questions, I'm more than happy to have this discourse with the community.

[nanona]

The difficulty adjustment works well now when the hashrate is skyrocketing. It is too slow however to re-adjust when the hashrate suddenly drops, like from 1.1MH/s to 55kH/s.
This happened right now when the latest attack stopped at block 36086 with the difficulty at 131M. The next block was found only after exactly one hour.
You would expect the difficulty to drop significantly, but it went up to 144M.

The pools are actually the ones who see what is really happening since they do directly measure the actual hashrate the miners contribute to the network through them in every single second.
I could imagine a re-target method where the pools are communicating the actual hashrate that is pointing at them. This way the adjustment could be done as hashrate joins or leaves.
The current systems in use only react after the fact by looking at the timestamps of previous blocks, which is always too late and inaccurate anyway.
Already because faster or slower blocks due to natural variance will emulate a higher or lower hashrate, which means the adjustment will be fooled by hashrate increase or decrease which simply doesn't exist.
Of course that would open up also many attack vectors and it might be not viable at all.

[thaer]

All a pool is, is a miner node distributing its work to other miners, giving them some sort of quorum capabilities as part of the protocol would be pretty bad since it centralizes control of block emission.

Your idea goes towards decentralized governance like Dash's model, but that has some heavy restrictions with respect to voting and like you mentioned can't be applied to block difficulty without opening attack vectors on the network.

P.S the Masari network has adjusted quickly enough and has been emitting blocks within reasonable times in the last 10 or so blocks - happy mining!

[Asinetwork]

The difficulty adjustment works well now when the hashrate is skyrocketing. It is too slow however to re-adjust when the hashrate suddenly drops, like from 1.1MH/s to 55kH/s.
This happened right now when the latest attack stopped at block 36086 with the difficulty at 131M. The next block was found only after exactly one hour.
You would expect the difficulty to drop significantly, but it went up to 144M.

The pools are actually the ones who see what is really happening since they do directly measure the actual hashrate the miners contribute to the network through them in every single second.
I could imagine a re-target method where the pools are communicating the actual hashrate that is pointing at them. This way the adjustment could be done as hashrate joins or leaves.
The current systems in use only react after the fact by looking at the timestamps of previous blocks, which is always too late and inaccurate anyway.
Already because faster or slower blocks due to natural variance will emulate a higher or lower hashrate, which means the adjustment will be fooled by hashrate increase or decrease which simply doesn't exist.
Of course that would open up also many attack vectors and it might be not viable at all.

If the adjustment back down worked so fast how do you regulate the amount of blocks found per 24 hour period? Should be 720 Blocks per day right? When some idiot uses nicehash and runs difficulty up they hit blocks well to fast and once they stop the network needs to change difficulty. In Theory  If some one nice hashed in a few hours all 720 blocks then the network should not produce more blocks for next 20 hours or so. If it does readjust in like 2 hours then you would produce more than 720 blocks per day?

[nanona]

The attacker is simply waiting for the difficulty to drop below a certain threshold and then returns. After the remaining 50kH/s of permanent miners brought the difficulty down from 100M+ to 20M after two hours, the attacker returned, this time with even more hashrate. Currently nearly 3MH/s, which is insane for a network that works usually at 100kH/s. Difficulty is now above 300M. Good thing is the uptick adjustment works, or we would currently see more QE than at the Fed, ECB and BOJ.

> This whole issue in general is a good sign because it shows the value being attributed to Masari

It makes economically no sense what he is doing. Instead of pointing 4,000 GPUs to mine MSR against a huge difficulty he is generating, he could simply point 50 GPUs 24/7, keep the difficulty low and get the same amount of coins at much much lower cost.

Anyone with such a farm knows this. Therefore this is certainly not someone with a huge farm but some dummy using rented hashrate. I mean how long and how many attacks do you need to notice that difficulty goes up quickly every time and your 4,000 GPUs are suddenly as good as 100 GPUs previously. Or he is trying to break something, that would make more sense.

[nanona]

If the adjustment back down worked so fast how do you regulate the amount of blocks found per 24 hour period? Should be 720 Blocks per day right? When some idiot uses nicehash and runs difficulty up they hit blocks well to fast and once they stop the network needs to change difficulty. In Theory  If some one nice hashed in a few hours all 720 blocks then the network should not produce more blocks for next 20 hours or so. If it does readjust in like 2 hours then you would produce more than 720 blocks per day?

The network needs to and does change difficulty much earlier than "once he stops". He therefore can't mine 720 blocks within a few hours. Especially not since the V2 fork which implemented a more aggressive difficulty adjustment. If we would wait until "he stops", he would never stop and mine all 18.5M coins in no time.

[thaer]

Regarding Nicehash, if it is the case here, these flash mine attempts typically take around 30 minutes, and with respect to valuation would have cost the miner 1800+ satoshis / MSR **, more than 4x the current exchange rate at SouthXchange. This is either an attempt to harm the network regardless of cost, or their mining costs are lower than Nicehash's (if it's not).


** (estimating 2.5 MH/s, roughly 30 blocks were involved ending around block #36130, currently costing ~0.35 BTC/MH/day as a "fixed" rate on Nicehash, costing 0.018 BTC for that half hour, and 0.018 / (33 * 30) = ~1800 satoshis per MSR)
edit: corrected calculation based on 2.5 instead of 3 MH/s

[nanona]

The attacker is gone again, leaving the difficulty at 350M. Superpools has around 30kH/s, masaripool around 60kH/s and ms-pool has around 5kH/s.
Good luck to the remaining permanent miners. It will probably take 5-10 hours this time until the difficulty is again down to a level which reflects their hashrate, at which point they will start to earn some coins again. This is unless the attacker won't return just then, get 99% of all block rewards again and rinse repeat.

The operator of superpools can see in his backend where the hashrate is coming from. He has recently added a port specifically for Nicehash mining. As far as I remember this cryptonote universal pool has ways to block miners if they are considered to be malevolent, e.g. by detecting things like low diff attacks and then blocking their IP.

[aix514]

what makes the MSR coin different from Sumokoin or AEON coin? will this coin be listed on  coinmarketcap.com?

regards,

[Littledragons]

^ that all depends on when an exchange picks it up

[thaer]

@Littledragons it's already up on SouthXchange - any more exchanges listing MSR will be promptly announced!

@bitnod the Masari network's difficulty adjustment algorithm is responsive and resistant to flash mining attempts, and isn't determined by any pool behaviour - the network difficulty jump you saw was MSR reacting to an increased hash rate detected by block emission rates and adjusting to maintain ~2 minute block times.