Latest github source doesn't compil anymore on linux ! obj/main.o: in function « CBlockHeader::GetHash() const »:
/ProtoShares/src/main.cpp:1335: undefined reference to « bts::momentum_verify(uint256, unsigned int, unsigned int) »
obj/main.o: in function « CBlockHeader::CalculateBestBirthdayHash(int&) »:
/ProtoShares/src/main.cpp:1345: undefined reference to « bts::momentum_search(uint256) »
collect2: error: ld returned 1 exit status
See here: http://bitsharestalk.org/index.php?topic=429.0Basically, you'll need to add "momentum.o" to your make file. |
|
|
|
|
Let me see if I have this right... for 1 BTC, you get ~0.09 GH/s?
Doesn't that seem steep?
If that's the case, I'd rather spend 0.07 BTC and own a 0.33 GH/s USB Block Erupter.
|
|
|
|
Pools are a bit dodgy at the moment, not sure if I should just go solo and hope for the best (i.e. get nothing!)
There's a discussion on bitsharestalk about an issue where CLI clients are crashing. It wouldn't surprise me if the main protoshares instance backing the pools are having a hard time staying online. Is there a blockchain equivalent for PTS?
If you mean blockchain explorer, then yes. It's in the main post: http://btsblock.com/chain/ProtoShares |
|
|
|
its hard out there on the protoshare street ....
Easy street more like! $96 a block. You put your i7 to work and it is earning $10 a day. That's more than most people in the world earn. Speaking of, where's the trade threads? I can't seem to find a link anywhere. |
|
|
|
All further discussion in this thread should be moved here: http://bitsharestalk.org/index.php?topic=22.0I do not have time to follow two threads or repeat myself... :-) gigawatt: join us over at bitsharestalk, I will pay you a 0.5 BTC tip for your contribution. I scooted my conversation. My address is in my signature.  |
|
|
|
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: https://i.imgur.com/k2cNrmd.pngSource using bloom filters: https://i.imgur.com/w8Enf9e.pngIn 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.5The 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. |
|
|
|
|
Is there a version of the $5000 bounty thread here on BitcoinTalk?
|
|
|
|
Perfect, thanks. Is it possible to do something similar on linux? The dameon keeps crashing when I try to set setgenerate to 8. I managed to make 8 threads work with an Amazon EC2 instance. Run "free -m" to see if it's dying due to memory starvation. You'll need ~750MB memory per thread, so make sure you have at least 6GB free. If you do and it still crashes, make sure you're running a 64-bit version of linux. |
|
|
|
|
There seems to be one big unknown factor that makes determining if switching to hosted mining is a better deal: how high will the difficulty get before it finally starts to level out?
Currently, it's going at ~100% per month, but at that sustained rate you'd be looking at a 2 TRILLION difficulty by December of next year. I don't think it's physically possible to churn out that much hardware to make it happen.
|
|
|
|
For anyone interested in renting cloud space to run miners, I've found DigitalOcean's smallest server (512MB ram, 1processor core) to actually have fair hashing power. It costs $0.007 per hour per instance, so five instances (account max) costs $0.035. After running for 24 hours, the average is around 0.8 blocks per instance. This is using the default client for mining.
Is that the reported blocks/day or the actual number of blocks per day? |
|
|
|
OP can I give you Pool Mining Script for VPS, I have it down to a copy and paste method that uses some of your guide to setup
You might be interested in my Securecoin pool mining guide in my signature. Securecoin and Quarkcoin use the same hashing algorithm, so you can just point the miner to a Quarkcoin pool and be good to go! |
|
|
|
Some of you may have tried to use vanitygen to make a Securecoin vanity address and ran into some problems. Turns out that Securecoin uses nonstandard constants* to generate addresses. So, without much further ado: https://github.com/llamasoft/securecoin-vanitygenI will not be distributing compiled binaries, but if you know how to run "make", you can make them yourself. To generate a securecoin address, just use the -S flag: $ ./vanitygen -S secure
Difficulty: 264104224
Pattern: secure
Address: secure1qeuUrEmr2LVucyDBymM7kaiHTE2
Privkey: === REDACTED ===
*: When it comes to cryptocoin addresses, you have two parts that determine some key info about the key. There's the address type (PUBKEY_ADDRESS) and the address version.
Normally, the address version is 128 + address_type, but in this case it was hard coded to 128. |
|
|
|
If you'd accept DGC, I've a bounty for you.
Just set one up. Not going to say no to a bounty. DKDoMWyZukAroASnEEz7VGWSoYPW92QHcW |
|
|
|
Good job  Sent 0.1 BTC (i'm poor, but I hope it helps) K. I'm not gonna complain!  Thanks much for the support! |
|
|
|
|
Show Posts
