I run 1.1.16 on both my forums.
My bad then, I was going off faulty information it seems. |
|
|
|
... Again, I just said you can get a 0.5C/W or lower heatsink if you go large or loud enough.... But no one wants to do that  The whole idea about FPGAs is that they are smaller, cooler, less noiser than GPUs. Even if you achieve 2.7C/W top power draw shouldn't be more than 17W, commercial grade chips, 25W industrial grade chips at 25C ambient temp. Compared to 40W of one chip in BFL Single is damn small value. And we have to remember that propagation delays thru silicon raises when temperature raise. More power draw, faster MHz limit = less MH/s. There is somwhere a sweet spot and it's defenitevely below 17W thanks to high Rthjc... Are we agreed? Yes, definitely. I wouldn't want to get nearly that close to the limit. That being said, if someone like eldentyrell releases a bitstream that does 250MH/s on an LX150 but pushes power consumption up to 15W, there are options out there that might be worthwhile to deal with that.  Thats up from 200 mhash, right? I wonder how many of these boards should have been equipped with big copper heatsinks instead. Watercool that shit. |
|
|
|
I can't see a workable solution either at the moment, which is why I'm trying to just shore up the EMC servers to handle LPs better. Maybe if there's some way to identify a "backup" LP request to the server, so the server can prioritize active LPs and backup LPs in a QoS fashion or something... that way LPs can be pushed out as best effort for the backup LPs. It would obviously require some changes to pool software, but I don't think they'd be that drastic and it would help out everyone.
Slush prioritizes his LPs already, it sounds like a good idea. Also, what is the bottleneck with many LPs? Is it processing power? Memory hog? Disk reads/writes blocking? Running out of sockets? I wonder if it could or should be offloaded onto a dedicated box, if it is that much of a load issue. |
|
|
|
Nuclear mining operation either in a power plant or in a submarine. It will already have a water cooling system set up for the fuel rods which can be used for the mining rigs as well. Any excess electricity generated can also be sold for more profit.
Radioactive video cards FTW. Also, nuclear power plants use steam cooling, which is kind of hot for a video card. |
|
|
|
Even the admins and mods are subject to that limit. Sorry.
I admin a couple of my own SMF forums, it's changeable by default and with modification packages you can change it per user/group: (mods are also exempt by default)  Is that SMF 2.0 or 1.1.16? |
|
|
|
PM sent
With a scammer tag, why did you even bother? |
|
|
|
ROFL! cool story bro. You clearly know this is it for Bitcoinica what stake do you have in this ?
We have over 80% of our Bitcoins in offline wallets at the moment before the attack.
Offline == not stolen. Try again. |
|
|
|
I don't keep my real wallet in a public lockbox at a train station and I wouldn't keep a bitcoin wallet on public server at a datacenter.
Yes that was already covered extensively before you went off with a derail involving your "non solution". If Bitcoinica had avoided the attackers gaining access to the server containing the private keys then the theft wouldn't have occured. No custom protocol was required. If the attackers gained access to the server containing the private keys then the theft still would have happened. No custom protocol would have helped. Hence the whole point about your "custom timed delayed protocol" being of dubious value. Most (all ?) major thefts involving bitcoins was a result of attacker gaining access to the private keys. Not sure how the hacker would gain access to the server when the only network-accessible thing is the custom interface as previously stated. Did you think I was trying to come up with a solution to stop the hacker after he already gained access or something? Yes it sounded like that, because that's what happened. The "only network accessible things" extend to the control panel as well as the server itself. Sure, if you are in complete control of the hardware, making that interface difficult to access is common sense (actually it is always common sense), but when someone can reset the root password at the click of a button, that isn't going to help you. In that case there is no possible solution. Not even an encrypted filesystem will help because it will still be mounted. You can't reset the root password on a mounted filesystem, and you can't access an encrypted filesystem after a reboot without the password. EDIT: I might as well make it crystal clear that you can't reset the root password on a mounted filesystem externally without access to the password itself. |
|
|
|
ding dong MR Z i see you online where are the updates  No updates. They are probably busy packing up. Why wouldn't they ? BTC is 0 value in legal system  As long as they give you all the USD / fiat back then they are 100% clean legally. Very funny putting the meatspin crap up AFTER the BTC was stolen ... real clever proof of you getting hacked zhoutong ! What a joke ! Dude, what is up with your profile on this forum ? what a mess lol I am celebrating my 1 year anniversary on this forum with a proud scammer tag. Soon zhoutong will join me, by the looks of things  ROFL!!! Whole bunch of these guys are going to be given scammer tags LOL either that or long prison sentences! Who are these "founders" can someone list them here ? WTF you idiots, shut the fuck up about a scammer tag already. It hasn't even been 12 hours for them to review the security of the system, and you think that it is all gone. No it isn't all gone it just takes a while to get things back into a secure and operational state. |
|
|
|
I don't keep my real wallet in a public lockbox at a train station and I wouldn't keep a bitcoin wallet on public server at a datacenter.
Yes that was already covered extensively before you went off with a derail involving your "non solution". If Bitcoinica had avoided the attackers gaining access to the server containing the private keys then the theft wouldn't have occured. No custom protocol was required. If the attackers gained access to the server containing the private keys then the theft still would have happened. No custom protocol would have helped. Hence the whole point about your "custom timed delayed protocol" being of dubious value. Most (all ?) major thefts involving bitcoins was a result of attacker gaining access to the private keys. Not sure how the hacker would gain access to the server when the only network-accessible thing is the custom interface as previously stated. Did you think I was trying to come up with a solution to stop the hacker after he already gained access or something? Yes it sounded like that, because that's what happened. The "only network accessible things" extend to the control panel as well as the server itself. Sure, if you are in complete control of the hardware, making that interface difficult to access is common sense (actually it is always common sense), but when someone can reset the root password at the click of a button, that isn't going to help you. |
|
|
|
I don't keep my real wallet in a public lockbox at a train station and I wouldn't keep a bitcoin wallet on public server at a datacenter.
Yes that was already covered extensively before you went off with a derail involving your "non solution". If Bitcoinica had avoided the attackers gaining access to the server containing the private keys then the theft wouldn't have occured. No custom protocol was required. If the attackers gained access to the server containing the private keys then the theft still would have happened. No custom protocol would have helped. Hence the whole point about your "custom timed delayed protocol" being of dubious value. Most (all ?) major thefts involving bitcoins was a result of attacker gaining access to the private keys. What about a setup where hot wallet is on separate machine which periodically fetches instructions for transfers. Attacker would have to reverse engineer the setup in short time from obtaining access to alarm being raised. The main server can be collocated while hot wallet server can be in a basement of undisclosed private home. You can do this with multisig transactions. |
|
|
|
We're already seeing Quad FPGA chips on a single board for $1k and other designs with expandable daughterboards etc similarly priced for the number of chips and total hashing power. And they will have to compete with each other for customers thus lowering the price of FPGAs. Then we'll see some custom FGPA multicore processor maybe with 4, 8, or maybe 4096 FPGAs all in a single chip. And then maybe the first quantum computer that can be used to solve sha256 will get purposed for Bitcoin mining. And every increment of overall tech performance will push up the difficulty, and force people who want to keep being competitive at mining to upgrade their hardware, and the network will end up more secured as a result.
And even when quantum computers are mining, and the difficulty is 1 billion, there will always be some poor noob mining away on his Pentium 4 in his mother's basement, hoping to strike it rich.  |
|
|
|
Perhaps while everyone is distracted with the bitcoinica debacle... Not me! |
|
|
|
There is nothing to reverse if the transaction is canceled during the grace time before it is executed on bitcoind. There is no server to hack into when the only network-accessible thing is the custom interface.
There always is a server. Some custom protocol doesn't change the fact that a server exists. When you send a command using the costom protocol where is going? Obviously bitcoind is running somewhere. Your solution is no solution. Attacker would simply bypass the stupid "interface" hit the real server and steal the private keys. You do understand the private keys are simply numbers right? If you have the numbers you have the funds. Thieves don't need to use the lockdown bitcoind. They steal the private keys and execute a transaction from anywhere in the world. Why would you have a custom interface but leave the bitcoind rpc port and ssh open to the public? Are you intentionally missing their point? Are they implying the hacker had physical access to the machine? Yes, close enough when the machine is a VM on a cloud somewhere. |
|
|
|
& just to clarify, with the new site we can now reuse the 4 deposit addresses that we are initially given with np I assume, instead of needing to generate new ones each time I assume, much handier for me to just keep 1 or 2 of these in a wallet labelled for GLBSE deposit address, thanks for the improvements & hope that the doors can open again soon for buisness
While this is handy, ALWAYS confirm the address on the site before sending funds to it. Remember when Bitcoinica was hacked the first time? The deposit addresses were compromised, and some people continued to send funds to the old addresses because they didn't log in to check and see if it had changed. |
|
|
|
How do you intend to prove that you didn't deliberately give someone the private key? Private keys have become a form of payment in their own right; for example, you can provide one to MtGox to fund your account. A key isn't necessarily "stolen" just because you had it first, and now someone else also has it.
So far as the bitcoin system is concerned, possession of the private key is ownership. The damage is in the unauthorized access to your computer, and for that you need to show that the key was copied without your consent.
That is where the RSA/PGP/GPG/etc key comes in. If you for some reason wanted to give a private key to someone (why?) you could create a message with your signing key to say that it was authorized. You could, but the absence of such a message does not mean the transfer was not authorized. Moreover, unless everyone timestamps their keys this way, anyone who does not have such a timestamp is left with the task of proving a negative--that they do not have a timestamp to sign over. Actually, that could be a problem even if you do sign over a timestamp, since nothing prevents you from having more than one, dated earlier than the one you signed over, which you've been keeping to yourself. You could mitigate this by only considering timestamps which have already been made public, but it seems easier to me to simply secure your private keys. Quite so. I brought this up because the last time Bitcoinica was hacked, there were those that were saying that they should not be pursuing the recovery of their funds because it would not be possible to prove in court that they had ownership of the funds/keys first. This provides a way for a public entity to prove ownership based on a timestamp, and as we saw this morning, private keys can get stolen from large public entities too. I would love to see better security on everyone's private keys. |
|
|
|
There is nothing to reverse if the transaction is canceled during the grace time before it is executed on bitcoind. There is no server to hack into when the only network-accessible thing is the custom interface.
If the keys are stolen, ANY bitcoind can make the transaction, doesn't have to be on the compromised server. |
|
|
|
This could have been avoided by not using the standard bitcoind rpc interface. If you have your own custom interface in between you can add large amounts of security measures such as withdraw verification and grace time. The hacker will also not be able to look up how your interface works by going to Google.
How do you know? From what we have heard, it has nothing whatsoever to do with the cracking that took place. Or do you have some inside info? 18,000 BTC was withdrawn. If you had a custom interface you could make it piss red flags when it sees a transaction with such a large amount. Which does nothing since Bitcoin is irreversible. The most likely attack vector was a) gain access to rackspace admin console b) reset root password c) login as root d) steal private keys So what exactly would a custom RPC do about that? And to add more flames to this raging inferno, Rackspace maintains backdoor root accounts on their managed servers to perform backups and maintenance. I'm not sure whether this applies to the cloud servers or not. |
|
|
|
|
Show Posts
