If anyone would like to give it a shot, there's an extremely optimized sieve of Eratosthenes implementation here: https://primesieve.googlecode.comFrom the software: The best sieving performance is achieved with a sieve size of your
CPU's L1 data cache size (usually 32 or 64 KB) when sieving < 10^16
and a sieve size of your CPU's L2 cache size above. primesieve uses the segmented sieve of Eratosthenes with wheel factorization, this algorithm has a complexity of O (N log log N) operations and uses O (sqrt N) space.
Segmentation is currently the best known practical improvement to the sieve of Eratosthenes. Instead of sieving the interval [2, n] at once one subdivides the sieve interval into a number of equal sized segments that are then sieved consecutively. Segmentation drops the memory requirement of the sieve of Eratosthenes from O(N) to O(sqrt N). The segment size is usually chosen to fit into the CPU's fast L1 or L2 cache memory which significantly speeds up sieving. A segmented version of the sieve of Eratosthenes was first published by Singleton in 1969 [1], Bays and Hudson in [2] describe the algorithm in more detail. From the source, the sieve size is small (1 * 10^6) by default if I'm interpreting it correctly. I'm wondering if a massively parallel GPU implementation with higher memory bandwidth also benefiting from the reduced memory requirements will see much better performance. Also, primesieve generates the first 50,847,534 primes up to 10^9 in just 0.4 seconds on a single core of an Intel Core i7-920 2.66GHz, this is about 50 times faster than an ordinary C/C++ sieve of Eratosthenes implementation and about 10,000 times faster than trial-division. primesieve outperforms my older ecprime (fastest from 2002 to 2010) by about 30 percent and also substantially outperforms primegen the fastest sieve of Atkin implementation on the web. Here is a list of other fast sieve of Eratosthenes implementations. |
|
|
|
@tacotime Any hints you want to share?  Compile with gcc 4.6.x+ x64 and these compilation flags: -O3 -march=corei7-avx -mtune=corei7-avx |
|
|
|
 Doing pretty good on my own optimized x64 build of primecoin... |
|
|
|
|
I guess that's normal, then. I put a 120mm fan in from of them and they're mining at about 35C now, so it's a pretty dramatic improvement.
|
|
|
|
Fuck you and your EC2 instance. Use a regular system like everyone else.
"like everyone else." are you trying to make me laugh til I shit blood? Botnets and Amazon instances is 90% of this coin. If you shit blood when you laugh, it's time to see a doctor, mate. EDIT: And it's not really botnet mineable until someone makes a standalone CPU miner, dipshit. Not true, there is a script here for you to run the daemon with that would work fine for a botnet. It automatically sends all mined funds to your address https://bitcointalk.org/index.php?topic=251850.msg2690895#msg2690895 |
|
|
|
|
Anyone else have heat issues with these? Mine are running at 70 C (temperature taken with an independent thermal diode), is that normal??
|
|
|
|
Has anybody made a GPU miner yet?
a GPU miner will drive up the difficulty and lower the block reward. We'll be dealing with the same exact shit again. What's the point? That people aren't mining in secret with them and getting 100 blocks for every 1 block you get with your CPU? I thought the block reward was constant. No, block reward decreases with higher difficulty. |
|
|
|
There was memcoin a while ago tldr version is that even if you make scrypt use more RAM, it tends to just make the calculation take longer (about linearly with N values) rather than make the calculation any more GPU/ASIC hard. from the yacminer, even at high values of N GPUs have about a 10-fold higher efficiency over CPUs thanks to the time-memory tradeoff (TMTO) |
|
|
|
I'm sick right now, but I'll try to answer these as best I can. 1) You can't invalidate previous blocks without recursively invalidating the blockchain as described. The solution I am proposing is to make truncated PoS subblocks that verify the PoW blocks (this will make more sense when you read it entirely).
If I understand correct the stakeholders are the signatories who vote Yea or Nay to validate whether or not the transaction ledgers match? If they vote 60/40 in Yea then it is true and 60/40 in Nay then it is false?
So it creates a validation chain over time, and you're using truncated PoS sub blocks as the mechanism to accomplish this? Complexity is the enemy of security but I also understand that in this case there is no simpler algorithm that I can think of to do it. It seems like it would work on paper but you're going to have to explain in more detail on the wiki. Yes, the stuff for the wiki for this component is written, but right now the wiki is not really working correctly.
3) A suitable algorithm needs to exist that takes the most recent transactions seen on the network and the times they saw the transactions as input and then analyzes a new PoW block and returns a boolean value specifying whether or not the transaction list included in the PoW block is actually plausible given what it saw.
So what you're trying to do here is essentially verify the integrity of the transaction list?
An algorithm captures the latest snapshot of the list, captures the time stamp as the meta-data part of the input, analyzes the meta-data along with the transaction list to determine whether or not the snapshot is plausible/implausible? This would be narrowed down to a true or false?
Will probability be factored in or is it just true or false?
You have it correct. Ideally the algorithm should have an input cutoff range for probability, with 1 being totally stringent, 0 being "accept any transaction arrangement", and anything between there being a different level of stringency. Stakeholders themselves could adjust this value, but via experimentation on the testnet we can obtain what will be an ideal cutoff, at least at some level of traffic. This will be used to supplement the PoS solution? Are you saying that the PoS solution you highlight in the paper will not scale?
Consistency issues may also arise; for example, if two transactions are sent at nearly the same time, Node A might first see Tx A and Node B might first see Tx B. Node A claims a block and hashes the transaction list with Tx A sorted into the list. Then Node B sees Tx A and makes a list sorted with both A and B in it. Node B will thus never generate the same hash as the one used by Node A to solve the block. To remedy this, stakeholder nodes will have to generate hashes for all possible incorporations for the last n transactions.
If the remedy you are describing based around some sort of combinatorics based consistency check? Are you saying all possible Tx orders would have to be included so that they both generate the same hash? I'm confused about this. If the transaction volume is low, you can calculate ledger hashes for all possible likely transactions that should be included in the block. When the transaction volume becomes huge, the combinatorial calculation of all possible hashes becomes computationally intensive and possibly impossible for the use that we want (instantaneous confirmation of validity of the blockchain). Hence, the theoretical algorithm as described above. Are you saying that the transaction list is like a finite Markov chain?
Sort of. I will write more on this later, I am not feeling good. |
|
|
|
|
There are a few problems with the PoW/PoS method as detailed. I'm trying to upload proposed updates to the wiki, but the wiki is still kind of buggy and won't let me.
Namely:
1) You can't invalidate previous blocks without recursively invalidating the blockchain as described. The solution I am proposing is to make truncated PoS subblocks that verify the PoW blocks (this will make more sense when you read it entirely).
2) Truncating SHA3-256 to 16 bits is somewhat dangerous from a security perspective for ticket selection. This can be resolved by making the input data for the hash fairly random (ie, hash the concatentation of the last 256-bits of the block header hash + SHA3-256 hash of the stake transaction in the block + bits and pieces of the last n blocks' block header hashes + block header hashes of the stake subblocks). What you really don't want is someone gaming the ticket hashes by manipulating the transaction list, this needs to be thought about a little more to ensure it can not be manipulated.
3) A suitable algorithm needs to exist that takes the most recent transactions seen on the network and the times they saw the transactions as input and then analyzes a new PoW block and returns a boolean value specifying whether or not the transaction list included in the PoW block is actually plausible given what it saw. At high transaction volume, it will be more or less impossible for a PoS miner to calculate hashes for all possible additions of transactions to the ledger, so an algorithm as just described that is less intensive is needed.
4) To keep block timing consistent, we need to adjust difficulty based on the value of N for each new PoW block. This is pretty easy, as hashing performance scales almost linearly with N in the ranges I specified if I remember right.
|
|
|
|
|
Itt maximum jimmy overrustle
|
|
|
|
So your new method for Primecoin is just leaving the checkpointing system in place but disabled, and then letting the users turn it on if you think there's the possibility of a 51% attack?
In primecoin a similar checkpoint system is present, but it's user enabled, and by default not enforced. So without threats of 51% attack the system is actually dormant.
Yes, I know, I just wanted to confirm I was following correctly. |
|
|
|
|
So your new method for Primecoin is just leaving the checkpointing system in place but disabled, and then letting the users turn it on if you think there's the possibility of a 51% attack?
|
|
|
|
Yes, go and buy the scamcoin valued at 13% of Bitcoin already. This cannot possibly go wrong.  By market cap LTC only has 5.5% of Bitcoin's total value. |
|
|
|
The 24 hour volume for LTC is well over 1M USD right now (MORE than the 24 hour volume of BTC/USD at mtgox) and the LTC economy seems healthier than ever Well, it is not an economy sign at all. It should read "the LTC speculation seems more vivid than ever". EDIT: the economy is: merchants and services using LTC as a payment method. The Litecoin economy is people buying or selling Litecoin, speculators included. You don't walk into Safeway and trade 5 gold doubloons for a crate of steaks, but people are still trading gold speculatively every day and it has definite value. In the meantime, the price looks set to explode as people bail out of Bitcoin for the time being.  ltc-charts.com |
|
|
|
Anyone want to play devil's advocate? What are the down-sides?
Similar to PPCoin, the chain will be checkpointed such that anyone acting maliciously on the chain will be overridden by Sunny Coin (completely centralized). The new PoW scheme may have yet unforeseen vulnerabilities, also like PPCoin. This isn't really a problem because of the sentence above, but it depends on how comfortable you feel using a chain that is essentially controlled by a single person. Of course, you can always fork the chain and make a version without the continuous checkpointing, too. |
|
|
|
Alt coins are also dead, Litecoin is the last to go down but it's going and will be gone soon.
Why do you say that? Litecoin is currently ASIC proof so there will be a lot of GPU workers going there over the next few months, also it is small but steadily growing, much like Bitcoin was. Once MtGox starts trading LTC we'll see a lot more market validation. Right now, using GPU mining, LITEcoin is LESS profitable than BTC. BTC is already not profitable for people to get into. GPUs cost too much, use too much power, and don't earn enough. They earn even LESS money than BTC. I checked the exchange rate for Litecoin with my mining power, and I make more mining BTC. Yet I shut down my miners because it isn't enough to bother with. Therefore Litecoin was dead before it ever went mainstream. Much like HD-DVD back when that was competing against Bluray disks. Bitcoin was in the news, on TV, on talkshows, mentioned by the black market. Nobody cares about Litecoin but people that don't yet know that they are burning out their CPUs and GPUs on a dying currency. Sure they can make $10 USD a month mining litecoin, but that is foolish when they could make $15 a month on BTC currently. Overheating my house and burning up my GPUs is no longer worth the little $150 I get after the power bill. Anyone doing litecoin is terrible at math and or accounting. Litecoin is totally dead. BTC is alive. Bitcoin mining is 50% less profitable than Litecoin mining right now, see coinchoose.com |
|
|
|
The next few weeks will be interesting; as I said before The 24 hour volume for LTC is well over 1M USD right now (MORE than the 24 hour volume of BTC/USD at mtgox) and the LTC economy seems healthier than ever |
|
|
|
Alt coins are also dead, Litecoin is the last to go down but it's going and will be gone soon.
Why do you say that? Litecoin is currently ASIC proof so there will be a lot of GPU workers going there over the next few months, also it is small but steadily growing, much like Bitcoin was. Once MtGox starts trading LTC we'll see a lot more market validation. People holding devaluating Bitcoins don't want to feel like they're losing money to the rapidly growing Litecoin The 24 hour volume for LTC is well over 1M USD right now (MORE than the 24 hour volume of BTC/USD at mtgox) and the LTC economy seems healthier than ever |
|
|
|
|
Show Posts
