I want to implement a pay-per-share mining pool and would like to know the equation for calculating PPS for a given block based upon difficulty, block reward, and share target.

I am thinking of setting pool shares to be 0x03fffffffffff............

Given pool shares of that difficulty and assuming a 0 average profit pool, what should my pay per share price be?

Amazon
boshen
lighthouse
stan

anyone who is a moderator or admin..

http://54.238.185.113

hi, the pts pool, the testnet is broken, so it is just a beta version!

Nice work, though the bounty is for a pool set up on my server so I can collect the fees

As many of you know Keyhotee will have a wallet interface.  I would like a developer to build the initial version of this interface with the following requirements:

1) Interfaces to bitcoind (or any compatible alt-coin)
2) Uses public/private keys from Keyhotee Profile Hierarchical wallets (I have already implemented the key generation)
3) Displays a list of all transactions & Balance
4) Allows the creation of new transactions for sending coins to a Keyhotee ID

I estimate that it would take me about 2 weeks full time dedicated to the effort to create the basic interface. 

The winner of this bounty also gets credit of $5000 toward their Keyhotee ID.

Could you use the ProtoShares logo rather than the BitSHares logo for this block explorer? 

Thanks.

My replies..

I suppose the performance of your algorithm would also suffer if instead of SHA512(X),  SCRYPT(X) was used because the cost of doing this step twice would be much higher and less GPU friendly.

I wonder what would happen if we used NESTED momentum proof of work? 

Change the nonce-space of the outer proof of work to a pair of 16 bit numbers that result in a X-bit collision?

Now you have a more memory intensive inner hash that is still quick to validate, but would significantly complicate GPU miners.

Note the reason we selected a fast hash like SHA512 rather than a slow hash like SCRYPT is to maximize memory bus bandwidth. 

gigawatt:

I've managed to make a huge step forward in proving Momentum being not nearly as good for proof-of-work as intended.

The magic lies in using a Bloom filter to store the intermediate hashes.
As a result, instead of using 12 bytes per hash/nonce in a Semi-Ordered Map (which results in ~750 MB of memory), the required memory is (-1 * (2^26 * ln(0.01)) / (ln(2)^2)), or about ~76 MB.

This number can be reduced arbitrarily if we're willing to have a false positive rate greater than 1%.  For example, if we allowed up to a 50% chance of having a false positive, the memory requirement drops to ~11 MB.


Here's a overview of how the algorithm works:

Make a "main" bloom filter of size 2^26 with a false positive rate 1%: ~76 MB
Make a tiny "clash" bloom filter of size 2^16 and false positive rate 2^-26: ~0.7 MB
Make a vector of pairs< hash, nonce > to store candidate birthday collisions.
For each nonce in the search space, check if its hash exists in the "main" bloom filter.  If it is, add it's entry to the "clash" bloom filter.
The "main" bloom is no longer required and can be discarded.
For each nonce in the search check if its hash exists in the "clash" bloom filter.  If it does, add < hash, nonce > to a candidate list for investigation.
Sort the list of candidates by hash.
For each pair in the candidate list, see if the previous element has the same hash.  If it does, add it to the output list.  This step removes false positives by comparing the actual hash instead of the bloom filter's idea of a hash.
Return the output list as normal.


For your testing pleasure, I also built a working proof of concept.
(Most of the magic is right here.  The bloom filter is a modified version of "bloom.cpp" called "bigbloom.cpp")

Unmodified source: http://i.imgur.com/k2cNrmd.png

Source using bloom filters: http://i.imgur.com/w8Enf9e.png

In exchange for lowering the memory requirements by a factor of ~10, the algorithm runs at about 1/4th speed, mainly due to the doubling calls to SHA512 and the hash calls within the bloom filters.  The overall result is a net efficiency gain of approximately 2.5
The reduction in memory requirement means that if we could fit N instances of Momentum in GPU memory, we can instead fit 10*N instances.  If we up the false positive rate in exchange for more time spent sorting, we can achieve ratios of up to 70*N.

Given that bloom filters, SHA512, and sorting data are all parallel/GPU friendly, we can conclude that Momentum as a proof-of-work isn't nearly as GPU-hard as initially intended.