|
A friend of mine has received shipment noficiation for order #1865 (7/24) for two singles.
|
|
|
|
What does that article have to do with Sonny Vleisides or BF Labs Inc. (Butterfly Labs)?
Did BFL or Sonny Vleisides engage in ponzi scheme fraud?
The mission of the U.S. Securities and Exchange Commission is to protect investors, maintain fair, orderly, and efficient markets, and facilitate capital formation. Except when you buy a product, you are not considered an investor. Unless the pre-order money was used to develop the products. Nope, that still doesn't change your status as a customer. And it has yet to be proven that they've used pre-order money to develop the products anyway. |
|
|
|
|
Blockchain.info's firstbits lookups are not working. 1sgtspike doesn't come up. 1a comes up, but with the wrong address - it should come up with the address from block #1.
|
|
|
|
I don't think this is true or needed. Some addresses have no firstbits base representation, because an address differing only by case appeared earlier.
The chance of two addresses only differing by case is something like 1 in 34^34 (or 34^27 if you're looking at the shortest possible Bitcoin address), is it not? If so, I'd say we can safely assume no two addresses have been, or will ever have, the same address differing only by case. Even 24^27 is such an impossibly high number as to conclude it will not happen within the life of the earth. I don't have a strong preference. Abe does use enough characters to distinguish from addresses later in the block. I think the code was simpler before I did this. I don't think conceptually either way is more complex; you choose between defining "order of appearance" and "same or earlier block". I strongly suggest finding an example and checking blockchain.info's treatment of same-block collisions, since that site obviously has a lot of work put into it and may be unwilling to change. And let's try to include piuk.
I agree. Since all three of us seem to be willing to change, let's see what blockchain.info is doing and go from there. EDIT: As luck would have it, Firstbits doesn't appear to currently be working on blockchain.info at the moment. |
|
|
|
What does that article have to do with Sonny Vleisides or BF Labs Inc. (Butterfly Labs)?
Did BFL or Sonny Vleisides engage in ponzi scheme fraud?
The mission of the U.S. Securities and Exchange Commission is to protect investors, maintain fair, orderly, and efficient markets, and facilitate capital formation. Except when you buy a product, you are not considered an investor. |
|
|
|
|
Make a bot that reads the forum. For every post that says "sell", buy a little bit. For every post that says "buy", sell a little bit.
|
|
|
|
Currently, people getting their devices can probably expect some profit on them (at least if they didn't pay in BTC back before BTC went through the roof).
No one paid "in BTC". They paid in USD with BTC. It is as useless to compare an investment in BTC with an investment in a mining machine as it is to compare an investment in gold mining equipment with an investment in gold itself. Hindsight is 20/20, and no one knew that BTC would be worth as much as it is today when they ordered mining equipment with the price at $5. They chose to invest in mining equipment instead of Bitcoin itself, while Bitcoin itself has shown itself to be the more profitable investment. Both investments have proven to be profitable - just because the profit would have been higher in one investment does not mean the investment in the other is a loss. Just saying. They'd have been in better shape just to sit on their BTC. For that matter, they'd have been in better shape to use the same USD to buy BTC. BFL is one of the kinds of things that happen in a "gold rush economy." You know who made the most profit on the gold rush (other than the real monsters who moved in like Hearst)? It wasn't the miners. It was the people who sold them equipment. Funny how history repeats itself. Yes, I agree, they would have been better off to sit on their BTC. They'd also have been in better shape to use that USD on some penny stock that went up 10,000%. I mean, we could go on about what-if scenarios, but since no one knows the future, they're kind of pointless. |
|
|
|
Currently, people getting their devices can probably expect some profit on them (at least if they didn't pay in BTC back before BTC went through the roof).
No one paid "in BTC". They paid in USD with BTC. It is as useless to compare an investment in BTC with an investment in a mining machine as it is to compare an investment in gold mining equipment with an investment in gold itself. Hindsight is 20/20, and no one knew that BTC would be worth as much as it is today when they ordered mining equipment with the price at $5. They chose to invest in mining equipment instead of Bitcoin itself, while Bitcoin itself has shown itself to be the more profitable investment. Both investments have proven to be profitable - just because the profit would have been higher in one investment does not mean the investment in the other is a loss. |
|
|
|
Correct me if I am wrong, but the HW error rate of 3.2% means your effective hashrate is actually 60GH/s, not 62GH/s? So the increase is truly only 2GH/s?
I had an error rate of around 0.4% to begin with. I'll also admit I wasn't keeping meticulous records of my pre-modded hash rates. I suppose it may be "only" 2GH/s, but such a mod will cost you a lot less than buying USB ASICs, though with the exponential difficulty 2GH/s isn't going to mean that much soon. It's certainly better than a kick in the pants that's for sure. Agreed! I might give it a try - thanks for experimenting and releasing your firmware to the public though! |
|
|
|
|
I'd rather use a molex --> PCIe than a PCIe splitter. Then you have the electricity at least flowing through two different sets of 12v wiring. But to be honest, it would probably be fine either way.
|
|
|
|
Ok cool. So I set the frequency to 9 in std-def.h, disabled ""#define __RUN_HEAVY_DIAGNOSTICS_ON_EACH_ENGINE" and changed "#define __TOTAL_DIAGNOSTICS_RUN 10" down to 1 in std-def.h. (Thanks, danattacker) Also took off the case and froze the unit for about 30 minutes. Used to be averaging about 58 GH/s...now: 5s:62.57 avg:62.02 u:63.48 Gh/s | A:114 R:20+0(.40%) HW:127/3.2% HW error rate is a little high, but it's stable. So ~5-10% gain depending on the average, which isn't anything to sneeze at. So I've uploaded the compiled Singles firmware .elf here, with the source code with my edits should you wish to tweak it further: https://www.dropbox.com/sh/2v6151n50g4hb0s/CdGbzmnDiVI would expect this should work for all non-little singles/jalapeno units. I've also included an untested version that should work with the minirigs as well. I also have included two pictures of the board with the jtag connectors visible, to the left of the power ports. There's no need to disassemble the fans or heat sinks. If you use this and it works for you, a donation of one day's worth of your increased earnings (~.05-0.1 BTC at current rates for a singles, ~5-10BTC for a minirig) is suggested and appreciated. Donations: 1QGGpaa8YX1eC2Kp99yxCPfrMoRuMUoudD Correct me if I am wrong, but the HW error rate of 3.2% means your effective hashrate is actually 60GH/s, not 62GH/s? So the increase is truly only 2GH/s? |
|
|
|
|
How do you actually attempt to overclock an SC Single?
|
|
|
|
As an update.
Due to a recent decision from the management team on Overclock.net we now will no longer support the discussion of Bitcoin or any other elements of it.
The Use of Bitcoin breaches our TOS as you can use Bitcoin to earn currency. It specifically states in the OCN TOS that you may not Directly or Indirectly profit from the use of OCN. As such we cannot support the Bitcoin project. We also feel that the Bitcoin project does not fit in with goals we strive for on OCN.
We have nothing against the Bitcoin project, it simply does not fit the purpose and goals of Overclock.Net What a bunch of bullocks. Screw OCN. 6000+ posts and 4 years later, I'm leaving. Sick of the crap that they pull. I can understand not advertising about your own websites to some extent. But not allowing discussion of Bitcoins because you can make money from it? Seriously? BTW, the PRIMARY motivation of OCN for doing this is to keep everyone on the site folding@home - it has nothing to do with the actual bitcoin discussion. OCN is one of the top ranked communities for folding, and I'm sure they don't want to see their ranking drop because a bunch of folders switched over to bitcoining.  Bye-bye OCN. I am unsure of who sent this to you, but discussion of the project was not banned after the distributed computing forum announcement was made (the second version). This was May 2011... long before said distributed computing forum announcement was made. At least as far as I am aware. I still think it is absurd that discussion of it was banned in the first place, and I am still convinced it had to do with trying to prevent people from leaving the OCN F@H team. |
|
|
|
No chance... note that 200 DMD per day requires about 8000 kh/s - with that rate you need 5 days to mine 1000 DMD... a simple calculation: - 8000 kh/s means 10 x 7970 with 250W each - 250W * 10 = 2500 = $12.60 per day (0.21 $/kWh) - DMDs Value: 5*12.60 = $63 - BTCs Value: 0.23 * $85 = $19.55 - Conclusion DMDs Value > BTCs Value ==> no one sells his DMDs for this price  $.21/kwh? Christ, where do you live? I pay $.09/kwh. probably europe, I have $.2 Yep... central europe (Germany) - the average price for 4000 kw in 2012 was .2457€ (or $.32.287437) per kwh... in 2013 we've .2760€/kwh for 4000 kw Conclusion: $.21 = cheap, $.09 = dream (please send me some batteries  ) Tis the price paid for clean energy. Whether you agree with it or not, it IS much more expensive than coal. |
|
|
|
Forgot the blockchain spam. That's BS.
A lot more jackass than the blockchain spam is the mass acumulation and hoarding of first bits.
You know, in my country domain names are free to register, and we got the same kind of greedy people running crazy bots and the such to be able to register as much as possible. Thankfully they later had to and were able to cap it on a per person basis, but the damage was already done. We will not even be that lucky here. These abuses will ran rampart.
"Hey, here is a free amazing resource BTC has which, incidentally, is great for newbies, usability and further adoption."
"Oh cool. IMPERIALIST MODE ON. Let me capture them all before anyone finds out, and then sell for 20 a pop out of thin air."
Nothing further from the ideals of BTC and precisely the opposite of what we need right now IMHO, but I can't however negate the fact that a free market is a free market after all.
I'm at loss here, what do you mean by firstbits? |
|
|
|
Forgot the blockchain spam. That's BS.
A lot more jackass than the blockchain spam is the mass acumulation and hoarding of first bits.
You know, in my country domain names are free to register, and we got the same kind of greedy people running crazy bots and the such to be able to register as much as possible. Thankfully they later had to and were able to cap it on a per person basis, but the damage was already done. We will not even be that lucky here. These abuses will ran rampart.
"Hey, here is a free amazing resource BTC has which, incidentally, is great for newbies, usability and further adoption."
"Oh cool. IMPERIALIST MODE ON. Let me capture them all before anyone finds out, and then sell for 20 a pop out of thin air."
Nothing further from the ideals of BTC and precisely the opposite of what we need right now IMHO, but I can't however negate the fact that a free market is a free market after all.
Well, the actual plan is less about jacking them and reselling them, and more about putting them on physical bitcoins, because I think that is a fantastic use for them. |
|
|
|
A large manufacturer mining / "burn testing" for 2 weeks does drive up the difficulty, which makes the unit less profitable. There won't be much problems if you did "burn testing" on testnet but of course nobody will do burn testing if it's on testnet.
The picture of their burn testing rack looks like it might handle a hundreds Jalapenos or a couple of dozen Singles. I don't think that's going to change the world. Not to mention they're just doing burn-ins for 24 hours on each unit anyway. |
|
|
|
Looks pretty good Jan. My only comment is that the line "The order of appearance..." is largely irrelevant. We have agreed that order in a block doesn't matter - all addresses with matching firstbits in the same block will have characters added until they each have unique firstbits.
As I wrote just above: ... Regarding this: ... If it is possible (is it?) for an earlier tx to spend the output of a later tx in the same block, we would have to be careful about whether the earlier one's input script triggers "appearance" of the address in case a competing address appears in a third transaction between those two. The rule about "all addresses appearing in the same block" avoids that issue, while unfortunately making some address prefixes ineligible ever to become firstbits.
...
I am pretty sure that an earlier tx cannot spend outputs from a later output in the same block (the other way around happens all the time). I had the same worry when I did my block chain loader back in october last year and included some hefty logging in case it appeared. It never did. The specification and implementation will be cleaner without this corner case. ... This adds unnecessary complexity, potentially invalidates old firstbits addresses, and is incompatible with what other implementations do today. I really think it is a bad idea. It would be interesting to find an example of such a case to compare how it is resolved on any services that work with firstbits. I have a feeling they are not all resolved in the same manner. I disagree regarding complexity - I think it actually makes implementation much simpler, which is why I like the change. Yes, it will invalidate a few specific firstbits - perhaps we should run some sort of script to find out exactly which firstbits would be invalidated. |
|
|
|
The problem is that the OP is being very cheap. He sells first bit addresses for $20 a pop on his site but wants to pay us (0.4*85/35000)= a fraction of a fraction of a fraction of a US cent per address.
I am open to offers. If you can't run your business yourself, don't ask other people to do the hard parts for you.
I'm outsourcing... why is that a problem for you? |
|
|
|
Has he updated to support 1.2.5 firmware yet?
Could be that.
The reply in 1.2.5 adds the chip that found the result - in your case that says:
8636095F59A... = midstate
2BA85F... = blockdata
1=chip
0=nonce count
1.0.0 Jalapeno or PARALLELIZATION disabled, would not have the "1," in there.
That's what it is. Thanks. I will have an update for this soon.  Excellent! Please let me know when the update is out - I really am not a fan of Easyminer. |
|
|
|
|
Show Posts
