Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet.
Only people trying to create new coins would need to run network nodes.
It is strictly necessary that the longest chain is always considered the valid one.
When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it’s now invalid according to the accepted chain.
At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.
I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it’s not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.
Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.
For greater privacy, it’s best to use bitcoin addresses only once.
Being open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it’s essential for a program of this nature to be open source.
Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of freedom for several years. Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.
If you don’t believe it or don’t get it, I don’t have the time to try to convince you, sorry.
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.
I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.
Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don’t have to worry about a chain of custody of communication. It doesn’t matter who tells you a longest chain, the proof-of-work speaks for itself.
As you figured out, the root problem is we shouldn’t be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.
Bitcoin isn’t currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
This helps keep you from turning your coins over rapidly unless you’re forcing it by actually turning all your coins over rapidly.
I’ve been working on bitcoin’s design since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn’t resist to keep thinking about it.