|
BEX took the responsibility for the attacks on BTC-e apparently, in retaliation for RS/CH/whoever calling BEX a n00b, but who knows what's actually going on.
It's also claimed that everything related to SC2 is being DDoS'd too, from the trusted notes to the block explorer to the forums to solidcoin.info.
|
|
|
|
Finally i can post here  Nice work ssvb to make miner for PS3, i hope we can tweak it together to make it even better Just GPU miners are a bit more hot topic at the moment. During the last weekend I was busy installing a new graphics card and then doing some OpenCL coding with it. But I'm going to revisit Cell/BE code after I get my GPU miner up and running  I look forward to the performance numbers! The previously much talked about miner (if it even exists) showed only marginal per-watt performance over CPUs. |
|
|
|
Heads up to coblee: You need to integrate net.h and net.cpp from bitcoin 0.5.2 for the program to compile correctly in Linux with the newest version of miniupnp, otherwise you get error: too few arguments to function 'UPNPDev* upnpDiscover(int, const char*, const char*, int, int*)' |
|
|
|
|
The take home message is that the CPF can't be spent, unless it can be spent.
|
|
|
|
|
WELP, looks like I'm never gonna get my money back
|
|
|
|
I don't really need a lot of studies or overwhelming evidence or whatever. One of the beaches I used to go to as a child in the 80's and early 90's was originally almost a kilometer long from shore to dunes. Last year, the length of that same beach was about 300m, and in the past decade they have had to repump more sand into the beach to restore it (because it's disappearing) than they had in the previous 30 years. Remember hard drive prices last year? http://newsinfo.inquirer.net/89853/floods-show-what-lies-ahead-for-sinking-bangkok |
|
|
|
If you want to believe me, then I can vouch for mtrlt's gpu miner being significantly more efficient than any current cpu miner for scrypt.
From what I know of the gpu miner, option 3 of modifying the scrypt parameter will have minimal impact. The pad size did not seem to matter much, and can be compressed for lack of a better word, with on the fly value reconstruction. So any increase in pad size will have a relatively equal impact on cpu miners until you exceed their cache size, at which point, gpus may become even more efficient.
I think you will be stuck with option 2, finding a completely different hashing algorithm.
Are you saying he has disproved the sequential memory hardness for the ROMix algorithm from the original scrypt paper? I don't see why mtrlt couldn't supply us with at least some of the mathematics behind his algorithm. If mtrlt has really completed this code, he could easily create an account on a pool with a random username and password, start mining, and have someone log on and verify that he's actually get 1M/s with four miners. It's really at no loss to him, he would only need to mine for a few minutes for the hash rate to be apparent to the other person. Why hasn't he done this? |
|
|
|
I calculated it out and as soon as SC2 increases in value 125 fold, I'm set to make some killer profits! |
|
|
|
The benefit being you don't need to download the chain or wait for anything, it's all instant.
Yep. Who wants those pesky blocks anyway. Distributed block chains are for nancy-boys. Centralized transaction authorization is the new meme!  Now you can get ScamCoins straight from the source! It's not like you'll ever get them from mining. |
|
|
|
|
Not sure if anyone is paying attention, but the number of "Other" miners has fallen to nearly 40%, and it seems the bulk of people are now mining in pools. I think the golden era of litecoin may be coming.
|
|
|
|
Basing it on bitcoins and making it CPU friendly was a smart move. Is the generation process something that can never be done in OpenCL/CUDA? or will someone eventually write that code and mess things up?
One of the things that I don't quite understand is why you chose 2.5minute block time. One of the main problems for bitcoins are in real-time transactions - was that like the lowest technically feasible time for true transactions to propagate the network or something?
The faster you make the block chain, the more quickly it grows in size... To keep it from becoming massive, you need to choose a reasonable block time size. GG proved that you can have insanely high block generation rates, but I think you still potentially risk clutter by having it too large. Scrypt is difficult for GPUs to perform, so far no one has really proved a faster GPU miner |
|
|
|
I am no GPGPU expert, but I think ArtForz made some very good points in the following thread: https://bitcointalk.org/index.php?topic=45849.0CoinHunter could make his claims convincing by simply explaining how to address the GPU limitations outlined by ArtForz. At least ArtForz was mistaken about Cell earlier Just let's do some simple math. Playstation3 has 6 SPE cores, each clocked at 3.2GHz and 25GB/s of total memory bandwidth. Calculating one hash needs approximately 434176 ADD/ROL/XOR operations on 128-bit vectors in the performance critical part of salsa20/8 which are executed in the even pipe (shuffles and the other instructions are executed in the odd pipe). Also calculating one hash needs 256KB of memory bandwidth (128KB is written sequentially, 128KB is read in scattered 128-byte chunks). So taking into account that SPE core can execute one instruction from the even pipe each cycle, the theoretical performance limit based on computational power is (6 * 3200000000) / 434176 ~= 44.2 khash/s. The theoretical performance limit based on memory bandwidth is 25GB / 256KB ~= 95.4 khash/s. There is a lot of headroom for the memory bandwidth and arithmetic calculations are the bottleneck. Though Cell has precise control over memory operations by scheduling DMA transfers and can overlap DMA transfers with calculations. This allows to utilize memory bandwidth very efficiently for scrypt algorithm. This page seems to say that HD 6990 has 320GB/s of memory bandwidth. And here ArtForz tells us that it is possible to achieve < 20% peak BW with GPU. Doing some math again, we get 320GB * 0.2 / 256KB ~= 244 khash/s. Looks rather believable to me. edit: corrected HD 6990 memory bandwidth (it is 320GB/s and not 350GB/s) What about smix and the mul operations in scrypt? I thought the reason for the speed of Cell as implemented in PS3 (~35 kh/s) was do to the 256kb onboard local registers... The slowdown in scrypt(1024,1,1) has little to do with the speed of the memory and everything to do with the speed of random accesses to that memory. Cache (or onboard memory in the case of Cell) is way, way faster in terms of random access to data (L1 and L2 are 4 and 10 clock cycles respectively for an I7). With DRAM memory, random access is never efficient. In fact, the GPU hardware looks at all memory addresses that the running threads want to access at a given cycle, and attempts to coalesce them into a single DRAM access - in case they are not random. Effectively the contiguous range from i to i+#threads is reverse-engineered from the explicitly computed i,i+1,i+2… - another cost of replicating the index in the first place. If the indexes are in fact random and can not be coalesced, the performance loss depends on “the degree of randomness”. This loss results from the DRAM architecture quite directly, the GPU being unable to do much about it - similarly to any other processor. http://www.yosefk.com/blog/simd-simt-smt-parallelism-in-nvidia-gpus.htmlGPUs generally have little onboard cache (16-32kb) because the data they process is intended to be sequential (and it usually is for 3D applications). |
|
|
|
|
Dubious at best.
source or gtfo
|
|
|
|
|
You're doing it wrong in my opinion; you want total number of coins in circulation * the present trading price --> market cap.
1. BTC: $46,301,166 USD
2. SC2: $900,000 (In ~15 million coins; 99.8% of which is held by CoinHunter and close friends through his 13 million coin premine, so the real market cap is more like $1,800 as far as I am concerned. It's doubtful there's any liquidity close to the 1m$ amount. This is really dangerous; all it takes is one big dump by one of CH's friends and the whole currency goes to shambles.)
3. LTC: $60,274 USD
4. NMC: $57,225 USD
5. RUC: ? No idea what block they were on, but it's pre-mined like SC2 so it doesn't really matter.
|
|
|
|
Server error! Please contact the admin. Very nice.  |
|
|
|
|
thanks, this works well and doesn't slow down my computer all that much.
|
|
|
|
Liquidcoin sort-of
Nicksasa (creator) disappeared with no notice, BTC-E rejected LQC, the client is slightly buggy, it's extremely low value (it's still tradable on vircurex.com), and the blockchain itself has 1000's of orphans for each block.
I'm the guy running liquidcoin.org so it's pretty annoying when the actual creator disappearing, plus I also ran the blockexplorer on liquidcoin.org:2755 which is now broken since the blockchain keeps corrupting itself and ABE keeps breaking its own MySQL so I have to keep re-scanning the liquidcoin blockchains...so I gave up of course after the 100th time...
It's still sort-of alive, but buggy and unsupported by its own developer.
I told the developer the orphan problem would happen when it first came out... Whoever it was, they didn't have a decent understanding of the algorithms underlying bitcoin. |
|
|
|
Hey im back after four days.
Wft happened to this thread?
Coinhunter shit all over everyone's criticism while the price of SC2 plummeted |
|
|
|
|
Show Posts
