(1) your power is a lot more expensive (2x or 3x more, eg. $0.20-0.30/kWh) That's the UK, then. Ave price (before recent ~20% rises) was £0.13 / kWh, about $0.21. Well these are approximate price ranges I quoted. Personally, at $0.20/kWh I would be on the fence... and probably still keep my GPUs.
|
|
|
so you get about 160 mh/s with one of these for what was it $450?? i dont understand how these are better than buying a graphics card for 150 and getting 350 mhs
Its a lot more complicated than that Arij! Yes you are going to pay around $450 and get only 100-110 Mh/s it seems, thats almost 4x-5x more cost than buying GPU's. But these things are almost magic and this is why. They connect via USB, So your rig can be anything that has a internet connection (and likely free..., This means no more $300 Power supplies. Hell you could run 10 of these cards on a old ATX 300 Power supply from a computer going to the landfill...) They consume roughly 1/8th 1/10th the electricity. Perhaps less? So every month the power savings will slowly eat up the 'savings' you think you have buy buying a gpu. You are wrong. For the majority of Bitcoin users who pay an average worldwide electricity rate of ~$0.10/kWh, buying a $450 FPGA board for only ~100Mh/s makes absolutely no sense from a financial viewpoint, given the current Bitcoin difficulty/exchange rate ratio. You wrote your post based on feelings, not math. I encourage you to run the numbers yourself. The only rational decisions for buying these FPGA boards are either (1) your power is a lot more expensive (2x or 3x more, eg. $0.20-0.30/kWh), or (2) you bet on the difficulty/exchange rate to sharply increase in the very short term, or (3) you are significantly power-constrained (eg. want to run a mining farm out of a small apartment).
|
|
|
I don't see how. All you do is create a fresh wallet, send the stolen coins to the fresh wallet, then send them to your wallet, and then to the exchange. How can anyone tell that this is any different from you receiving the coins legitimately?
For doing this, you don't even need a fresh wallet. Just create new addresses, send the coins to them, and repeat at will. My mechanism does not pretend to be able to differentiate the thief from someone who received them legitimately (hence the question mark at the end of my post). It would just allow to trace back to the thief, who would then have to invent stories explaining how he received them. If you start hounding people because they received bitcoins that were stolen a few transactions back, you reduce the usefulness of bitcoins to near zero. Consider:
1) You place an ad to sell some widgets for bitcoins.
2) Someone accepts your offer and sends you 10 bitcoins for the widgets.
3) You see that most of those bitcoins were stolen 10 transactions back 10 weeks ago. But you have no idea if the person who sent you the bitcoins did all 10 of those transactions between his own addresses and just waited 10 weeks or if the bitcoins have been in circulation for 10 weeks.
4) If you accept the bitcoins, and so does everyone else, then anyone can easily launder stolen bitcoins through you. If you do not, and everyone else doesn't either, the bitcoins become useless -- two weeks after you accept some bitcoins and send the widgets, you may find your bitcoins become unspendable. So you can't safely hold bitcoins and we all play hot potato with them. Yuck.
And, worse, whether you keep them or send them back, if you're not careful, you can easily contaminate your own bitcoin stash with the tainted coins.
While I certainly agree that forensic tracking of the stolen coins in the hope of identifying the thief is a great idea, trying to stop the spread of the coins will never harm the thief anywhere near as much as it harms legitimate users of bitcoins and the bitcoin system in general.
I entirely agree. Again, I am not saying we should refuse to accept stolen coins. This is just a forensic tracking platform that I am proposing.
|
|
|
And all someone would have to do is some quick laundering if they noticed some of the coins they had were on the list. Sending them to a couple of exchanges, then back to themselves would suffice.
Hum, no. In fact, the moment you send stolen coins to an exchange is the moment you can get caught and linked to a personal identity. In the method I described, stolen coins would be tracked by the Bitcoin client, including the clients used by exchanges/merchants to receive payments.
|
|
|
It would be nice if there was a centralized database/website where people like allinvain could report fraudulent transactions with as much details as possible ("theft of 25k BTC", link to forum thread), and if the Bitcoin client could check this database and would instantly alert its user when receiving coins that are linked to these fraudulent transactions. The receiver of the coins could report, on the website, as much info as possible about the sender of the coins, who could, in turn, be contacted, and so on, to trace the transactions backward up to the original thief. Think about this as an open platform for voluntarily de-anonymizing Bitcoin transactions.
Of course, some problems need to be addressed. One of them being that malicious users would attempt to pollute the centralized database by reporting many "fraudulent transactions". A rating system could be implemented to allow the community to rate the plausibility of each theft. The Bitcoin client would only alert its user if a certain level of plausibility is met. By default only the most well-known thefts that have been largely publicized would be tracked by the client. (For example most people recognize that the theft of allinvain's money is real, given how much energy/time he has spent on the forums tracking it and communicating about it.)
Another problem is that the original thief would most likely transfer the coins to a few addresses, and create a fake persona X pretending to have received them from Y, and them would spend the coin while pretending to be X. The voluntary de-anonymizer platform would be able to trace the thief at least up to persona "X" but would have no way to distinguish if X is the thief, or Y, etc. It would have successfully traced back to the thief, but its identity would be unknown, so... would that make it useful or not?
|
|
|
I pay 5.8$ for 250 kw That's exactly what costs 250kW for ~14min at $0.10/kWh, an average US domestic price.
|
|
|
I can provide backup of your wallet on 3 different dedicated server, hosted in 3 different datacenters ( wether you are an individual or an exchange ) . For trust concerns you can check my gpg Wot and my otc ratings
True Bitcoin hackers create a small, GPG-encrypted wallet and back it up by embedding it in the block chain itself, globally replicated around the world
|
|
|
"lost"? Do they think we are idiots? 17000btc and no backup, nothing? Ahahahahah
More like it was a scam.
It can be verified. I urge Bitomat users to keep track of the coins they recently sent to their Bitomat accounts, by monitoring the block chain, and report if there are any ongoing transfer.
|
|
|
what util would one use to strip it down to the size that normally gets released?
Simply " strip bitcoin"!
|
|
|
Of course you can join our quest and start deleting your wallets from today and help us get rid of bitcoin. Coin by coin by coin by coin! It is too late to get rid of Bitcoin. 6.8M BTC have already been mined. That's 6.8e14, or 680000 billion of the smallest divisible unit (10 nano BTC, or 0.00000001 BTC). There are about 830 billion USD in circulation, so: 830e9/6.8e14 = 0.00122 USD Meaning that the whole USD economy could be run on Bitcoin if its smallest unit was worth only one tenth of a US cent. Same thing for the Euro, as there are only 840 billion EUR in circulation. In fact, the whole worldwide economy could already comfortably be run on 6.8M BTC without its divisibility being an issue.
|
|
|
kwhcoin: but what backs gold?
|
|
|
Getwork returns data (essentially block header) and midstate. Midstate can be created from data. Data contains block header which MUST contain previous block hash. Block header contains also merkle root which is unpredictable but everything else must be consistent.
Hash is unpredictable but the data to be hashed must be valid. Otherwise the block will not be accepted by the network.
Right. In theory it should be possible to modify miners to check this previous hash. For some reason I only remembered the merkle root was here.
|
|
|
I already gave it to you. Multiple times. "In the last ~110 minutes only 6 blocks have been solved (135104-135109)"
|
|
|
6 blocks in a row that require twice the time are not statistically insignificant.
Yes it is. It happens many times every single week. Check the timestamps on blockexplorer.com. Also: The only visible effect is that the global network appears to solve ~6 blocks (instead of ~12) during these 2 hours; but no one notices because it happens all the time due to expected statistical variation. As a matter of fact, it is happening right now: in the last ~110 minutes only 6 blocks have been solved (135104-135109), and there is no reason to find this suspicious whatsoever.
|
|
|
OK, I have not used pools for a long time but if they return a valid getwork (and they should), then getwork returns the block header. The hash of the previous block is there. https://en.bitcoin.it/wiki/Block_hashing_algorithmPools only need to manipulate the target hash so the miners submit all the hashes of difficult 1 and above The attacker may try to spoof the data block, but then the hash of the data would differ from the midstate. The hash of the "previous block" in the getwork reply is actually completely opaque data to a pool miner, who cannot verifies whether it is legitimate or not. One reason being that it varies based on unpredictable data that is known by no one else but the pool owner (eg. the 50 BTC generation fee transaction). The only way to prevent the pool vulnerability I described is, as pointed out by DamienBlack, a significant rework of the getwork & pool interface: http://forum.bitcoin.org/index.php?topic=9137.0
|
|
|
Another detail is that with the half mining power you only get 3 blocks per hour because of the difficulty. So you need 2 hours in the first place to get a confirmation that MtGox accepts.
That's correct, and what I said from the beginning: the whole attack can be performed in 2h.
|
|
|
Well in that case, the attack would have to be ongoing for as much time as the number of confirmations. In the two hour attack, you can go undo 6 confirmations, in a two month attack, you could undo 600 confirmations (or whatever). Confirmations is still linked to time somehow.
Right. Got you. Personally, I would urge exchange owners to require 144 or 288 confirmations (nominally 24 or 48 hours).
|
|
|
|