Email is perfectly capable of operating in this manner. If everyone ran their own SMTP server, then it would be "fully" P2P. However, most people prefer to use a centralized service. The system is still P2P, though, since it's entirely possible for two people to communicate directly.

In the future most Bitcoin users will transact through MyBitcoin-like services, and running a full network node will require gigabit-speed Internet access. Does that make Bitcoin non-P2P?


If one SMTP server goes down, then the rest of the network functions just fine. Mail will even be delivered after the server comes back up, since other peers will keep trying to deliver mail for several days.

No one can ever create new bitcoins in an illegal way, even if they have 99.99% of the network. Similarly, no one can ever spend coins that they have never owned in the past.

Network nodes can't influence transaction verification unless they control a very large portion (>80%) of the network. They need to segment the network, surround peers, or block transaction/block propagation. It is a design goal of Bitcoin for network nodes to be as powerless as possible. Only computational power should matter.

Getinfo reports "keypoololdest", which is the unix time of the oldest key. When this time is after the time of your last backup, then your backup is too old.

Email is already peer-to-peer. Using my SMTP server, I can send and receive email to/from anyone without relying on third-parties. I could even send email using telnet if I wanted -- the basic protocol is (unsurprisingly) simple.

Good writing, though it could use some editing. I see many comma splices and other errors.

It should be remembered across sessions. The setting is stored in your wallet.dat.

This was also reported here:
http://bitcointalk.org/index.php?topic=3573.msg50559#msg50559

Probably just a temporary malfunction.

The single transaction is the generation transaction that pays to the generator. All blocks must have at least this one transaction.

There just weren't any new transactions at that time, probably. There are tens of thousands of blocks like these. Blocks are created regardless of the number of transactions, and the hashing scheme is set up in such a way that adding transactions doesn't slow down hashing at all.

Even a block with just a generation transaction makes it more difficult for previous blocks to be reversed.

The label is not public. You can't easily pass messages via Bitcoin.

The idea is OK. I would have just used plain text instead of HTML. Bitcoin sends blocks in chunks of 500 -- splitting in chunks of 10 seems excessive. I don't like having to convince someone in the system to pull data from me.

Gavin mentioned that using the -rescan switch significantly reduces the "download" time. Does -rescan do verification?

There's some info here:
https://en.bitcoin.it/wiki/MyBitcoin_SCI

That won't make everyone else accept the change. No one who already has BTC will want it to go down in value.

The addresses don't look like EWallet addresses. Usually there is significant "churn" with transactions sent to EWallet addresses, but these transactions have not been redeemed even after a month.

Maybe his wallet was on one of his servers, which he lost access to.

You'd have to remove the transaction from wallet.dat somehow. If you know the wallet format in detail, you could remove it with a hex editor. Otherwise, it's probably not too difficult to modify Bitcoin to do it.

Normal transactions will get moved to the new chain. Only invalid transactions get removed.

The split after the overflow incident was nearly 120 blocks long, but no one reported any lost transactions.

Bitcoin almost supports this. It would work like this:
- You send a transaction to your heir with nLockTime equal to the block number they can claim it at.
- nLockTime prevents miners from including the transaction in a block before the specified time.
- If you're still alive, you can reverse the transaction at any time before nLockTime by creating a transaction with conflicting inputs and lower sequence numbers.

The code for handling this already exists in Bitcoin, and the heir could even receive such transactions with Bitcoin 0.3.19, except that the in-memory replacement feature necessary for the last step was disabled.

You can't do it in a transaction's script because it's too dangerous. Consider this scenario:
- You create a transaction that pays to a before and including block 200,000 and b after block 200,000.
- The transaction gets in block 200,000, paying to a.
- a spends the coins, and the recipient spends the coins, etc.
- However, it turns out the network was segmented during this. After 60 blocks, the network recombines, and the transaction is now in block 200,001. A huge number of people lose transactions because the original transaction now goes to b.

This is worse than when generations become invalid after a split because generations can't be spent for 120 blocks. Time-limited transactions could be spent immediately (maybe it would be OK to use them if there was a similar maturation time). They're worse than double-spends because massive losses due to time-limited transactions could happen accidentally.

I'll do it.

You might give a discount because Bitcoin has no fees, while credit cards and Paypal do. For the same reason, some people give a discount for payments with cash.

ICANN itself is located in the US, as is Verisign (.com, .net) and PIR (.org).

I think ICANN will try to do something about this eventually. Once countries on the Governmental Advisory Committee become angry/jealous over the US's ability to take down random websites, ICANN will need to act.