Post in this thread if you are interested.

Sent 140 Shares with a 0.01 Fee - took around 30mins
Send 49 Shares with 0 Fee - instant

is that right?

With the number of orphans out there the network is wonky right now.  SHould clear up once difficulty adjusts.

Note: the only things we changed from Bitcoin 0.8.5 is the proof of work, the reward schedule, and the block rate, the address leading letter, the ports, and the genesis block.

Quote from: AnonyMint on November 06, 2013, 05:45:09 pm

Okay if I understand correctly your proposed PoW algorithm, we are generating pseudo-random values that can range over the address space of the memory size we target until we generate a duplicate (or triplicate). The Birthday math tells us that we will find a solution with 50% probability before visiting less than roughly 10% of the addresses, or 99% before visiting less than roughly 20% of the addresses. Thus this is a way to require large memory without actually writing to every memory address, i.e. a sparse memory access algorithm. Btw, I also considered this sort of algorithm before and dumped it.

Assuming the generation of the pseudo-random values can be accelerated by parallelism, i.e. that the algorithm is main memory latency bound, then the GPU is going to be much faster, because the GPU masks memory latency by employing 1000s of threads, i.e. we can test 1000s of pseudo-random values in parallel. This was the key myopia that caused Litecoin to fail at stopping GPUs from outperforming CPUs, although it did improve the difference relative to Bitcoin's PoW.

I don't see how the use of a hash table really changes the outcome significantly, as it will only serialize perhaps every 10 buckets and we assume the pseudo-random values are uniformly distributed over the entire address space. Collisions with a 1000 threads are going to be rare.

I have revealed my key insight into PoW. If you weren't aware of this and I am correct, I hope you tip me consumerately.

Ok... a few corrections for you to consider.   The address space of the birthdays is 50 bits.   The TARGET_MEMORY is the number of birthdays that must be stored to have a 90+% probability of finding 1 collision once you have filled TARGET_MEMORY.    As a result, this isn't sparse memory access unless you are operating on some MULTIPLE of the TARGET_MEMORY and that multiple would have to be very high (scaling with the number of GPU threads) if you want to avoid threads stomping on each other with high probability. 

Your GPU algorithm is still O(C * N^2) where C is some constant factor improvement.
CPU algorithm is O( C * N )

While the GPU can hide latency it cannot change bandwidth and your bandwidth usage is still N^2.

There will be an official exchange within the month, or so we have been promised.

I had been mining on my macbook air for a while before this issue happened. Now the client tells that:
Error loading block database. Do you want to rebuild the block database now?

I click OK. It gives me:

ProtoShares-Qt quit unexpectedly. Click Reopen to open the application again. Click Report to see more detailed information and send a report to Apple.

I am trying to locate the blockchain directory on OSX, but it's not there where the bitcoin blockchain would be. I am thinking just delete the blockchain, if I can find it.

Thanks.

everything ends up in ~/.protoshares

Quote from: bytemaster on November 03, 2013, 09:28:00 pm

For example:  Suppose momentum as specked requires about 1 GB of RAM for maximum performance and produces hashes at 1hz.   If you design an algorithm that only requires 1 MB of RAM and can find hashes at .001 hz then you win because you will have proven that computational complexity is linear with RAM use rather than non-linear like I believe the problem calls for.   

Best of luck to you all!

I believe there is a weakness where GPUs can run much faster, but it doesn't requiring lowering the memory. If I explain it to you and am correct, do I qualify for at least part of the bounty?

It is possible I am incorrect or have misunderstood some aspect of the algorithm, so let's not jump to conclusions yet.

There is a big difference between theory and practice when it comes to GPUs and considering the price on the bounty you can afford to provide an implementation.  Your implementation can use a simpler hash function than SHA512 because we are testing the algorithmic complexity not the cryptographic security.

Here are my thoughts on why the GPU cannot do it faster, test them against your theory:
1) I am sure a GPU can calculate the SHA512 birthdays faster.... but it will do no good because the process of comparing every birthday to every other birthday is either:

      a) brute force linear search which could be done in parallel.  The challenge is that such a linear search would be very taxing on the GPU's memory bus to have every thread read every value.

      b) slightly better... use the GPU to sort the data after generating it... such sorting also requires heavy memory bandwidth use and then ultimately ends up with a linear scan of the memory looking for matching neighbors

      d) implement a hash table to some kind on the GPU.  Unfortunately, for the hash table to be effective at finding duplicates items have to be inserted sequentially.

2) Assume we divide and conquer this work between the GPU and CPU... in this case you generate the birthday's in parallel on the GPU then search for collisions on the CPU.  In the middle you have to transfer all of the data across the PCI-E bus which is slower than your memory bus which is already close to the bottleneck. 

3) I count integrated graphics as the CPU

We are working to put one together as quickly as possible.   It will clearly be necessary.

A new client with different difficulty target adjusting time may cause the blockchain diverged.


Sent from my iPhone using Tapatalk

This adjustment would be made with lots of time for people to update.  We are not going to make rash updates.   Right now the parameters are the same as bitcoin so it cannot be all that bad