Hummm... I was able to use one patch or the other. When trying to use both patches, I couldn't apply the patches. Perhaps I did something wrong. I will try again.
patch is not meant to be used blindly. You're supposed to look at the reject file manually and figure it out. The problem is caused when trying to patch the section of rpc.cpp around line 1330. Both patches try to apply their changes to the bottom of the list, with context looking up. They modify each other's context. To fix this, they should be applied to the top looking only up or the bottom looking only down. (Not sure if you can actually do this, however.) |
|
|
|
|
I think the technology is pretty safe. There's nearly no chance that your bitcoins will be lost because the network screwed up.
I expect the price to go down in the short term, however.
|
|
|
|
Thanks ive got it sorted now, maybe you can help me with one last thing, how can i display ฿ icon in html?
฿ |
|
|
|
If someone rejects a block that most of the network accepts, won't the rejecting nodes eventually give up on the rejecting branch and move to the longer branch that accepted it?
If you reject a block, then all blocks after it are also invalid from your point of view, no matter how many other people accept them. If this was not the case, then an attacker could create bitcoins out of thin air by getting more than 50% of the network's CPU power. This effect was demonstrated when the overflow bug was fixed: even though 0.3.10 nodes were in the minority, they rejected all blocks produced by old clients (which contained a fraudulent and impossible transaction for 184 billion bitcoins). This is not quite the case for timestamp issues, but there is a similar effect. If your clock is off, you won't accept any new blocks, as they'll all be too far in the future. You'll eventually get the blocks when they are no longer too far in the future, but you'll still be unable to generate because your view of the "latest valid block" is wrong. The same problem would happen if someone double spends a coin, and nodes disagree on which one came in first. The majority will make a longer chain and the minority nodes will have no choice but to jump over. You don't reject blocks for transaction timing/ordering issues. |
|
|
|
|
Logout usually just deletes all authentication cookies on the user's browser and removes those tokens on the server. It's pretty easy to do.
You can probably do it yourself, but I'll do it for 100 BTC.
|
|
|
|
|
Add funds -> Put an amount in the lower "Add Bitcoins" section -> Click "send bitcoins" -> A JS popup thing will appear with the address you should send bitcoins to. Funds appear after 6 confirmations.
|
|
|
|
Bitcoin should absolutely not be sending the computer's time to the network. Nor should it depend on the clock being set properly. Each node can keep track of when they see transactions come through. If they want to reject a block because it contains a transaction they saw too long ago, then they are free to reject it; no reason for the nodes to compare each other's clocks. If it's too old they will all reject it, which is what we want.
If someone rejects a block that most of the network accepts, then all of the blocks that they produce will be invalid and transactions won't gain confirmations from their perspective. This is about times of blocks, not transactions. Block timestamps are used for the difficulty calculation, so they can't be too far off from reality. |
|
|
|
|
I'm not surprised.
Such a high rate of chargebacks does not bode well for future CC->BTC trades, no matter what intermediary companies are used. Identity verification is the only real solution if you want to do that.
|
|
|
|
|
Bitcoin can already pay to an IP address. It wouldn't be a big deal to add DNS support. Maybe an address in a TXT record could be used as a fallback if the IP address isn't accepting payments.
DNS and IP transactions aren't secure, though. (DNS will be perfect for this once DNSSEC is available everywhere.)
|
|
|
|
Bitcoins aren't infinitely divisible. The smallest amount is 0.00000001. Once the halving would make a subsidy lower than this, the amount will go to 0 because the calculation is done as a bitwise right shift (of an integer holding the number of nanocoins). It just so happens that the total number of coins in this scheme ends up being very near 21 million (20,999,999.9769) Even if the precision is greatly increased, the number of BTC in existence would never go above 21 million. See: http://theymos.ath.cx:64150/btcstat.php?q=changeparams&precision=200(Changes precision to 200 instead of 8.) |
|
|
|
We are currently using the address: 1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt, however the market site states, "CAUTION: ALL BITCOIN ADDRESSES FOR DEPOSITS HAVE CHANGED" and I'm not certain what that means. What am I missing? Tell them that this is only relevant for people who had BCM's receiving address saved. BCM regenerated everyone's unique address for deposits into BCM. The warnings at the top of bitcoin.org, bitcoin.org/smf/, and BCM don't look good to outsiders... It makes the system look unstable. |
|
|
|
And yes, since the documentation for the "lose all yer bitcoins" behavior is found only in threads like this, that's a bug and a damn big one.
A warning about this was in the very first revision of the wiki's "backup" page (from July). An elegant and anonymous solution will be implemented at some point (a list of queued addresses will be included in wallet.dat for use with change). Until then, deal with the fact that this beta software requires more frequent backups. |
|
|
|
|
I don't see how this can last. 100,000 BTC in bids+asks on MtGox, but 7,200 BTC are created every day. The market just can't absorb it.
Of course, I've been bearish about the market since I was selling (below the normal market rate) at 0.003.
|
|
|
|
|
If you give the user a machine that can decrypt something, and then you give them the key and the ciphertext, then they can decrypt it. You can make it difficult if you make them use special hardware with the key/ciphertext/encryption embedded, but you're still giving the information to them, and it's still possible to reverse-engineer.
|
|
|
|
|
I played the demo. It's an interesting casino game. The odds are certainly against you, but it's possible to make a profit. There's one 2-player game (so far), and if you're good at it you could clean everyone out.
I saw two slot machines, a unique multi-player/community game, a coin-flip doubler type of game, and a two-player bluffing game. Also, nearly every plant in the game is a gambling device with different odds. There are tons of opportunities to gamble.
|
|
|
|
What it comes down to is that only the program itself "knows" the bitcoin private keys and the code inside the cointainer. They would never be revealed to the host. I don't mean security by obscurity like spaghetti code, what I mean is that no amount of reverse engineering would reveal the contents of the container. This is impossible. The CPU needs to know the encryption key to decrypt the container; there's no way around this. |
|
|
|
|
What will you do if the major governments make Bitcoin illegal and actively try to shut it down? Will you resist them?
If Bitcoin becomes bigger than PayPal, how do you see the organization of the project? Will you continue to develop it more-or-less alone, will there be a secret group of developers like TrueCrypt, will it be a massive community-driven project like Firefox, or what?
|
|
|
|
How long did it take to get connected with TOR the first time, having to use the seed nodes?
I gave up and used -addnode after 10-15 minutes. I definitely was unlucky in exit node selection, since I've been able to connect to IRC with Tor a few times since them. |
|
|
|
While I was trying out Bitcoin with Tor a while ago, I found that it was impossible to get connected in a reasonable amount of time. See the debug.log excerpt below. Starting 2 BitcoinMiner threads
BitcoinMiner started
BitcoinMiner started
trying connection lastseen=-2.0hrs lasttry=-357170.7hrs
proxy connecting
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 71 seconds to reconnect
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
trying connection lastseen=-2.0hrs lasttry=-357170.7hrs
proxy connecting
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 138 seconds to reconnect
trying connection lastseen=-2.1hrs lasttry=-357170.7hrs
proxy connecting
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
DelayedRepaint
trying connection lastseen=-2.1hrs lasttry=-357170.8hrs
proxy connecting
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 211 seconds to reconnect
DelayedRepaint
trying connection lastseen=-2.1hrs lasttry=-357170.8hrs
proxy connecting
proxy connecting
trying connection lastseen=-2.2hrs lasttry=-357170.8hrs
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 292 seconds to reconnect
trying connection lastseen=-2.2hrs lasttry=-357170.9hrs
proxy connecting
DelayedRepaint
DBFlush(false)
addr.dat refcount=0
addr.dat flush
ler exiting
ThreadMessageHandler exiting
blkindex.dat refcount=0
blkindex.dat flush
ThreadIRCSeed exiting
ThreadBitcoinMiner exiting, 1 threads remaining
ThreadBitcoinMiner exiting, 0 threads remaining
wallet.dat refcount=0
wallet.dat flush
StopNode()
DBFlush(true)
Bitcoin exiting I know that the guy who operates irc.lfnet.org is around here. Maybe he can remove that hostname limitation, since it's blocking some users. Also, most of the seednodes are gone. Only 37 out of 230 are accepting connections on port 8333. This makes connecting without IRC very slow. The offline ones should be removed. A list of online seednodes is attached. |
|
|
|
|
Show Posts
