Bitcoin Forum
November 22, 2017, 02:29:02 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 »
  Print  
Author Topic: BitShares PTS (formerly ProtoShares) Mandatory Upgrade & Snapshot Announcement  (Read 216566 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
oroqen
Sr. Member
****
Offline Offline

Activity: 280



View Profile
November 08, 2013, 04:52:29 PM
 #521

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

Posts: 1511317742

View Profile Personal Message (Offline)

Ignore
1511317742
Reply with quote  #2

1511317742
Report to moderator
1511317742
Hero Member
*
Offline Offline

Posts: 1511317742

View Profile Personal Message (Offline)

Ignore
1511317742
Reply with quote  #2

1511317742
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511317742
Hero Member
*
Offline Offline

Posts: 1511317742

View Profile Personal Message (Offline)

Ignore
1511317742
Reply with quote  #2

1511317742
Report to moderator
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518


View Profile
November 08, 2013, 04:53:47 PM
 #522

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

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
NUFCrichard
Legendary
*
Offline Offline

Activity: 1120


★Nitrogensports.eu★


View Profile
November 08, 2013, 04:57:46 PM
 #523

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?


           █████████████████     ████████
          █████████████████     ████████
         █████████████████     ████████
        █████████████████     ████████
       ████████              ████████
      ████████              ████████
     ████████     ███████  ████████     ████████
    ████████     █████████████████     ████████
   ████████     █████████████████     ████████
  ████████     █████████████████     ████████
 ████████     █████████████████     ████████
████████     ████████  ███████     ████████
            ████████              ████████
           ████████              ████████
          ████████     █████████████████
         ████████     █████████████████
        ████████     █████████████████
       ████████     █████████████████
▄▄
██
██
██
██
██
██
██
██
██
██     
██
██
▬▬ THE LARGEST & MOST TRUSTED ▬▬
      BITCOIN SPORTSBOOK     
   ▄▄
██
██
██
██
██
██
██
██
██
██     
██
██
             ▄▄▄▄▀▀▀▀▄
     ▄▄▄▄▀▀▀▀        ▀▄▄▄▄          
▄▀▀▀▀                 █   ▀▀▀▀▀▀▀▄▄
█                    ▀▄          █
 █   ▀▌     ██▄        █          █              
 ▀▄        ▐████▄       █        █
  █        ███████▄     ▀▄       █
   █      ▐████▄█████████████████████▄
   ▀▄     ███████▀                  ▀██
    █      ▀█████    ▄▄        ▄▄    ██
     █       ▀███   ████      ████   ██
     ▀▄        ██    ▀▀        ▀▀    ██
      █        ██        ▄██▄        ██
       █       ██        ▀██▀        ██
       ▀▄      ██    ▄▄        ▄▄    ██
        █      ██   ████      ████   ██
         █▄▄▄▄▀██    ▀▀        ▀▀    ██
               ██▄                  ▄██
                ▀████████████████████▀




  CASINO  ●  DICE  ●  POKER  
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
   24 hour Customer Support   

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Mowcore
Hero Member
*****
Offline Offline

Activity: 592



View Profile
November 08, 2013, 05:02:00 PM
 #524

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.

Humble Weekly Bundle.Pay What You Want. Redeem on Steam. Support charity. Pay with BTCitcoin now!--> Paypal Sad
pgbit
Sr. Member
****
Offline Offline

Activity: 321



View Profile
November 08, 2013, 05:02:47 PM
 #525

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

Activity: 140


View Profile
November 08, 2013, 05:07:37 PM
 #526

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

Activity: 280



View Profile
November 08, 2013, 05:09:02 PM
 #527

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
Hero Member
*****
Offline Offline

Activity: 798


wubba lubba dub dub


View Profile WWW
November 08, 2013, 05:09:19 PM
 #528

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.

tiny rick !
- https://voat.co/v/Contact/
- Twitter @Kolin_Quark
NineLives
Sr. Member
****
Offline Offline

Activity: 252



View Profile WWW
November 08, 2013, 05:19:43 PM
 #529

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?

Bitcoin Mining Hardware:   www.mininghardware.co.uk
l3jmr
Member
**
Offline Offline

Activity: 94


View Profile
November 08, 2013, 05:20:36 PM
 #530

That's what i was wondering aswell if i should put all on the same adress.
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518


View Profile
November 08, 2013, 05:25:58 PM
 #531

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.

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
NineLives
Sr. Member
****
Offline Offline

Activity: 252



View Profile WWW
November 08, 2013, 05:30:00 PM
 #532

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,

Bitcoin Mining Hardware:   www.mininghardware.co.uk
digitalindustry
Hero Member
*****
Offline Offline

Activity: 798


wubba lubba dub dub


View Profile WWW
November 08, 2013, 05:32:01 PM
 #533

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

we need ..



DONATIONS !



send to my Nybble address please.

tiny rick !
- https://voat.co/v/Contact/
- Twitter @Kolin_Quark
AnonyMint
Hero Member
*****
Offline Offline

Activity: 518


View Profile
November 08, 2013, 05:35:43 PM
 #534

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.

unheresy.com - Prodigiously Elucidating the Profoundly ObtuseTHIS FORUM ACCOUNT IS NO LONGER ACTIVE
NineLives
Sr. Member
****
Offline Offline

Activity: 252



View Profile WWW
November 08, 2013, 05:36:05 PM
 #535

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

we need ..



DONATIONS !



send to my Nybble address please.

+1

Bitcoin Mining Hardware:   www.mininghardware.co.uk
Snard
Full Member
***
Offline Offline

Activity: 140


View Profile
November 08, 2013, 05:38:48 PM
 #536

Lots more rejects than accepted shares on this pool.

Difficulty to easy with the amount of miners?
bitdraw
Hero Member
*****
Offline Offline

Activity: 507



View Profile
November 08, 2013, 05:46:49 PM
 #537

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

rwessels
Member
**
Offline Offline

Activity: 102


View Profile
November 08, 2013, 05:48:39 PM
 #538

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
Hero Member
*****
Offline Offline

Activity: 592



View Profile
November 08, 2013, 05:51:26 PM
 #539

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.

Humble Weekly Bundle.Pay What You Want. Redeem on Steam. Support charity. Pay with BTCitcoin now!--> Paypal Sad
l3jmr
Member
**
Offline Offline

Activity: 94


View Profile
November 08, 2013, 05:52:35 PM
 #540

i have already recieved 2 payments so far, so must be working. it does feel crappy to look at all those reject % tho Smiley
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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 »
  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!