BitShares PTS (formerly ProtoShares) Mandatory Upgrade & Snapshot Announcement

[oroqen]

i got some blocks near the start but nothing for 2 days, on 2 linux machines, one running 4 threads for 40hpm and the other 2 threads for 6hpm.
Using the poolminer ptsminer 64bit version with 4 threads off github, in linux i get 40 hp/m and got roughly .6 coin in an hour, with the windows 64 version from the pool I've been getting 20hp/m for 1.6 coin in 40mins. anyone care too share why there's such a big difference. linux didn't get as many share but it had 0 rejects where as windows has roughly 60/40(accepted/rejected) split. i assume the windows version doesn't have AVX support?

Admittedly an hour isn't much of a test.

[1714125331]

1714125331

[1714125331]

1714125331

[AnonyMint]

Okay I now understand why bytemaster doesn't understand why I am correct.

They are assuming I was talking about replacing memory with computation, and they apparently didn't even bother to take the time to understand that is not what I am saying:

http://bitsharestalk.org/index.php?topic=22.msg1695#msg1695

[NUFCrichard]

sorry for the noob question, but I am seeing 0.00000 kh/s using the pool.
What am I doing wrong, I recieve the data, I see when it is solved.. but I am apparently not mining?

[Mowcore]

sorry for the noob question, but I am seeing 0.00000 kh/s using the pool.
What am I doing wrong, I recieve the data, I see when it is solved.. but I am apparently not mining?

Give it time, it might take upto 10 mins. It will show eventually.

[pgbit]

sorry for the noob question, but I am seeing 0.00000 kh/s using the pool.
What am I doing wrong, I recieve the data, I see when it is solved.. but I am apparently not mining?

Give it time, it might take upto 10 mins. It will show eventually.

yes, when it goes from "0" to "0.000000" it means its starting up...

[Snard]

This is the pool http://54.238.185.113/

Download the miner in the "getting started section.

Extract somewhere then right click on the x32 or x64 .exe's and ; Right click - Send to - Desktop.

Right click on the new shortcut on your desktop and add this line to the end of the target field
 -pooluser=YOURPTSADD -poolpassword=0 -poolip=54.238.185.113 -poolport=2336 -genproclimit=numberofcpucoreshere 1-8

YOURPTSADD being the receiving address for your mined coins.

Who put together this ptsminer? Is there source available.

[oroqen]

This is the pool http://54.238.185.113/

Download the miner in the "getting started section.

Extract somewhere then right click on the x32 or x64 .exe's and ; Right click - Send to - Desktop.

Right click on the new shortcut on your desktop and add this line to the end of the target field
 -pooluser=YOURPTSADD -poolpassword=0 -poolip=54.238.185.113 -poolport=2336 -genproclimit=numberofcpucoreshere 1-8

YOURPTSADD being the receiving address for your mined coins.

Who put together this ptsminer? Is there source available.

not sure, it's here https://github.com/donSchoe/ptsminer
linux build from github has less luck hitting shares it seems.

[digitalindustry]

I don't know if anyone is still interested, and I hope I am not annoying readers. I will try to describe now the GPU vulnerability with education on technical concepts so that hopefully everyone can readily understand, so there hopefully won't be any doubt for those who desire to know.

First of all, let me describe what I believe the Momentum algorithm is, so we that we can see if we are all discussing the same thing. I will simplify some of the details which don't matter to my point. The Birthday hash algorithm generates a sequence of numbers, with each number being randomly generated (actually pseudo-random but never mind the slight distinction for now) and uniformly distributed over the number range specified.

In other words, we start with some number, then we use a SHA256 hash function on that number to get the next number in the sequence. The SHA256 hash function is applied to each output number over and over to generate a sequence of numbers.

We are looking for a pair of output numbers which are the same. We when find it, then that is the output of the Birthday hash algorithm.

So what is the fastest way to implement this? We must save the numbers in memory as we compute them (from repeated applications of the SHA256), then when we find we have already generated that number because it is already saved, then the hash solution is found.

Our options for saving the numbers as we compute them are to store them in the memory at an array index which is the number, or by storing them in a hash table where the key of the hash table is the number. The latter will use less memory. I will not explain hash tables here, because it is irrelevant to my point below.

The speed of the hash is thus determined by how fast SHA256 is and how fast we can store and lookup numbers from memory (either full random or hash table).

We know SHA256 can be parallelized and accelerated, in fact even some CPUs have accelerated custom logic for doing so. So asymptotically SHA256 will always be faster than the memory accesses in terms of the optimum hardware that can be made given the whole point is to force a use of large memory. I don't think anyone argues this point nor any point I have made above.

Thus the relative speed of the CPU and the GPU (or other custom hardware) is going to depend on the relative speed of the memory access and the level of parallelism that can be applied to the storage and lookup of numbers.

We have two choices for the algorithm. Either we can specify that only the first number of the sequence that is the same is allowed as the solution. In this case, verification can no longer be fast, because verification will also have to store and lookup all the numbers. So if we specify that any number of the sequence that matches is allowed as a solution, then verification can be much faster than when we search for a match, because verification doesn't need to store all the numbers that don't match the number we've told verification will match.

So obviously bytemaster chose the second option, as he needs fast verification. I don't think anyone disputes any of the above.

Let us assume that we can run SHA256 so fast that we can compute 100 candidate numbers asymptotically fast relative to the memory accesses.

However, the second option choice that provides fast verification, also allows us to run numerous simultaneous hardware threads (cores) each will simultaneously store and lookup a different number from the same sequence in the same memory simultaneously.

Now you need to understand the way this works on hardware. While waiting on memory the core will block (meaning it will sleep) and let another core run that isn't waiting on memory.

Random access latency on main memory for both CPU and GPU is very high on the order of several hundred clock cycles. That is an egregious amount of time that a single thread would be sleeping doing nothing if you didn't run simultaneously threads on the same sequence and same memory (i.e. within the same hash instance).

However, if you mix a multi-threaded (parallelized) computation of the SHA256 sequence with simultaneous threads for the memory stores and lookups, then you can asymptotically reduce that computation to 0 time. As well if your simultaneous memory access have collisions in the cache line and memory bus sizes (and don't forget that caches are multi-way mapped into memory so this doesn't just require sequential memory locations), then what happens if that the more hardware threads (cores) you run simultaneously, then the memory latency gets masked away and the underlying memory bandwidth becomes the limit of the speed. This is a fundamental quality of the GPU, and it was designed to have this advantage. If you don't design to defeat it, you won't. Momemtum algorithm does nothing to defeat it.

Since the i7 CPU has at most 8 hardware threads and the GPU has 100s or 1000s of hardware threads, then the GPU can reach its memory bandwidth and the CPU will not even get close to its 20 GBps bandwidth because the CPU has a statistically much lower chance of coherence (collisions) on the accesses. Additionally the GPU main memory bandwidth is up to 10x faster (e.g. 260 GBps for Radeon Tahiti versus 20 GBps for i7).

So the ratio of speed between the GPU and the CPU on this coin is going to be on the order of 260 GBps versus 1 GBps, i.e. two orders-of-magnitude. This is a major fail, since Litecoin is only one order-of-magnitude.

Now someone might counter that GPU cores are not as powerful as i7 cores. True but irrelevant, because the memory latency is the bound here not the computational power per core.

I am open to discussion, questions, and refutations

Anony

When you put it that way it makes me think , " but how could they get it so wrong" ?

The final verification is implementation,  the "DAC" community of mpow, will want you to implement.

In fact, according to the principals of  DAC you are both helping and hurting protoshares...

You are helping with open discussion,  but hurting by stating that its vulnerable but NOT moving to implement it, thus the DAC community may believe that others have behind the scenes.

So look at the DAC as a processor you have opened a "mpow is vulnerable" thread but it hasn't been resolved yet , and eventually it will effect efficency, though confidence.  

So a result is needed.

[NineLives]

Question..

If I give all my servers different wallet addresses for pool mining, will I loose any benefits then all having the same address?

I wana experiment and see what machines perform and gain the most.

Or shall i just leave the same address for all?

[l3jmr]

That's what i was wondering aswell if i should put all on the same adress.

[AnonyMint]

I don't know if anyone is still interested, and I hope I am not annoying readers. I will try to describe now the GPU vulnerability with education on technical concepts so that hopefully everyone can readily understand, so there hopefully won't be any doubt for those who desire to know.

First of all, let me describe what I believe the Momentum algorithm is, so we that we can see if we are all discussing the same thing. I will simplify some of the details which don't matter to my point. The Birthday hash algorithm generates a sequence of numbers, with each number being randomly generated (actually pseudo-random but never mind the slight distinction for now) and uniformly distributed over the number range specified.

In other words, we start with some number, then we use a SHA256 hash function on that number to get the next number in the sequence. The SHA256 hash function is applied to each output number over and over to generate a sequence of numbers.

We are looking for a pair of output numbers which are the same. We when find it, then that is the output of the Birthday hash algorithm.

So what is the fastest way to implement this? We must save the numbers in memory as we compute them (from repeated applications of the SHA256), then when we find we have already generated that number because it is already saved, then the hash solution is found.

Our options for saving the numbers as we compute them are to store them in the memory at an array index which is the number, or by storing them in a hash table where the key of the hash table is the number. The latter will use less memory. I will not explain hash tables here, because it is irrelevant to my point below.

The speed of the hash is thus determined by how fast SHA256 is and how fast we can store and lookup numbers from memory (either full random or hash table).

We know SHA256 can be parallelized and accelerated, in fact even some CPUs have accelerated custom logic for doing so. So asymptotically SHA256 will always be faster than the memory accesses in terms of the optimum hardware that can be made given the whole point is to force a use of large memory. I don't think anyone argues this point nor any point I have made above.

Thus the relative speed of the CPU and the GPU (or other custom hardware) is going to depend on the relative speed of the memory access and the level of parallelism that can be applied to the storage and lookup of numbers.

We have two choices for the algorithm. Either we can specify that only the first number of the sequence that is the same is allowed as the solution. In this case, verification can no longer be fast, because verification will also have to store and lookup all the numbers. So if we specify that any number of the sequence that matches is allowed as a solution, then verification can be much faster than when we search for a match, because verification doesn't need to store all the numbers that don't match the number we've told verification will match.

So obviously bytemaster chose the second option, as he needs fast verification. I don't think anyone disputes any of the above.

Let us assume that we can run SHA256 so fast that we can compute 100 candidate numbers asymptotically fast relative to the memory accesses.

However, the second option choice that provides fast verification, also allows us to run numerous simultaneous hardware threads (cores) each will simultaneously store and lookup a different number from the same sequence in the same memory simultaneously.

Now you need to understand the way this works on hardware. While waiting on memory the core will block (meaning it will sleep) and let another core run that isn't waiting on memory.

Random access latency on main memory for both CPU and GPU is very high on the order of several hundred clock cycles. That is an egregious amount of time that a single thread would be sleeping doing nothing if you didn't run simultaneously threads on the same sequence and same memory (i.e. within the same hash instance).

However, if you mix a multi-threaded (parallelized) computation of the SHA256 sequence with simultaneous threads for the memory stores and lookups, then you can asymptotically reduce that computation to 0 time. As well if your simultaneous memory access have collisions in the cache line and memory bus sizes (and don't forget that caches are multi-way mapped into memory so this doesn't just require sequential memory locations), then what happens if that the more hardware threads (cores) you run simultaneously, then the memory latency gets masked away and the underlying memory bandwidth becomes the limit of the speed. This is a fundamental quality of the GPU, and it was designed to have this advantage. If you don't design to defeat it, you won't. Momemtum algorithm does nothing to defeat it.

Since the i7 CPU has at most 8 hardware threads and the GPU has 100s or 1000s of hardware threads, then the GPU can reach its memory bandwidth and the CPU will not even get close to its 20 GBps bandwidth because the CPU has a statistically much lower chance of coherence (collisions) on the accesses. Additionally the GPU main memory bandwidth is up to 10x faster (e.g. 260 GBps for Radeon Tahiti versus 20 GBps for i7).

So the ratio of speed between the GPU and the CPU on this coin is going to be on the order of 260 GBps versus 1 GBps, i.e. two orders-of-magnitude. This is a major fail, since Litecoin is only one order-of-magnitude.

Now someone might counter that GPU cores are not as powerful as i7 cores. True but irrelevant, because the memory latency is the bound here not the computational power per core.

I am open to discussion, questions, and refutations

Anony

When you put it that way it makes me think , " but how could they get it so wrong" ?

The final verification is implementation,  the "DAC" community of mpow, will want you to implement.

In fact, according to the principals of  DAC you are both helping and hurting protoshares...

You are helping with open discussion,  but hurting by stating that its vulnerable but NOT moving to implement it, thus the DAC community may believe that others have behind the scenes.

So look at the DAC as a processor you have opened a "mpow is vulnerable" thread but it hasn't been resolved yet , and eventually it will effect efficency, though confidence.  

So a result is needed.

bytemaster ignored my question about why he claims the GPU has a squared time complexity compared to the CPU. His entire defense hinges on that, yet he refuses to reply:

http://bitsharestalk.org/index.php?topic=22.msg1695#msg1695

http://bitsharestalk.org/index.php?topic=22.msg836#msg836

No need to implement. He just needs to address the question.

[NineLives]

Question..

If I give all my servers different wallet addresses for pool mining, will I loose any benefits then all having the same address?

I wana experiment and see what machines perform and gain the most.

Or shall i just leave the same address for all?

That's what i was wondering aswell if i should put all on the same adress.

Personally, I don't think it makes a difference.

Wallet address is for payment.
Workers can't merge hps.

I'm a novice miner and I don't know enough.  Hope someone more experienced can answer,

[digitalindustry]

Ok then community lets make a GPU miner Mlrt , RS , BFL Tradefortress ....guys......

we need ..



DONATIONS !



send to my Nybble address please.

[AnonyMint]

It potentially gets worse for this new PoW algorithm. Gigawatt claims another vulnerability:

http://bitsharestalk.org/index.php?topic=22.msg1719#msg1719

Cryptography can not be invented overnight. It takes a long-time, lots of community peer review, and patience to prove some new cryptography has the desired properties.

[NineLives]

Ok then community lets make a GPU miner Mlrt , RS , BFL Tradefortress ....guys......

we need ..



DONATIONS !



send to my Nybble address please.

+1

[Snard]

Lots more rejects than accepted shares on this pool.

Difficulty to easy with the amount of miners?

[bitdraw]

hm... close to 20% mined already or am i getting it wrong?

[rwessels]

My 5 computers on the pool for 90 minutes (8 physical cores each E5420):

97.2% rejected (2 accepted)
100% rejected
98.6% rejected (1 accepted)
98.9% rejected (1 accepted)
98.9% rejected (1 accepted)

So 5 accepted.  Not really sure what that means because it shows no earnings.

[Mowcore]

My 5 computers on the pool for 90 minutes (8 physical cores each E5420):

97.2% rejected (2 accepted)
100% rejected
98.6% rejected (1 accepted)
98.9% rejected (1 accepted)
98.9% rejected (1 accepted)

So 5 accepted.  Not really sure what that means because it shows no earnings.

I know right? Still waiting for the earnings to update, been on 7 accepted for ages.

[l3jmr]

i have already recieved 2 payments so far, so must be working. it does feel crappy to look at all those reject % tho