JAP supports paying for Tor-like service (not yet with bitcoins, though):
http://anonymous-proxy-servers.net/

It uses onion routing like Tor, but you have to pay to use certain relays. All relays are contractually obligated not to attack your anonymity, so you also have more protection against certain "evil node" attacks.

Even the free "mixes" are often much faster than Tor.

A very large site would probably want use getblock, anyway, since it allows you to talk to Bitcoin only once per block instead of querying it every time you want to do anything.

It is a mistake in English, which the OP is using. No English style guide advocates putting a space before a question mark, and it is never done in English literature. Clearly it would not be a mistake in French.

I notice that the OP put a space before a question mark, which is a common French mistake. Maybe davux is thinking of something else, though.

ECDSA public keys are derived from the private keys using a formula. So including the public key is redundant.

Good idea. This will work. The client can also keep a stack of block hashes if desired to reduce work in case of a reorg (which happens more often than you might think).

It won't work for 0-confirmation transactions, of course.

Bitcoin Block Explorer does something similar: it uses the current block number for ETag/If-None-Match caching on certain pages.

No, they're not. And if they were, the timestamp would be provided by the attacker...

Bitcointools has the ability to analyze your addr.dat, which should contain nearly every node in the network if your client has been running for a while.

I originally made mine for an RPG character: Theymos Amastica. It was created without much thought, being only a minor adjustment of the "Thamior" and "Amastacia" names given as elven name examples in the D&D 3.5 Player's Handbook. I began using it for all of my online game accounts, as well, and then I used it even for non-game accounts so I wouldn't have to remember multiple usernames. (At this point most of my online accounts were game-related.)

I sometimes wish that I had chosen something better and more meaningful, though it is nicely unique: almost all Google results for "theymos" are related to me. It would be very difficult to change at this point, after using it for 5+ years.

No. You connect to an IRC channel to get a list of all active Bitcoin peers. Then you choose 8 at random (basically). You will also be listed on that channel, though peers won't be able to connect to you from the outside.

I recommend running the miners with -connect=<IP of networked bitcoind>. This connects only to the specified IP, and it prevents you from being listed on IRC. Then you are well-connected, but you avoid wasting network resources.

Not being well-connected is only a minor disadvantage. You can replicate some of the advantage by running the miners with -maxconnections=20, which will increase the number of outgoing connections to the specified amount. You might also do -maxconnections=4 and -noirc to decrease the number and stay off IRC (you'll bootstrap from your network node), and then use addnode to connect to your networked bitcoind: this decreases network load without relying completely on your networked computer.

(Edit: I just discovered that maxconnections can't increase the number of connections from 8, as I always assumed.)

You can often speed up transaction processing by including a 0.01 BTC fee.


I wouldn't say that. Consider that ArtForz or slush could easily reverse a transaction with even 2 confirmations (maybe more).


Processing would become much slower. However, transaction fees would accumulate, constantly increasing the generation incentive. Eventually someone would want to generate.

It would require creating a new transaction, which might have to have its own fees, which might have to have its own change transactions, etc. The refunded amount would also be at risk of changing in a reorganize, which would invalidate all future transactions based on that one.

The way you're doing transactions is not secure. Anyone can monitor the public address and then automatically email you when they see a transaction to it. The real purchaser will have a hard time proving that they were the one who actually sent the coins. You must generate a unique address for each customer. I recommend just using MyBitcoin's merchant API to do the transaction processing.

Bitcoin transactions are not encrypted, and it's likely that all transactions will require a small fee within a year or two.


Nickwit asked for feedback on his explanatory Bitcoin page. Kiba is responding to inaccuracies he perceives in the text.

I think he's saying that minimum wage laws make finding employment more difficult, since labor is more expensive than it should be.

Possibly the "modem" supplied by your ISP also acts as a NAT device that requires its own port forwarding rules. Maybe your ISP blocks all incoming connections, or has you NATed with several other users. You should contact your ISP's support.

You can, but it allows the sender to double-spend, so you wouldn't want to accept the transaction until it appears in the block chain. That's not a big deal in this case, though.

The email would also need to be encrypted.

The Linux/Unix "default" behavior is to use crypt() to DES-encrypt a truncated password as you described. Probably almost all Linux distros modify this behavior to something more secure, though.

Connect to the #bitcoin-otc IRC channel on Freenode. Here is a webchat page:
http://webchat.freenode.net/

Then just state the trade you want to make and wait for someone to respond. A 1:1 LRUSD->Paypal trade will be attractive, I think.

Here are the abbreviations:
http://wiki.bitcoin-otc.com/wiki/List_of_common_currency_abbreviations

It shouldn't be a problem if they truly do no transactions, though. (Generating 50 BTC for themselves would be a transaction.)

POST is also easily-readable plaintext... GET is just visible in the URL. GET parameters are encrypted when using HTTPS.