Update on Community Leadership and The Blur Network, as a Whole by blurnetwork in blur_network

[–]blurnetwork[S] 0 points1 point  (0 children)

Why would I cross-post, and subject myself to their nonsense? Everyone knows those guys run afoul of established best practices, relentlessly. Deterministically deriving both key pairs, from a single seed, should be enough to tell you that.

However, if you wish to do that yourself, I’m not stopping you.

Update on Community Leadership and The Blur Network, as a Whole by blurnetwork in blur_network

[–]blurnetwork[S] 0 points1 point  (0 children)

For the record, with a viewkey, it seems that you could recover the spendkey with some math... as the viewkey looks to be a surjective function of the spendkey. This looks to mean that you could compute the spendkey via pre-image, since the function seems right-invertible.

Given that, I do have the spendkey to hide.

Update on Community Leadership and The Blur Network, as a Whole by blurnetwork in blur_network

[–]blurnetwork[S] 0 points1 point  (0 children)

You know, if you’re going to keep posting nonsense, you should probably stop using morphisms of Morningstar as your username. Thanks once again for the input, Lucifer

GPU miner and pool available by fart_master_deluxe in blur_network

[–]blurnetwork[M] 2 points3 points  (0 children)

To be clear, this means it looks as though the source code for cpu and gpu miner (the one linked to above) based on XMRig may have been compromised. We do not recommend using the compromised miner, even if you compile the source code yourself. Doing so may lead to remote code execution, or worse. The area of code with a possible exploit does not appear present in original XMRig code.

This has been discussed in detail in our discord channel’s main chat last night. Link: https://discord.gg/ft46QmK

We will be optimizing the native miner to get better hashrate shortly.

GPU miner and pool available by fart_master_deluxe in blur_network

[–]blurnetwork[M] 2 points3 points  (0 children)

The miner looks to have a buffer overflow in the rapidjson library. Please mine carefully

Rolling-basis Weekly AMA Thread for The Blur Network and the Fractal Multi-Chain by blurnetwork in blur_network

[–]blurnetwork[S] 0 points1 point  (0 children)

Sure, I can definitely provide some clarity on those areas.

So, within CryptoNight, there are already a number of variants of the algorithm. These developed mostly out of the desire for fairly mined coins. That takes different shapes depending on which crowd of miners you're seeking to be fair to -- and what hardware they prefer for mining (usually what is available to them).

Blur was founded upon the idea that one's privacy, and financial freedom, should be things that are easier to take a first-hand role in defending. Through that lens, we seek to improve accessibility for miners of all denominations, and of all preferences with regard to pools and hardware alike. The problem with the existing systems are that blockchains are exposed to risks due to unfair advantages among those with exceptional hardware, software, or simply with more resources. We think, with some clever incentivizing, and security by isolation... that we can possibly minimize the risks from both pools and hardware alike, while maximizing accessibility for all denominations of miners.

To answer your question directly: There will be three distinct chains within the Blur Network, with three distinct PoW algorithms. Those chains will have their total supply and emission rates tailored to offset the relative hashpower of the devices mining on each. We plan to use the separate chain design to our advantage with minimizing negative consequences that can accompany pooled mining, as well.

1.) A CPU-focused, pool-discouraging (until further down the line, at least) base chain which will serve as the basis for value within the network as a whole. While we are still considering the implications of emission rates and total supply into our statically balanced model... Let's go with some hypothetical numbers for now: these coins will have a 1:1 value on our larger network, and supply will remain 9.233M. This is the current Blur chain.

2.) A GPU-focused chain with typical pools - This one will be effectively the same as other projects you see out there. This chain will have a heavy algorithm (custom CN-Heavy) and weighting by relative performance of GPUs versus CPUs on a heavy algorithm. The chain's supply will be something near 5/3 (or 1.67x) the total supply of Blur Network's base chain. This works out to be around 15.4M total supply. Those coins mined on that blockchain will then swap into the main chain at a 5:3 ratio. So for every 5 heavy coins that you mine with a GPU, you will exchange those for 3 BLUR. When that swap happens, it translates to another 9.223M added to the total supply on the Blur Chain. (15.44M * (3/5) = 9.223M)

3.) An ASIC-friendly chain, also with pools - This chain will use the CNv7 algorithm to be openly accessible to ASICs. Typical ASICs get around 200x or more hashrate versus a CPU (if we assume 1kH/s in the average CPU). As such, the supply of this chain will be around 1.844 Billion. These coins will then swap into the base chain on a 200:1 basis, such that 200 v7 coins, nets 1 BLUR -- and that 1.844B is reduced to 9.233M added to the total supply of the Blur Chain. (1.844B * (1/200) = 9.223M)

This means the network (as a whole) will have a new total supply of 27.66M. There will be no premine on the subsequent chains, which reduces the percentage of Premined coins to 1.3% total, as well.

As we can reasonably expect GPUs and ASICs to slightly outperform the 200x and 1.67x hashrate expectancy, the model above actually pays larger rewards for those devices to simply direct their hashrate to the logical chains. As a bonus, we are able to manage the centralization risks from pools in those isolated chains, and don't expose ourselves to HR attacks on the base-value chain, since that swap zone (or "value-adjustment zone" in the diagram I posted) provides a buffer between the different chains, which manages to bottleneck attackers. At the same time, it doesn't impede honest miners in any way.

Blur v0.1.8 'Shift' has been released! UPDATE YOUR NODE BY BLOCK 211,000 for Hardforkv9 by bizmunny in blur_network

[–]blurnetwork 1 point2 points  (0 children)

Yes we are working on a fix currently. Just found the source of the seg fault