I apologize, it was never mentioned to me by UPS that they would charge a 'fee' for getting it across the border when shipping the package, all that was told to me was the rate to ship the box. This is my first time shipping to Canada, now I know too I guess.
Yeah, it's a big problem here. My roommate bought some motorcycle parts online from the US for $70 and UPS charged him $120 in non-specific "customs brokerage fees". FedEx charges these fees here, there's basically a shipping cartel up here as far as getting stuff across the border is concerned. The only company without charges is USPS/Canada Post. |
|
|
|
|
$40 + shipping to Canada for the X58 board.
|
|
|
|
|
Got the drives in the mail today... unfortunately didn't have as good luck as the other customer.
1) UPS charged me an extra $45 for brokerage fees at the border (should have mentioned to never ship to Canada with UPS, was partly my fault. For future reference only use USPS to Canada).
2) Drives were in really bad shape, anti-static bags are nearly torn and heavily perforated from being banged around so much. One of the PCBs on one of the WD drives is actually scratched deeply. It looks like they were shipped with air-filled plastic baggies, but these all popped from rough handling by UPS which let the drives bounce around like crazy in the foam peanuts that filled the remaining half of the box.
I will test them out next week sometime, hopefully they're okay.
|
|
|
|
Yes, that's what I said. (4.9 million == 4800 K) (the exact number is 4939776 bits). Memory bandwidth for the block RAM is about 10 gb/s while GPU internal bus is usually around 250 gb/s on higher end cards.
I'm not following your arithmetic. Are you citing some document somewhere for either of those numbers? If so, can you paste a link? From my previous post, an FPGA memory with 1024-bit width at (lets downgrade it to a more modest 200MHz) is 200 billion bits per second or 25GB / s. This would be per-memory-instance (or, per hypothetical scrypt-core). The total RAM per block is 18KB. Each block has a 72-bit width. I don't really know where you're pulling your numbers from. Even if you calculate in parallel, 128/18 = 8 block RAM units required, with 72-bit widths each --> not 1024 bit width either. |
|
|
|
The problem is that the on-device block RAM is insanely slow compared to GPU ram (about 10 times slower for most FPGAs). The per slice block RAM for most FPGAs is also less than 128 KB (more like 8 KB in typical cases).
Well, I'm not as familiar with GPU, but I doubt it is 10 times faster. And I believe you have been misinformed regarding the capacity as well. The Spartan-6 LX 150 used on many of the boards already built has 4.9 million bits of memory. The memory in -3 speed grade part can run at up to 320MHz Newer but similar priced Artix-7 have 13.4 million bits, with up to 509MHz in -3 grade parts. As it relates to scrypt and it's 128KB scratchpad, the core loop accesses memory sequentially in 1024-bit widths. Within an FPGA, you can have access to all 1024 bits in a single clock. While you may not be able to achieve that performance point due to other issues, 1024 bits @ 320/500MHz is nothing to sneeze at. Total block ram on the whole chip for a spartan6 lx 150 (most expensive chip) is 4824 Kb. http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/lx.htmMemory bandwidth for the block RAM is about 30-60 gb/s (your numbers above) while GPU internal bus is usually around 250 gb/s on higher end cards. |
|
|
|
Anyone remember the value of BTC when FPGA's first appeared off hand? I started open development of FPGA mining designs in May 2011; BTC was about $5USD at the time. The first commercial FPGA mining products first appeared on August 18th, 2011, and BTC was about $10USD then. Food for thought: scrypt as it is used in litecoin is not a memory-hard algorithm. Rather, it's an algorithm with a space-time trade-off skewed towards using more space, given the current relative costs of memory fetches versus computations. You can implement litecoin's scrypt with only a little over 2 kilobits of memory, but it runs ~512 times slower. It's likely that a performant implementation will use a sparse LUT to cut down on fetches. For example, with a 512 element LUT (instead of 1024), the algorithm performs 50% less fetches, and requires only one extra salsa round 50% of the time. I think a simplistic port of the existing scrypt.c from the litecoin source code would just use 128KB of block RAM, which is readily available on most of the FPGA's already in circulation. I can see how it might increase the area/cost of an ASIC, but for an FPGA it's a non-issue. It's not clear why people are even discussing external memory requirements for this algorithm and getting ready to write-off their purchased bitcoin boards. Overall, it sounds like we should expect an FPGA implementation of litecoin to perform at (1/1024) the rate of equivalent bitcoin hash. And this is due to the sequential loops, and not the "memory-hard" aspect of the algorithm. The problem is that the on-device block RAM is insanely slow compared to GPU ram (about 10 times slower for most FPGAs). The per slice block RAM for most FPGAs is also less than 128 KB (more like 8 KB in typical cases). The tradeoff described above works (reducing the memory size a lot and just recreating the entire lookup table more often), but the performance decrease is usually so great that it's problematic. If you can make the algorithm run in parallel better I think it may be possible to get into the high double digit KH/s or perhaps hundreds with an FPGA. We'll have to see what LaSeek and friends come up with. |
|
|
|
I am aware of those facts.
However, I believe you missed the part where I explicitly stated the qualifier "malicious".
Detecting a reorg is trivial. Determining whether it is an okay reorg or a "bad" reorg does not seem so.
There's nothing suspicious about a chain 7 blocks long suddenly appearing on the network after an hour, with nobody else reporting it until then? And in the meantime blocks are being relayed every ten minutes by other miners? Really?  |
|
|
|
a) it would be exceedingly hard to properly develop detection algorithms for "malicious reorg" detector
Reorg shows up in the debug output immediately in the client It's absurdly easy to detect (just look for a chain that's been reliably mined for 6 blocks/1 h and then at 1 h the 7 block fork is detected --> report this to user via pop up) The likelihood of two totally different chains size max of 6 MB (6 blocks) existing on the network at the same time and both being reported to a vast number of different nodes with neither group of nodes interacting is really, really unlikely |
|
|
|
|
Not sure, this happened with cgminer to me using 3x 7970s. I'm replacing the board to see if that's the problem.
|
|
|
|
|
this is normal for 7xxx cards on 13.1, use beta driver to get rid of blocks
|
|
|
|
|
Not sure, never tried it
PPC is not scrypt, you have to run normal guiminer
|
|
|
|
|
both XFX and gigabyte cards, brand doesn't seem to make any difference as both hash at exactly same rate
|
|
|
|
|
If it's stratum you must use the mining proxy (see sig threads)
|
|
|
|
|
No, that's correct, 10 GH/s is about 10 TH/s BTC in GPU terms. The migration of miners to the Litecoin network has been steady as ASICs are introduced.
|
|
|
|
|
You neglect the part of the scheme above that's moronic because you spent tens of millions of dollars to attack a chain with less than that much immediate liquidity on any exchange. If you were to spend tens of millions of dollars making lots of ASICs, why not just mine with them like everyone who has made ASICs so far is doing?
edit:
For instance, your net profit per day right now mining Bitcoins with 80 TH/s (enough to attack the network) is $530,445.73 (after power given a mildly inefficient ASIC). Why would anyone in their right mind perform a 51% attack when they're making that much per day off their hardware?
|
|
|
|
|
^^ That wasn't my interpretation of it...
If I'm understanding correctly, the mechanism described works like this:
1) Attacker with 51% of hash rate begins mining a fork 7 blocks long in secret while submitting his coins to an exchange (or where ever)
2) The attacker's coins get 6 confirmations and he dumps them for something valuable at the exchange, runs off with it
3) Attacker now dumps his 7 block fork onto the network. Normally, because it's longer than 6 blocks, the attacker would get his coins back because he would invalidate all 6 previous honestly mined blocks because the network can not tell which blocks are valid or are not valid and just accepts whatever chain is longest,
HOWEVER,
The Litecoin chain for the last hour has included block hashes for the block headers of the previous honest 6 blocks for Bitcoin. The Bitcoin clients could be alerted to this (and the fact that a reorg of length 6, an exceedingly unlikely event, has just taken place), look at the Litecoin chain where the hashes of the honest blocks' headers are stored, and reject the fork that suddenly appeared on the network out of nowhere because they know the hashes on the Litecoin chain reveal the honest chain (the one that reported blocks as soon as it found them rather than hiding them).
There are some issues with this.
1) Inevitably bitcoin orphan blocks will appear in the LTC chain.
2) Miners on the Litecoin network can make up any block hash they want and submit it, since there's no easy way of telling whether the hash they give actually exists over some portion of bitcoin network.
3) Because of 2), forking the BTC chain may be made easier in some instances if the BTC network actually pays attention to what the LTC network is saying and the LTC mining nodes are dishonest.
What's being discussed here has nothing really to do with merged mining, it's just a way to lend temporal stability to the Bitcoin network via an independent network (Litecoin)
|
|
|
|
Also.... why are you tryingto stay out here ? I really enjoy your posts. Please, also give us an update about your VERY interesting MC2 concept !  I will lose my job (and $25,000 for the remainder of the year) if I don't pass my exams that are coming up this week and the following week, so I need to complete them first MC2 update coming soon, tons of things will be changed (new PoS strategy, more optimized hashing algorithm) based on the feedback I have received. |
|
|
|
|
Show Posts
