Topic: Vertcoin - First Scrypt N | First Stealth Address - Privacy without mixer - page 120. (Read 1232701 times)

Quote from: silencesilence on July 07, 2014, 11:23:47 AM

First i say that i do not know much about specifics of how the diff change algos and stuff works.
So not sure if i make any good sense.

But what about such idea:
When multipools enter they cause spike in network hash rate.
and as hash rate increases diff increases i do not know if it is linear relation or not.

But what if in case of big spike in hash rate change, the difficulty rate would overreact.
So lets say 600mh enters suddenly network then diff would jump exponentially (overreacting) and would take some time to calm down to the level it should be at such network hashrate.
Like creating resistance or inertia.
So when Multipool jumps in it must initially stay in not profitable environment and wait for it to become profitable. So all kind of jumping is discouraged.

And if network hasrate grows in normal slow rate then such resistance would be practically non existent.

Any thoughts?

The problem here is when the multipool leaves the network. The ''normal'' miners will be left with the high diff when the multipool leaves. I don't know how it could be implemented without a big impact on the small miners.

Well the overreaction could be in both ways balancing out for the steady miner.

I don't think that penalizing the normal miners when a multipool hit the network is a good way to do things. Could be useful but i don't know how it could be implemented. There's 3 options (i think) to really counter the impact of multipool:
- New algo: multipools won't implement it until it's really worth it (more than 1 profitable coins using it)
- Multi-algo: no matter which algo is it by the multipool, the 4 others algos can still mine without an impact on their diff
- PoS: no mining only staking.

or...
make gpu mining connected to pos mining... ie : you cannot mine more than a percentage of your pos coin in wallet...

So the GPU miner would be integrated in the wallet or find a way to have it connected to the miners stake, would be hard on pools and P2Pools.

deky_

full member

Activity: 182

Merit: 100

What are stealth addresses?
https://www.youtube.com/watch?v=dAUV5FvceM4&feature=youtu.be

Excellent video, explains in layman's terms what the stealth addresses are. Thumbs up Wink

silencesilence

legendary

Activity: 1120

Merit: 1000

What are stealth addresses?
https://www.youtube.com/watch?v=dAUV5FvceM4&feature=youtu.be

and

Vertcoin One Click Miner new Release
http://www.reddit.com/r/vertcoin/comments/2a1q6s/vertcoin_one_click_miner_new_release/

noobtrader

legendary

Activity: 1456

Merit: 1000

Quote from: djnocide on July 07, 2014, 07:02:01 AM

Quote from: rontz on July 07, 2014, 06:50:52 AM

Quote from: rontz on July 07, 2014, 06:50:52 AM

First i say that i do not know much about specifics of how the diff change algos and stuff works.
So not sure if i make any good sense.

But what about such idea:
When multipools enter they cause spike in network hash rate.
and as hash rate increases diff increases i do not know if it is linear relation or not.

But what if in case of big spike in hash rate change, the difficulty rate would overreact.
So lets say 600mh enters suddenly network then diff would jump exponentially (overreacting) and would take some time to calm down to the level it should be at such network hashrate.
Like creating resistance or inertia.
So when Multipool jumps in it must initially stay in not profitable environment and wait for it to become profitable. So all kind of jumping is discouraged.

And if network hasrate grows in normal slow rate then such resistance would be practically non existent.

Any thoughts?

The problem here is when the multipool leaves the network. The ''normal'' miners will be left with the high diff when the multipool leaves. I don't know how it could be implemented without a big impact on the small miners.

Well the overreaction could be in both ways balancing out for the steady miner.

I don't think that penalizing the normal miners when a multipool hit the network is a good way to do things. Could be useful but i don't know how it could be implemented. There's 3 options (i think) to really counter the impact of multipool:
- New algo: multipools won't implement it until it's really worth it (more than 1 profitable coins using it)
- Multi-algo: no matter which algo is it by the multipool, the 4 others algos can still mine without an impact on their diff
- PoS: no mining only staking.

or...
make gpu mining connected to pos mining... ie : you cannot mine more than a percentage of your pos coin in wallet...

rontz

newbie

Activity: 23

Merit: 0

Yes , possibly not feasible , anyway i imagined it looking something like this.

https://i.imgur.com/HdUAgka.png

djnocide

legendary

Activity: 1164

Merit: 1000

Einsteinium Foundation Board Member and Treasurer

First i say that i do not know much about specifics of how the diff change algos and stuff works.
So not sure if i make any good sense.

But what about such idea:
When multipools enter they cause spike in network hash rate.
and as hash rate increases diff increases i do not know if it is linear relation or not.

But what if in case of big spike in hash rate change, the difficulty rate would overreact.
So lets say 600mh enters suddenly network then diff would jump exponentially (overreacting) and would take some time to calm down to the level it should be at such network hashrate.
Like creating resistance or inertia.
So when Multipool jumps in it must initially stay in not profitable environment and wait for it to become profitable. So all kind of jumping is discouraged.

And if network hasrate grows in normal slow rate then such resistance would be practically non existent.

Any thoughts?

The problem here is when the multipool leaves the network. The ''normal'' miners will be left with the high diff when the multipool leaves. I don't know how it could be implemented without a big impact on the small miners.

Well the overreaction could be in both ways balancing out for the steady miner.

I don't think that penalizing the normal miners when a multipool hit the network is a good way to do things. Could be useful but i don't know how it could be implemented. There's 3 options (i think) to really counter the impact of multipool:
- New algo: multipools won't implement it until it's really worth it (more than 1 profitable coins using it)
- Multi-algo: no matter which algo is it by the multipool, the 4 others algos can still mine without an impact on their diff
- PoS: no mining only staking.

rontz

newbie

Activity: 23

Merit: 0

First i say that i do not know much about specifics of how the diff change algos and stuff works.
So not sure if i make any good sense.

But what about such idea:
When multipools enter they cause spike in network hash rate.
and as hash rate increases diff increases i do not know if it is linear relation or not.

But what if in case of big spike in hash rate change, the difficulty rate would overreact.
So lets say 600mh enters suddenly network then diff would jump exponentially (overreacting) and would take some time to calm down to the level it should be at such network hashrate.
Like creating resistance or inertia.
So when Multipool jumps in it must initially stay in not profitable environment and wait for it to become profitable. So all kind of jumping is discouraged.

And if network hasrate grows in normal slow rate then such resistance would be practically non existent.

Any thoughts?

The problem here is when the multipool leaves the network. The ''normal'' miners will be left with the high diff when the multipool leaves. I don't know how it could be implemented without a big impact on the small miners.

Well the overreaction could be in both ways balancing out for the steady miner.

djnocide

legendary

Activity: 1164

Merit: 1000

Einsteinium Foundation Board Member and Treasurer

Quote from: rontz on July 07, 2014, 03:32:24 AM

First i say that i do not know much about specifics of how the diff change algos and stuff works.
So not sure if i make any good sense.

But what about such idea:
When multipools enter they cause spike in network hash rate.
and as hash rate increases diff increases i do not know if it is linear relation or not.

But what if in case of big spike in hash rate change, the difficulty rate would overreact.
So lets say 600mh enters suddenly network then diff would jump exponentially (overreacting) and would take some time to calm down to the level it should be at such network hashrate.
Like creating resistance or inertia.
So when Multipool jumps in it must initially stay in not profitable environment and wait for it to become profitable. So all kind of jumping is discouraged.

And if network hasrate grows in normal slow rate then such resistance would be practically non existent.

Any thoughts?

The problem here is when the multipool leaves the network. The ''normal'' miners will be left with the high diff when the multipool leaves. I don't know how it could be implemented without a big impact on the small miners.

xingqiaoyin

sr. member

Activity: 395

Merit: 250

Quote from: Lucky - Luciano on July 06, 2014, 09:22:58 AM

I thought about how to resist multipools. Perhaps is the solution new algorithm with closed-source. Certainly we need a new, more energy-efficient algorithm.

What is energy efficient algorithm?
I understand that X11 mining at the moment reduces power usage compared to scrypt-n , but as i understand it is only because miners or drivers are not yet able to utilize 100% of GPU recources. And this cap is getting smaller with each new miner release.
And can we even talk about any energy efficiency as the computational work itself is only in place to avoid lots of people solving blocks simultaneously, and solving hashes has no other benefit. If it would be about processing transactions then probably few GPUs could do entire thing.

If the 50% less electricity and 10 degrees cooler running in x11 is really achieved by non-optimized miner i think developin an algo with hashrate peaking at 50% resources is a win-win for everybody...So initially hashrate gains as resources used up to 50% but decreases as more than 50% resources are used..GPU@50% yields the best hashrate, less than that or mroe than that yields less, i.e GPU@40%=GPU@60% and less hashrate than GPU@50%.

That way we can be sure nobody could develop a better miner as that will be useless...

Not that it's very important to cap the GPU@50% but it brings a safer running operation less risk of premature GPU death.

rontz

newbie

Activity: 23

Merit: 0

Quote from: Lucky - Luciano on July 06, 2014, 09:22:58 AM

I thought about how to resist multipools. Perhaps is the solution new algorithm with closed-source. Certainly we need a new, more energy-efficient algorithm.

What is energy efficient algorithm?
I understand that X11 mining at the moment reduces power usage compared to scrypt-n , but as i understand it is only because miners or drivers are not yet able to utilize 100% of GPU recources. And this cap is getting smaller with each new miner release.
And can we even talk about any energy efficiency as the computational work itself is only in place to avoid lots of people solving blocks simultaneously, and solving hashes has no other benefit. If it would be about processing transactions then probably few GPUs could do entire thing.

rontz

newbie

Activity: 23

Merit: 0