Do you have a bitcoin.conf or start with any special arguments like telling it to connect to a single particular node or use a proxy?  How many connections do you have when the node is running? Are you running low on disk space?

Did you really delete _all_ the files except the wallet.dat, including the database directory and _db.000 files?

What do you mean by "fails"? It's not unusual for it to stop and wait until the next block on the network is found during syncup.

The reason you were unable to start until you deleted your database is probably because your software was not cleanly shutdown before upgrading.

Neither is, you shouldn't use firstbits— not only does it encourage spamming, but it's fundamentally incompatible with pruning which will be required in the future to keep the cost of running a bitcoin node manageable.

As was mentioned it was unresponsive during the initial syncup— it was busily syncing blocks so quickly that the rest of Bitcoin was being starved. This will probably improve in later versions.

Bitcoin uses more resources now because the chain is much bigger— but current versions are actually much faster when compared apples to apples.  Bitcoin is very fast on tmpfs.   

Are you running two copies of the same wallet on different systems? Because thats what this sounds like— it sounds like you have the same wallet (or private keys) running in two places and they've been used enough to have diverged and one is confused by change generated by the other.

This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery.   I inquired about this claim before and I don't believe I got a reply: https://bitcointalk.org/index.php?topic=81045.msg899922#msg899922  Luke-jr also expressed skepticism: https://bitcointalk.org/index.php?topic=81045.msg899911#msg899911

 I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems.   Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.

That said— if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.

What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined.  ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.  

There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client.   Moreover, many aspects of Bitcoin security require that you be a part of the majority clique— even if the majority is "wrong"—, if you can be moved onto a minority chain you can be robbed.   Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk.  So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.

It might be more efficient to raise funds to fix whatever you don't like in the -qt GUI— even if there are irreconcilable differences maintaining a fork of the QT gui would be a lot less work than WX, it's easier to get people willing to work with QT, and the WX version is even a pain to build.

Next time you update the stats, could you also include "megabytes added to the block chain" and/or "percent of total bitcoin transactions"?

Martingale on a negative expectation game still has negative expectation so it's the users who are susceptible to it, not the site.

(Casinos avoid it because its procedurally disruptive, and rapidly ruins customers they're rather milk, not because it makes the games net positive for the players)

Has nothing to do with bitcoinica and everything to do with a crazy gambling site which operates in a way that produces a ton of transactions.

It depends a lot on the peers you happen to get. 0.7.0 will probably improve the sync speed in the face of lousy peers.  If your peers are fast and reliable you can pull the full chain in an hour or two.


You won't see your transaction show as confirmed until you catch up to the point in the chain where they were created.

I think we're miscommunitating somewhere, but I'm not sure where.   There is no publicly available Bitcoin software which is able to "see" the double spend and alert the site and the network itself won't propagate the conflicting transaction, so even if such software was widely available it would not be very effective.  

There is no amount of waiting, short of the first including block which is sufficient to show evidence that most of the hash power isn't attempting to mine some conflicting transaction, at least not currently.

There are things that could be done in the protocol to help this, e.g. flooding information about the existence of double spends.  Or merchants with hacked up software which abusively tries to connect to the whole network may have a fighting chance ...  but in the direct and obvious implementation with current software, what you're suggesting is not safe.  Suggestions like having the node remote might be a good idea— though they're bad for reliability... but that isn't even something our community advises as a best practice.   Security isn't about being secure iff you get lucky and a bunch of random characteristics about your setup happen to be the right ones that make an attack hard.

First— do you mean the 500k soft target or the million byte protocol rule?

The soft target is trivially lifted a node at a time. I expect the default soft limit will change once the network is consistently producing blocks up against that limit.

So I'll assume you mean the protocol rule—


I haven't done the benchmarking to fully figure out exactly where a standard PC peters off, but I'm pretty sure they can process somewhat more than the current limit, at least if they're SSD equipped.  So even if you're a full card-carrying member of my Church of Forever Decentralization,  whos doctrines requires that the maximum block sizes stay quite small,  you could still support a bit of a bump.


It's worth mentioning that beyond escaping the limits external things can have other advantages too.  For example, even getting a _single_ confirmation in Bitcoin (the minimum required to resist reversal attacks without using a trusted certification serice) can take a long time— 10 minutes is an _average_, but 30 minutes or longer happens about 7 times per day, an hour or longer every 2.8 days, etc.    And even though Bitcoin with the block size limits removed could be coerced to insane scaling levels, it would be a fairly storage and computation inefficient way to process all the world's transactions.   D'aniel also points out the considerable privacy/anonymity advantages other systems can have over Bitcoin (and add to Bitcoin when used along with it)


The limit can't be raised at all without a hardforking change (old nodes will not accept the new chain at all once the first oversized block is mined).  

It's not sufficient to change miners, as DeathAndTaxes suggests— the lifting the 1M protocol rule is a change unlike the BIP16/P2SH change which was fully compatible with old nodes. It's technically the same kind of change needed to adjust Bitcoin from 21m total BTC to 42m total BTC (though obviously not politically equal).   Every single piece of Bitcoin software produced would have to be updated to allow the oversized blocks

If the Bitcoin system were to take a hardforking change, switching to Ed25519 would remove ECC signature validation as a performance bottleneck, as  a fast quadcore desktop from today can do about 50k Ed25519 validates per second, compared to perhaps a thousand for the curve we use... though the random IO is still an issue.

More recently a number of people have independently invented the idea of committing to a merkle tree of open transactions.  If we do adopt some form of this it would allow the creation of nodes which are someplace in between SPV and a pruned full node in terms of security and decentralization benefit— so lower operating costs for nodes that validate. (In particular these nodes would have greatly reduced storage requirements)


Indeed, and Mike's position has gotten us (rightfully) flamed as not-decenteralized by e.g. Dan Kaminsky.

Gavin and Jeff have taken less strong positions than I have on the importance (and viability) of maintaining decenteralization in Bitcoin.  Although I expect to convince them eventually,  I think _everyone_ is in a wait and see mode.  Who knows what will happen?  At the moment I would aggressively argue against raising the limit— without it I don't see any alternative to Bitcoin becoming a particularly inefficient distributed system of establishment central banks— but I fully admit my position may change as things develop.  

I expect most Bitcoin users by count to be not even SPV— I expect most by count to be semi-SPV thin-clients (which may connect to a couple independent services). But expecting most users to be on not nodes does not preclude there being hundreds of thousands of nodes which perform complete validation, but gigabyte blocks surely would.

Others have pointed out that you can do more than one attack per block—  but not only that, but:

There is no double spend propagation, notification (even when it propagates to the victim), or repercussions (at least so far I'm not aware of anyone successfully being prosecuted for bitcoin based fraud, though I expect it will happen someday) ... this means that I can give my victim a transaction but 1ms later simultaneously give the same transaction to all the big pools.    The whole network will be my attacker then.   

The point of the Finny attack is that even fancy listening and alert stuff can't protect you against an attacker than can mine.  But even without the finny attack the lack of detection and notification means that zero confirmation transactions are trivially reversed without significant technical sophistication or expense.   They simply aren't safe for non-reversable/non-recourse transactions  (of course things like Spamoshidice are somewhat safe because reversals there also undo the payout),  and the finny attack means they can't easily be made safe.   

Of course, safety isn't always required but people should be aware of the risks.

It allows me to get instant on demand access to large amounts of hash power at low cost and direct it how I like it.

One of the barriers to a Finney attack is that you have to cause a block to be mined with a valid but not publicly announced transaction— without tens of thousands of dollars of fixed equipment costs you can't do this without having to wait with your finger on the attack trigger for years.   GPUMAX lets you purchase hash power with Bitcoins, (which will, more or less be returned to you from successful mining,  the only cost to you is the GPUMAX marketplace premium on hash rate and the slight chance of increased orphaning).  

Effectively GPUMAX somewhat violates the security assumption of Bitcoin:  We assume that hash power is well distributed and at worst consolidated in a manner proportional to parties long term interest in the Bitcoin system.   By allowing the highest bidder to redirect hash power at will, a party can get enormous amounts by paying a small premium for just the time they need it.   I understand that the GPUMAX system has some protection against attack usage (though I've not heard details and don't know how complete they are), but the finny attack case is basically not possible for a middleman system to protect against because it looks so much like normal mining.  (In fact you can finny attack using an existing pools, if you can find one that either won't relay your double spend or you simultaneously put conflicting txn on their peers to prevent relaying of it.— GPUMAX lets you move hashpower where you need it for the attack)

As I've pointed out before on IRC,  this isn't the way to accomplish what you want. A "one write many read" blockchain can not be accomplished with a simple patch— it would take either significant and hazardous rewrite of BDB, or a hazardous rewrite of bitcoin to use something custom instead of BDB.   Even if someone managed to pull it off I'm doubtful we'd take it upstream.

Instead, it appears to be generally agreed that we want to split the blockchain and the wallet— so you could have one trusted blockchain and N wallets (GUI or CLI/RPC) talking to it across the network.

I don't think it's worth time formalizing it unless you're having fun in the process.   We already think the keys and addresses are too long and generally want to move away from humans directly handling them where we can.   One fun point about base-32 is that since log2(32) is an integer, the digits form a Galois field and you can easily use either a reed-solomon error correcting code or a well tuned CRC for much better error handling (e.g. absolute certainty that no N point mutations are also valid).

It's come to my attention that some people are underestimating the danger of accepting zero confirmation transactions because they don't understand the finny attack and/or don't realize how easy and cheap things like GPUMAX make it.  

Are there any actual sites accepting 0-confirm transactions?  I'd like to perform a finny attack demonstration with the consent of the site operator in order to better educate users about this risk.

The thing you're missing is that Casascius was of the opinion that he had absolutely no room for longer.  Otherwise the keys would absolutely have been >=128 bit just to meet the normal good standards practice.

Base-58 already omits the most easily confused characters, including 'l'  (which can be confused with 1 e.g. under a base 32 scheme).