If I post a transaction with a fee that would be accepted by only one miner, I will have to wait much longer for my transaction to get into a block. If he controlled 1% of the mining power, I'd have to wait for 100 blocks on average. That may not be attractive to many users.

This is not quite right, but the code is pretty spread out. Generally un/serialization is done by the operator<< and operator>> methods of CDataStream in serialize.h. We do CTransaction tx; vRecv >> tx; to read a transaction object; or vSend << a1; to send something of template class a1 (in PushMessage in net.h).

The << and >> methods in CDataStream call Serialize() or Unserialize(), which do default the nVersion parameter to VERSION. But in these calls the default is not used, they pass the nVersion instance variable of CDataStream. And this instance variable is set to the min of the node and peer version, e.g. in the code I showed above.

Looking at the getwork code, it should only call CreateNewBlock() every minute or so:
This will call CreateNewBlock() either on a new block coming in, or on a new transaction if it's been 60 seconds since the last call. This shouldn't affect every getwork call, unless it's actually taking 60 seconds to do CreateNewBlock(), which would be remarkable.

The js-remote script implements a ssl web server, fully self contained. You don't need apache. Just run SSLserver.py, open up port 8338 for incoming, and connect with your mobile browser to https://yourhost.com:8338. Then you can access your wallet from anywhere, check balance, make payments, etc.

The person who originally had them would lose them.

Warning, lots of bad information and wrong answers in this thread!

Addresses are not created in batches of 100 (after initialization), they are created one at a time as they are used, so you always have a pool of 100 unused addresses.

Wallets do hold transactions, all the ones you see in the client window.

You would probably not want to share the same wallet between your home system and your phone, because of the risk of theft, any more than you would empty your bank account and carry all your money around with you as cash. Most people plan to hold a fraction of their assets in their phones.

Adding a check for a sufficiently low probability event means that the overwhelming majority of the time, the CPU or memory glitched, and it is a false alarm.

Adding checks for address hash collisions with existing addresses would not protect you against the creation of an address in the future whose hash collides with yours.

If you ever did generate an address whose hash collided with an existing address, you could steal any bitcoins held by that address. So you might not want to throw this windfall away.

I used to have trouble managing payments to a service that used a new address every time. Seems to conflict with the idea of an address book. Imagine if everyone's phone number changed every call. Not too convenient.

Here's what I do now:

1. Copy the payment address.
2. Choose Send Coins in the client.
3. Choose Address Book in the popup.
4. Choose New Address.
5. Enter a name for this payee, and paste in the Bitcoin address. Use the same name for all payments to this payee. For example, I use MBC for all transfers to my mybitcoin.com account.
6. Click OK in the New Address window.
7. Click OK in the Address Book window.
8. The Pay To field now holds the payment address. Enter the amount and click Send.

This way the transaction in your wallet will show who it's for. It does add some extra steps though. I wish sites would give customers the option to reuse a persistent address.

If we are seriously considering putting this in the client, are there concrete plans to use this? Is someone committed to investing in making and selling scratchoff cards? Or is this patch useful for some other case that doesn't require such specialized equipment?

The great majority of companies pay dividends, and that is what gives the stock its value.

New tech companies often don't pay dividends, but (believe it or not) their stock value comes from the expectation that they will pay dividends someday.

The buy-low-sell-high game only works when the market is trading in a narrow range. But you can't expect it to stay that way forever.

Specifically, what are you proposing? What nVersion value should they check, what should they check it against, and what should they do if the check fails/succeeds?

Messages do not have version numbers. Nodes exchange their client versions on connection, but that value increments with every release. There's no way to know if packets from a more-recent client peer have changed to be incompatible with this version.

Here is some of the code that handles the "version" message:

pfrom->nVersion is the peer version. This sends the "verack" message, checking if the peer is newer than version 209 for backwards compatibility. It sets the outgoing serialization version (vSend) to the older of the peer and this node, but only does it for incoming (vRecv) for peers older than 209. Otherwise the incoming deserialization version is left at this node; don't know why the difference.

This design puts the responsibility on the newer node to send/receive backwards compatible messages.

You laugh, but I predict that fractional reserve Bitcoin banks will exist. They'll make loans and pay interest, just as banks have done for centuries.

At least is believable, unlike the ludicrous claim that they'd limit transactions to $100. That one was a transparent bluff.

Kiba you're always looking for ways to earn btc, you should sell your user name. Bet you could get 100 btc for it.

Nice job! Sent 25 btc as thanks to 17eSZivDJpuJp9TxezTXVxkgLbsr3XZM1i.

A txn "in limbo" (in the transaction pool) will block double spends from being forwarded by peers, or accepted by (unhacked) miners. The pool is only in memory so gets wiped when the node is restarted, making network behavior somewhat nondeterministic. The wallet currently retransmits unconfirmed txns indefinitely, however the peers will not forward them unless/until the txns are cleared from peer memory due to a restart.

There's other stuff in wallets, including preferences, address book entries for payees, and account information. bitkeys format won't be suitable for wallet backup if it loses all this.

Here is the government press release on the Liberty Dollar case:

http://charlotte.fbi.gov/dojpressrel/pressrel11/ce031811.htm


I worry that Bitcoin can be seen as even more of a threat to the supremacy of the dollar, which by this reasoning would make it terrorism. An extreme claim, to be sure, but apparently the U.S. Is willing to go there.

The government also advances this theory:


Now this is really stretching the truth. Until the Civil War era, there was no U.S. currency as such, rather paper money was issued, perfectly legally, by private banks. There is no Constitutional prohibition of private currency. There is a law that prohibits private metallic coins, 18 USC 486, which is what they used against LD. It's ominous to see the U.S. expanding its claims like this, to the point where they would cover Bitcoin.

The modification to repeatedly hash the 64 bit password is a good idea, and should prevent square root attacks. I would probably have used a simpler iterative formula, but that one seems safe enough. SHA512 is notorious for speed variations on different architectures, but compared to the time to type in the password, that should be ok. Where does the magic number 108333 come from?