Josh how in the hell i knew you or a shill from BFL was going to say the photo was Photoshopped? Because you're a nutcase? And mind you i can tell when something has been Photoshopped. Oh clearly... I mean, it's not like it's a mirror image of the image on this page or anything: http://www.butterflylabs.com/ Even the logo and lettering is on the wrong side and reversed. Yep, you're sure one hell of an internet detective. But let's just say if it is,how do you explain this individual knowing what the revised cases for the 60GH/s Singles looked like at that time? Oh... I don't know, maybe because we started posting pictures in APRIL of 2013Yes, because Milkshake is a play on Smoothie, a known troll and lunatic on these forums, perhaps you're familiar with him. I hope those of you pay close attention at the dates of thos threads and this
ad:http://paris.en.craigslist.fr/ele/3829355665.html
What do they have in common?
All in the month of May,which indicates to me that there was a shipment of BFL ASIC's Yes, all in the month of may, so that logically follows that there was a shipment in May, after we had posted pictures in April. Of course! Silly me! The logic, it blinds! in May to a selected few or many Before BFL officially stated that they shipped out Singles.The only reason you jackasses at BFL ship out his orders because he made
such a large order and Paypal got on yall asses to ship out the order dated "June 12 2012" according to the invoice. Hate to break it to you, but 5 Singles is not a large order. We wern't even taking orders on June 12 of 2012, nor did we have 60 GH/s available at the time or even on the 23rd (they were 40 GH/s). And i'm sure you bastards cut all kinds of deals behind closed doors with your cronies and "developers" that got discounts/free ASIC's
and have them agreed to keep quite and mine while you and they drive up the fucking difficulty before we get our goddamn ASIC's.The spike in
difficulty is due to ASIC's you all at BFL have shipped out incognito back in May.And the Fed's cracking down on Mt.Gox, those of us here in the US have to now submit paperwork because BFL's cronies and
"developers" that got ASIC's are cashing in BTC like chips at a Vegas casino. You're sure of that, are you? Well, guess we know how much you know: Jack and Shit and Jack left town about 2 hours ago. So fuck you Josh,and you tell Jody i said fuck her as well,because in the history of the internet,there's never been a company that was legit
and failed to deliver something within 11 months after taking pre-order money from it's customers. Cry me a river, then build a bridge and get over it. I'd give you a quarter to get you started if I could. Even back in the day Paypal completely unfroze accounts with funds in it after 6 months.
Unfreeze the goddamn ASIC's you currently have in stock and stop feeding us bullshit,week after week,month after month.
Josh you and Jody destroyed yall credibility ,we're just customers waiting on BFL ASIC's.
You've made some of us look like fools to peers, family/friends,for failure to deliver on your promises. No, you've made yourself look like a fool, I had nothing to do with it. As far as i'm concerned i believe nothing of what i read from you and only half of what i
see coming from you.
This doesn't even make sense... PS - learn to use proper spacing. Once again, give respect, get respect. You've failed so far.
Not as hard as you. Not even close. Oooo burn!  |
|
|
|
|
Litecoin banned microtransactions a while ago by requiring huge (0.01) fees. It's still going strong. Stop whining.
|
|
|
|
why, what was the point if 6 algorithms, why not 7 or 5. What is your purpose other than adding complexity to a solution that is already exists (scrypt)?
just like that  long chain complicates gpu optimization thousands of times, there is a function not so accelerated, and it will slow down the entire chain functions. Unfortunately, i no have knowledge of mathe, pre-select in this regard "good" algorithms. no |
|
|
|
With how few coins that have been generated I highly doubt anyone is gpu mining
Well, all the hash functions are included in the source as .c files, if someone isn't GPU mining without a few hours I don't know when they will be. It should be like Bitcoin in that GPUs will be expected to hash at rates of around 50-100 fold that of CPUs. Most of the algorithms selected are high throughput and benefit strongly from parallelization. |
|
|
|
skipping this one, too many coins already which are better (atleast in announcing & releasing)
This is relatively innovative coin with 6 crypto-algoritms (Blake, BMW, Groestl, JH, Keccak, Skein) + block reward depending on difficulty. CPU-only at this time. No premine. That is actually what a lot of people waited for. why, what was the point if 6 algorithms, why not 7 or 5. What is your purpose other than adding complexity to a solution that is already exists (scrypt)? Because everyone knows that using six 512-bit hashing algorithms consecutively and then truncating the last 256-bits means that your coins can't be GPU mined, duh! It's not like you can just reduce the search space to what the difficulty is and only check random hashes against the last hashing algorithm, either.  Someone is GPU mining this right now. |
|
|
|
some new rig porn  installed a shelf in my garage, these sit up here just hashing away all day NOTE THE SEXY PARABOLIC DOLLAR STORE WIFI ANTENNA |
|
|
|
Accidental forks are created from bugs in software making two distinct forks with clients from one version only seeing one valid, while clients from the other version only see the other as valid (see BIP 0050).
If a pool has 51% of the hash rate (or more) it's not a problem for the network unless the pool owner (or a hacker with administrative privileges to that pool) decides he wants to start hiding his chain from the network.
PoW 51% + doublespend in a few words:
1) Everyone else has <50% of hash and is mining a chain.
2) Attacker mines a longer chain in secret, not reporting it to the network. Attacker can do this because he has more hash power.
3) Attacker spends on the <50% fork, waits for 6 (or whatever) confs to get it to spend at the exchange, then exchanges it for cash or whatever.
4) Attacker dumps his chain onto the network. Entire network invalidates the <50% chain, replacing it with the attacker's chain. Attacker's coins are now returned to him to respend at will. Not only this, but all the blocks mined in the <50% chain are now invalidated, so everyone not the attacker loses their blockrewards.
So, end result is that attacker gets 100% of the network coins from block reward and can double spend freely.
The link I shared it tells something different . It says that the attackers coins get invalidated after he has converted them to BTC and other currencies and thus the exchange loses the coins not the normal user. But your story is opposite. Don't know which one to believe. No, it is the same story. The <50% chain has the coins spent, attacker's chain has coins unspent. Exchange sees <50% chain, so it sees them spent (sent to exchange). Attacker then swaps these coins for something else, then dumps their chain onto the network. The transaction in which the coins are spent on the <50% chain become invalidated because the whole chain is invalidated. Thus the attacker now regains his coins (because they are unspent on his chain) while the exchange loses these coins (because they came from a now invalid transaction). |
|
|
|
|
Accidental forks are created from bugs in software making two distinct forks with clients from one version only seeing one valid, while clients from the other version only see the other as valid (see BIP 0050).
If a pool has 51% of the hash rate (or more) it's not a problem for the network unless the pool owner (or a hacker with administrative privileges to that pool) decides he wants to start hiding his chain from the network.
PoW 51% + doublespend in a few words:
1) Everyone else has <50% of hash and is mining a chain.
2) Attacker mines a longer chain in secret, not reporting it to the network. Attacker can do this because he has more hash power.
3) Attacker spends on the <50% fork, waits for 6 (or whatever) confs to get it to spend at the exchange, then exchanges it for cash or whatever.
4) Attacker dumps his chain onto the network. Entire network invalidates the <50% chain, replacing it with the attacker's chain. Attacker's coins are now returned to him to respend at will. Not only this, but all the blocks mined in the <50% chain are now invalidated, so everyone not the attacker loses their blockrewards.
So, end result is that attacker gets 100% of the network coins from block reward and can double spend freely.
|
|
|
|
I get those errors, and im not able to find an answer on the internet Traceback (most recent call last): File "guiminer.py", line 20, in <module> File "pyopencl\__init__.pyo", line 4, in <module> File "pyopencl\_cl.pyo", line 12, in <module> File "pyopencl\_cl.pyo", line 10, in __load ImportError: DLL load failed: Impossibile trovare il modulo specificato. Note: the software does NOT start at all! Note2: i've already downloaded http://support.amd.com/us/gpudownload/windows/Pages/auto_detect.aspxfor my ATI Radeon I have WinXP, tell me if you need more details Thank You :-) win xp is not supported |
|
|
|
Avoid using APU, onboard GPU uses slower DDR3 memory Gigabyte cards run hotter and have shitter VRM heat management (--> cards way more likely to fry from voltage fluctuations) USB thumb drive works fine for linux and cgminer but you will lose voltage control (and thus pay about 20% more in electricity costs and will also be more likely to kill your cards with heat) |
|
|
|
|
You shorted to the +12v... It's no surprise you wrecked the slot.
|
|
|
|
|
yes.
i have a similar setup. put the higher draw cards (5970 and 6970) on powered risers. I have a 4x6950 rig with two cards on powered risers that has never seen problems and draws about 900w.
|
|
|
|
|
Profitability is still about 250% of what it was for me 6 months ago. No worries here. I think we're finally at the point where we're going to see LTC price diverge from BTC price.
|
|
|
|
How is the PoS system coming? Choices here are really delicate. You can easily fuck up in a subtle way. I would not start work on it until the final system has been peer reveiwed. I suggest myself, Killerstorm, iddo, Colbee and Meni Rosenfeld as likely sources of quality feedback. If you come up with something that everyone agrees is workable, do not change it. There is a butterfly effect with these systems. Small changes often introduce exploits for attackers.
Ideally the whitepaper should be as detailed on the PoS system as possible.
Also the people working on bitfreak's idea are pretty smart. Freicoin too (deluded but smart). If you can get their opinions that would be great.
I'm not trying to be discouraging. I just want this to work, then I can finally end my PoS crusade. It has been almost 2 fucking years now. I'm very eager for victory.
Slowly. I want something that actually works well. With the next whitepaper I'll give a supplementary section that includes the specifications in point form for easier audit. |
|
|
|
|
You should look up the MOSFETs they use and see if that's actually anywhere near the temperature limit, as many MOSFETs function perfectly normal up to 105C.
|
|
|
|
So I am to understand that when coblee asked for suggestions on how to prevent GPUs from taking over litecoin, all he had to do was change the N value to higher than 8192 and litecoin would have become way more GPU resistant? Coblee's thread about GPU-mining and Litecoin: https://bitcointalk.org/index.php?topic=64239.0Well, the N factor increases memory requirements for computing a single hash (thus it's using more memory and memory bandwidth). Current GPUs will quickly run out-of-memory (or there's other GPU-specific constraint that prevents the code from running at higher N, dunno). However, it also affects CPUs really hard (around 40% hashrate decrease if I remember correctly). Nah, all you have to do is increase the lookup gap (via the previously published TMTO solution for scrypt from cgminer/reaper) and then you can compute the same hashes with less memory. There's a probably bug in mtrlt's current code that doesn't allow calculation above N=4096, but it's possible that this particular TMTO implementation is not really optimized well for the GPU and that in the future with some hacking we'll see the gap further widen. The further up the N value you get, the greater dependence on memory access speeds you typically observe (or at least, I observed using scrypt-jane on a CPU). I wouldn't be surprised if eventually an implementation for GPUs came along that was optimized and destroyed CPUs for efficiency and speed. BLAKE is used as an entropy source to randomize memory access too, I wouldn't be surprised if you looked at accesses to the lookup table and found that they end up being less than random as well due to consistent ordering of some types of data in the block header (thus also diminishing the amount of memory required). I think pooler observed this when he was writing his CPU miner. |
|
|
|
Is the wiki ready yet?
I'll ask xweb to set it up. Working with him on it right now. It'll be pretty bare bones, but we'll continue improving on it. Sorry, thought I posted that we were! Thanks! |
|
|
|
Is the wiki ready yet?
I'll ask xweb to set it up. Remodel of the PoS system (yet again) coming in the next version of the whitepaper, although there are only some minor changes. With any luck the paper will be finalized soon and we can begin the organization of a lead software dev and supporting devs, then open the kickstarter. |
|
|
|
|
Sent a block. Looking forward to 0.8.1+ version.
|
|
|
|
|
Show Posts
