I think Artix-7 would be the best one/most cost efficient to mine BTC on, Virtex is a bit of overkill, and a lot more expensive.
Zynq would probably be amazing as well though (I think)
It seems to be a lot harder to get bitcoin miners to place and route successfully on Artix-7 than on Kintex-7. I just updated the repo with a DSP48E1 design, for Kintex 7. 400MH/s using 80% of the DSPs, and ~25% of random logic. I don't have an Artix-7 to port to, but I think they also have DSP48E1's. I plan to start revamping the code base to better support multi-core designs and standardize the communication modules. Hope to get my Kintex up to at least 1GH/s by throwing in two regular hashing cores.
Cool! |
|
|
|
|
Not sure there'd really be any point to anyone developing them, since BFL have been shipping next month for about the last half-year or so.
|
|
|
|
Ongoing panic sell
I expect a bunch of merchants are still setting their prices based on the now-frozen Mt Gox rate and are going to get the shock of their life. |
|
|
|
The Instawallet service is suspended indefinitely until we are able to develop an alternative architecture.
Our database was fraudulently accessed, due to the very nature of Instawallet it is impossible to reopen the service as-is. Fucking maroons. For this to be true, they'd have to be storing the raw, unhashed keys from the URLs, and there's not really any good reason why they should do things this way. Simply hashing the URLs would have made it difficult or impossible for someone who got hold of the database to imitate account holders. |
|
|
|
|
The idea of gmaxwell being lead dev scares me slightly to be honest. He's a decent enough guy, but he doesn't entirely think things through sometimes...
|
|
|
|
I don't think the warning is clear enough, it should read something like this: High scam risk! This is a self-moderated topic. The original poster can delete replies, including ones which point out fraud or dishonesty by them. If you do not want to be moderated by the person who started this topic, create a new topic. Because on past experience that's what this is going to be used for, just like the local thread rules were. Edit: The current warning also doesn't mention that deleted posts disappear completely, so there's no way for normal users to tell if the feature's been used to delete posts. |
|
|
|
Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head:
1) There was no *permanent* "double spend" right? i.e. the transaction on the .8 fork would have eventually been orphaned / dumped / never credited to the address specified in the .8 block?
2) The risk here (and reason why SwC shut off all deposits / withdraws for a few hrs until this was resolved) was that during this very odd period a sophisticated user could use multiple 0-conf services that would all at the same time believe they were getting the same coins, but after the blockchain becomes 1 again only 1 of the transactions would actually be included in the "real" blockchain?
In theory this didn't just affect 0-confirmation services. The transaction on the 0.8 side of the double-spend got 15 confirmations on that fork before it was invalidated by the conflicting transaction from the 0.7 side of the fork, which is more confirmations than anyone requires. |
|
|
|
It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?
You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug. |
|
|
|
It's actually about half of that. About half of those people shouldn't have found blocks and only did because the person who should have mined the block was working on the other chain.
Think about it this way, for each block in the fork, someone mined the block in the 0.7 chain and someone mined it in the 0.8 chain. About half the time, the right person got it (because the forks merged when the work in them was roughly equal), and they still have it. About half the time, the wrong person got it and the right person lost it in an orphaned block.
That's not true. Think about it this way - the difficulty didn't change, so on average everyone mined about the same number of blocks as they would have if the blockchain hadn't forked, except that all the blocks on the losing side of the fork were orphaned and the people mining them didn't get paid. If it wasn't for the fork the blocks would have been distributed slightly differently amongst the miners on the losing side and they might have received very slightly more or less, but since it could vary in either direction we can safely say they're out 625BTC or 29k$. (This also means all miners on the losing side of the fork lost money even if none of their blocks were orphaned, since they could potentially have mined blocks if the chain hadn't forked.) |
|
|
|
It's not ASIC resistant at all. You could make an ASIC for LTC if you seriously wanted to and though it was worthwhile. What you mean to say, more precisely, is that Bitcoin specific ASIC's (SHA-256) will not work for LTC. It's ASIC resistant. You can build ASICs for it, but scrypt is designed to make it impossible to get a worthwhile efficiency gain from doing so compared to general-purpose hardware. |
|
|
|
Almost three hours later, and even later in the evening in EU, you posted At around 2 AM here in the UK - even deeper into the early morning in mainland Europe. Some banks don't even make their online banking systems available at that hour, let alone process wire transfers. |
|
|
|
Avalon went with a very simple chip on a large(110nm) process. I imagine this strategy gave them very high yields out of the wafers because of the small chip size. This came at the cost of a large PCB to route to all the chips. Well, that's certainly going to be part of the reason. However, take a look at the distance between chips on the BFL board and compare it to the distance between chips on the Avalon board. Now remember Josh's comment about the PCB ground plane not being able to dissipate enough heat due to the thermal density of their design, and how having to redesign the chips to fix this delayed shipping whilst Avalon shipped on schedue using similar QFN chips. |
|
|
|
Once Apple discovers how it is being used it will be banned. It doesn't matter what gimmick is used to camouflage the intended functionality. Or if you found a flaw in the TOS that means they should allow your app, they will ban it anyway, and maybe update the TOS, if they feel like it.
If Matthew didn't learn that from his previous loophole-finding attempt, he's probably not going to understand it now. |
|
|
|
And FYI, FPGA board vendors don't talk about power consumption at the wall, but at the 12V level, after the AC/DC PSU.
BFL's FPGA power consumption figures are at the wall; you can get better-than-quoted power usage by using a more efficient PSU. As far as I know, the only vendors that measure power consumption at the 12V input are the ones which make you supply your own PSU. Icarus had both options and gave both power consumption stats: After months of work, finally I build a FPGA mining cluster using the board "Icarus".
each board has 2 XC6SLX150 -2FGG484I on it, generates a 380MH/s hashing power. 19.2W (full load working) / 3.4W (idle) power consuming (board input, without fan). here a detail spec table:
Technology: Spartan6 -LX150 -2I (or -3C)
speed (MH/s): 380
$: 569 (1) / 469$ (multiple of 30) (-5$ if you do not need the adapter, recommend for bulk orders, they are heavy)
W: 4.5 for idle / 21 for full load. (notice this is the on wall power, include the adapter losses and fan) Also, all FPGA vendors which reported board-level power consumption did so for the whole board including power wasted in the onboard DC-DC converters, not the chip power usage as Avalon is doing. It's not like you can really unsolder the chips and put them in your own board with more efficient power circuitry, after all! |
|
|
|
ASIC's are an unstoppable part of any cryptographic 'coin' as it gets more accepted and widespread. It would seem that at the moment Litecoin is 'safe' from ASIC's and can only be mined by GPU's, but an ASIC is sure to come if Litecoin gains fame and widespread acceptance like Bitcoin does.
Not really. The hashing algorithm Bitcoin uses was designed for efficient ASIC implementation, whereas litecoin uses scrypt which is structured to reduce the advantage an ASIC has over general-purpose hardware. |
|
|
|
I'm happy to announce my involvement with the 100TH Mine project, as hosting provider of choice! This is a great project - BitFury has the design doing simulations already and the project is on track for mining in the June/July timeframe. What I like about it is the price point - at $5/GHs, it amounts to 200GH/s for the same $1000. I think its a worthy place to put your hardware dollars, especially if you got aced out of bASIC, BFL or Avalon. For those of you who haven't checked out BitFury's FPGA project: http://www.bitfury.org/bitfury110.htmlOne thing to make very clear: this is not a reborn bASIC project, does not use Tom's chips, is not related in ANY way to bASIC. https://bitcointalk.org/index.php?topic=140366.0So Dave has confirmed his involvement in an ASIC project no-one has heard of before which has nothing to do with bASIC, honest. Not fishy in the slightest. |
|
|
|
Not true at all. That bubble happened precisely because of regulation. Banks were practically forced to lower lending standards by Freddie and Fannie, not to mention the FED key interest rate affected mortgage rates to get artificially low enabling many to borrow who couldn't afford it. All Wall Street did was feed upon this circle and meet a demand that was created by the government and no one else. It's called moral hazard, look it up.
This is completely and utterly bass-ackwards. The only influence Freddie and Fannie had was that they wouldn't buy mortgages on the secondary market unless they met minimum underwriting standards. The pressure was actually in the opposite direction - the banks pressured Freddie and Fannie to lower their lending standard so the banks could make more money on risky subprime loans. However that ignores the bigger picture, namely the amazing and astounding history of Freddie and Fannie from the 70s and the knock on effects. My oversimplified understanding of it is of the way in which those government-set-up institutions got used to force lenders to lend irresponsibly to fulfill political agendas. I've heard this said a lot, but again the exact opposite is true. For instance have you looked at what the much-criticised Community Reinvestment Act actually did? It banned the practice of "redlining" - banks were no longer allowed to refuse mortgages to people who otherwise met their lending criteria just because they were buying homes in poor, largely black urban areas. That's it. It didn't require them to lend money to people who couldn't afford it or any of the other things blamed on it; that was a purely profit-motivated commercial decision by the bank. Actually, things would probably have been worse without the CRA. Amongst other shady things, banks had been pushing black homebuyers into expensive subprime mortgages they couldn't afford even though they were eligible for a much cheaper, affordable prime mortgage on the same house because those mortgages were more profitable for the banks in the short term. Without the CRA, the banks could and almost certainly would have refused to give prime mortgages to those buyers, forcing them to rely on the subprime mortgages that caused the problems in the first place. |
|
|
|
Well, I don't remember Pirate refunding 2/3rds of what was owed before running off with the rest, but I could be wrong.
Even assuming he wasn't lying about the proportion of payments, those 2/3rds were credit card payments, which means that most of the customers could've got their money back via chargebacks. Now when that happens, Tom's credit card processor is forced to pay out from their own funds and get the money back from Tom, meaning they'd lose more than enough money to justify legal action against him. They also have his name, address and ID. Bitcoin customers tend to be a lot more reluctant to sue and a lot less capable of doing so. |
|
|
|
I kinda agree with this sentiment. But why whine? Call BitSyncom, ask what MOSFETs and inductors he needs, raid the nearest RadioShack and Fry's and negotiate with him an exchange of components for finished product. If needed fly them himself to China in carry-in luggage. Radio Shack and Fry's don't carry a decent selection of MOSFETs or inductors, and even if they did sending them to China would be like shipping coals to Newcastle - it's one of the few places where you can actually walk in and buy these kinds of parts. |
|
|
|
This is actually new-ish info, I think? I wanted to have a bit more information for this update, but it looks like I will have to wait until tomorrow to talk to a couple people.
The most important thing I wanted to convey to people at this time was that we have changed our initial "batch" from 12 wafers to 6 wafers, or to be more specific, it's apparently always been 6 with the additional six scheduled for about 1.5 weeks after that. Due to the short time frame between the two, there was a miscommunication as to the actual number of wafers being delivered in the first round. I don't know that this will affect any sort of shipping, since the next set of wafers will be done about when we are ready to start assembly on the first set.
The 6 wafers is actually a good set point for the "first batch" shipping, so the 1/3 plan will be implemented for the first 6 wafers and the remaining wafers will then all be FIFO. The first 6 wafers should cut into the pre-order orderbook by a decent chunk, but it obviously won't satisfy them all. We aren't sure what our yield will be on the wafers, we are running on an 80% yield speculation, but it's likely our yield will be much, much higher than that. With our design, we can have a core in a chip disabled due to dust or what have you and just bump up the other 15 cores to compensate and/or use it for a Jalapeno, so our yield will likely be much closer to 100% than other ASIC projects with more complicated chips.
We should see the bulk of what remains of the 75k chip run about 2 weeks after that, so about the time we are done shipping the other 6 wafers worth we'll have the bulk of our chips arrive and we'll start assembling/shipping those.
The bumping situation is mostly wrapped up at this point, so there should be no problem there. I know there was some talk about the final mask with regards to the bumping and that it may push the date of the chip completion back a couple days, but it shouldn't impact the timeline to speak of as a couple days on either side of the 31st of January shouldn't really make much of difference, being as it's basically a weekend and is in transit anyway. I am hoping to have confirmation with regards to that tomorrow (Monday).
I obviously haven't left for the fab yet, and Mondays call will determine when/if I leave. We have changed our bumping facility from the left coast to the right coast (North Carolina), so we may have the 6 wafers overnighted via courier to the bumping facility vs me picking them up and couriering them myself, although I will be meeting them at the bumping facility and making sure they don't sit around for a couple days while some guy eats and egg salad sandwich and wonders why there's a "priority!" box on his desk. It's possible they're holding half their initial batch of wafers part-way through the wafer deposition process like ASICMINER did, in case they need to be revised. To be honest, I'd thought this was what Josh was hinting about a while ago regardign being able to revise their designs, so it's a surprise that he's so surprised by it. |
|
|
|
|
Show Posts
