|
The network is fine. Still chuggin away at 10.611 th/s. The DDOS'es have done nothing to make "bitcoin fail". Just a few pools that need better DDOS protection.
|
|
|
|
maybe divide big payments up into smaller transactions so you dont lose it all at once
There is no way to lose it, accept by sending it to an address you don't have control of. And a "typo" won't do it, there is a checksum, so the client knows what a real address is. |
|
|
|
|
Make sure the sending computer is hooked up to the network, aka, there are connection in the bottom right.
If all else fails, copy your wallet to a different computer, then run bitcoin with the -rescan option. It is possible the coins have never been sent, if that were the case, they will still be there.
But seriously, don't worry. You _can't_ lose your bitcoins like this. They are either in one address or the other, we'll get you sorted out.
|
|
|
|
GeniuSxBoY, are you serious?
The higher fee the faster the transaction get processed.
I've never sent any transaction fee above 0. Don't worry you can't lose it. Check your block number in the client. |
|
|
|
07/05/2011 16:27 I made a transaction of 80 btc to another wallet on another computer of mine, both with version 0.3.23 . I had by accident changed the fee to 0.00 btc but I sent 20 btc just a minute before and didn't think about it. Now it's been some time since I did the transaction and it's still Status: 0/unconfirmed and I'm starting to get really worried since that transaction represents the great majority of all my bitcoins. I know it's stupid to set the fee to zero but every time I have done it before the transaction went trough in 24 h. Another reason I'm worried is also becuase I lost 0.07 btc in the same way some time ago ( http://forum.bitcoin.org/index.php?topic=8048.msg118905#msg118905 ). I looked at blockexplorer and I can't see a trace of my transaction. Well I'm basically just want to know if there is any chance my transaction will get processed eventually or if I am just fucked? If I'm fucked I think I'll start losing faith in the bitcoin project, I guess I have done about a sum of 120 transaction and now lost two... Anyhow I would be grateful for any help. For example, have anybody experienced a really really slow transaction with fee set to zero?
Status: 0/unconfirmed
Date: 07/05/2011 16:27
To: 1AtwGxS9cZqViumwg2AjrBdNijTmCtz1We
Debit: -80.00
Net amount: -80.00You are fine. The DDOS on the pools has slowed down confirmation a little. Just give it a few hours. EDIT, Make sure that the number of "blocks" shown in the bottom of your client is 135223 or more. If it isn't your client just hasn't caught up. |
|
|
|
I'm sure these threads are very attractive to merchants.  If the price goes down, then merchants can charge more bitcoins. More = good. |
|
|
|
I've got client version .3.17 - do I need to upgrade it or something?
Probably not what causing it, or it might be, I don't know. That would be a good idea. If im not mistaken, the current version is .3.23 If I remember, there were connection issues with older client. Something about a pseudo-ddos. Try upgrading. |
|
|
|
Here, we see an illustration of Paul Revere warning the British that BitCoins are dropping.
With bells. |
|
|
|
|
I actually did sell about 50% of my bitcoins for this weekend. I've seen too many big dips during the weekend. I want in on one.
|
|
|
|
Curious if there's enough spread for profit after fees to sell on Mt.Gox and buy on TradeHill. Prices at this instant are: Mt.Gox: $15.44 and TradeHill: $15.22
Trader Steve
Those are just the last prices, you really need to look at the bid/ask. Tradehill often has really wide spread. The ask will be higher and the bid lower. You could put in your own bid/ask and wait, but there is no guarentee that by the time someone bites (if they do) that the arbitrage opportunity will still be there. |
|
|
|
The bitcoin client lack so many basic functions and features...
Well. if is only 0.3... Give it time, it'll get there. We are all early adopters here. |
|
|
|
|
Yes, that would be fine. But I would not recommend that be your _only_ copy you have. All of the services you listed have had "hiccups" and lost some people's data.
|
|
|
|
It is being worked on by smart people. Couldn't help but grab that one. Thank god for smart people! ;p Yes, if it were in my hands... heaven help us. |
|
|
|
Then the problem is insecure pool design.
I'm sorry. Have I somehow missed what this entire thread is about? Pools reduce the security of bitcoin. End of line. j Yes, but listen. IT IS FIXABLE. And smart minds are working on it. It is only the current manifestation of the pool system that allow these pool attacks to work. http://forum.bitcoin.org/index.php?topic=9137.0It is possible to have pools work with zero pool attack risk. It is being worked on by smart people. The new system will probably be adopted soon (within 6 months). |
|
|
|
Please answer to my posting: Your attack still assumes that you can split the internet. That you can dictate what blockchain each miner can see.
No need to "split the internet". The attacker simply withholds the block, on Tycho's server, that are being solved by the miners. Remember that these miners are not connected to the Bitcoin peer-to-peer network. There is no need to isolate them. But you have to distribute the block in the whole mining pool to generate the next one. No you don't. The pool pre-hashes all the data. The pool miners have no idea what they are working on, nor do they need to generate it themselves. |
|
|
|
This whole attack is possible but is not undetectable. The pool miners will know they are not working on the main chain. However, most of the miners will have no idea and the miner programs will not print it automatically.
The hash of the previous block is contained in the getwork data returned to the miners. If the miner program does the getwork to the local copy of the bitcoin daemon, it can compare the hashes and print warning. It happens occasionally though (some accidental chain forks), however if it happens twice in a row (chain fork differs by two blocks), it is very unlikely by accident and very likely by an attack. It does not seem to be very difficult to program into the miners as an option to print warning and better yet to switch to another pool if it is happening. If large enough number of pool miners switched, the attack would be prevented.
When you are in a pool, you only get pre-hashed data. You can't see anything you are working on. This is the main problem with pools. |
|
|
|
Again, it doesn't protect you, it just buys you time, because the attacker has to start that far back in the chain and build a longer chain. But the attacker will succeed (given enough time).
But in my attack, the attacker doesn't have to start "far back" in the chain. He starts forking it from the last known legitimate block... (sorry for my multiple edits, this is complicated) 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. Please answer to my posting: Your attack still assumes that you can split the internet. That you can dictate what blockchain each miner can see.
All the clients use the longest rule-following blockchain. If you can provide a longer one then the current one, everyone will use it. |
|
|
|
If an attacker has 50% of the hashrate (q = 0.5), then the math is completely off. No amount of confirmations is going to protect you against that.
Well, each additional confirmation buys you more time. It would take years for someone with 51% to undo a transaction with 1000 confirmations. No. Run the math. Run the sample Poisson code provided in the whitepaper. An increasing number of confirmation only protects Bitcoin for q < 0.5. For q >= 0.5, no amount of confirmations can protect anything. Again, it doesn't protect you, it just buys you time, because the attacker has to start that far back in the chain and build a longer chain. But the attacker will succeed (given enough time). |
|
|
|
If an attacker has 50% of the hashrate (q = 0.5), then the math is completely off. No amount of confirmations is going to protect you against that.
Well, each additional confirmation buys you more time. It would take years (edit, only months, because of earlier difficulty) for someone with 51% to undo a transaction with 1000 confirmations. |
|
|
|
It is still a double spend, and it is even more obvious if you spend on the main chain first and then try to reverse it. Check your debug log. The node already flags chain reversions and double spends. Sites that wait for multiple confirmations can (should) be watching.
Yes, but the evil pool would not release the "bad" block chain until the first spend already had 6 confirmations, got sold, and sent to dwolla. Then the new block chain would roll it all back. In that case: Step 10: A few minutes later, the legitimate block chain becomes longer than my forked chain, which invalidates the 500 BTC I transferred to TradeHill/Bitcoin7/MtGox. The 500 BTC automatically "reappears" in my original wallet. The exchange is short on BTC and is screwed. An investigation later in the day reveal that Tycho's pool was compromised. Tycho's reputation is ruined. People switch to another pool, which gains 50% of the hashrate. The attacker repeats the same attack on this other pool  This step won't work for two reasons. First, if the exchange sees your chain as legitimate, you need to assume that every miner also sees it that way. They will be working on the next block to extend your chain, not the old reverted chain. Your 500 BTC spend to the exchange will not be overturned on those grounds. Second, if you manage to somehow time your chain transmission so that it forces a race and gives the other chain a chance to get back on top, if it does take back over, every node on the network will instantly put your 500 BTC spend in their transaction list. Your recovery attempt will be seen as a double spend. So, you've spent 2 hours to get an instant transfer into an exchange when you could have just waited an hour. The OP set up his attack wrong. But it is still possible in a slightly different way, and he has since updated the original post to reflect the correct attack. This attack _would_ work, make no mistake. It is possible that the miners would all get together and roll back to the "original" chain, and then you wouldn't have any gains. But this would probably involve a lot of pain and suffering and could take days to get sorted, all the while the bitcoin network would be essentially down. There might be a whole lot of confusion over which transfers are real and which aren't and so on... Most likely, to avoid all of that, we would be forced to continue on the compromised block chain. And I really doubt anyone would notice in only two hours. Sometimes deepbit doesn't hit a block for a full hour and a half. And their stats are delayed by an hour to prevent pay-per-share manipulation. No one checks the shares they produce to see if they have a block. I don't even know of a mining application that tells you. Two hours is well within the time-frame for an attack. If Tycho doesn't notice, no one will. But still, I find it unlikely that anyone would be able to pull this off. It is more complex then just robbing the pool, for less gain. I don't feel threatened by the possibility. But let me make it clear, it is a possibility. And the odds are 50%, you don't need 6 consecutive blocks, because you are just holding all your block, waiting to release them later. It they are longer than the other chain, then all clients will accept them. That is a bitcoin rule. The longest blockchain is the "real" blockchain. |
|
|
|
|
Show Posts
