I spoke with the author last week; I think she did a great job explaining bitcoin for a not-super-technical audience and does a great job being realistic about the hurdles bitcoin faces:

 https://www.eff.org/deeplinks/2011/01/bitcoin-step-toward-censorship-resistant

First: I am not a lawyer.

Second:  No.  http://criminal-law.freeadvice.com/drug_crimes/unwitting_possession.htm

I think you should begin by defining the threat model.

Can the attacker see all unencrypted IP traffic to/from the sender's node, or is the traffic tunneled through an anonymizing network like i2p or tor?

Does the attacker know any of the sender's receiving bitcoin addresses?  Is the attacker willing and/or able to send 'marked bitcoins' to the sender?  Lots of them?

Run one instance normally.  It'll listen for incoming bitcoin network connections on port 8333, rpc connections on port 8332, and connect to other nodes.

Run the other instance with a different -datadir, and a bitcoin.conf like this:
nolisten=1
rpcport=7332  (or whatever you like)
noirc=1
connect=127.0.0.1:8333

You'll need to be running the latest source code from github for the nolisten option.

The noirc and connect settings aren't strictly necessary; leave them out and the second instance will make 8 outgoing connections to other bitcoin nodes.  You'll save a little network bandwidth if the nolisten instance only connects to the other node.

Having spent a lot of time working with the existing code, I don't think splitting the code into multiple files would make it much easier to work with.  The hard part is figuring out how everything fits together (for example "if I have a CWalletTx, how do I get the CBlock that it is in (if any)?").  Just rearranging the code that is there now won't make that problem any better.


I don't think anybody who has worked on the code, except for Satoshi, has a lot of bitcoins.  I certainly don't.  I hope to earn some with Clearcoin....


The listaccounts bug is nearly fixed.  I cannot reproduce the dangerous-looking bug, even running bitcoind under the valgrind memory-checking tool (valgrind actually simulates machine instructions to catch memory access errors)-- tcatm seems to be the only person having the issue.

Satoshi is busy.  Doing what, I have no idea-- maybe he's working on a GPL-version of bitcoin, but I doubt it.

In any case, I wouldn't expect any opinion on GPL versus MIT from him.

My opinion:  I've got better things to do than worry about which open source license is most appropriate.  No software license has magical powers that will prevent 'bad guys' from trying to do bad things.

I paid for the download; nice little paper.  And interesting choice of pseudonym.

Are you submitting it somewhere to get it peer reviewed?

And do you mind me asking what you mean by "I'm a computer scientist with some knowledge in cryptography" -- are you a professor, grad student, postdoc, graduated-with-a-degree-in-computer-science-and-now-working-in-industry ?

I don't think we have consensus that CORS in bitcoin is a good idea, so I'm not going to pull this now.

tcatm's little proxy server is a good workaround.

ribuck: The Faucet is currently giving out between 5 and 6 BTC per day (100-200 payouts per day).

BioMike: Are you creating an AdWords-like service, but bidding/paying in Bitcoin?  One reason I like AdsCaptcha is because if won't clutter up the Faucet page with ads.

[mike]: Thanks for the pointers RE: how much it costs to get google/yahoo/etc accounts; I have been tempted to give out more coins from the Faucet to people with Google accounts.


I'm going to give AdsCaptcha a try; if the ads are annoying or offensive or inappropriate or doesn't work with ad blockers I'll switch back to reCaptcha.

I'm thinking of replacing the Bitcoin Faucet's reCAPTCHA with an AdsCaptcha -- instead of solving a CAPTCHA to help scan books, people visiting the site would be shown advertising which would help refill the Faucet with bitcoins.

My goal isn't to make money from freebitcoins.appspot.com, my goal is to make it sustainable without relying on donations.  According to the AdsCaptcha folks, they expect advertisers pay anywhere from 1 to 20 US cents per CAPTCHA solution, depending on web traffic, how well the website fits their product, etc.  The Faucet is currently giving out 0.05 bitcoins per visitor, which is 2 cents at current prices.

I would also like to gradually relax some of the anti-cheating measures I have in place that occasionally make it frustrating for non-cheating new users who "look like" people who are constantly re-visiting the Faucet (using proxies and new bitcoin addresses) to try to get more than their fair share.

One danger is that I implement AdsCaptcha, donations to the faucet stop, I find the revenue from AdsCaptcha is less than 0.01 BTC per visitor so that whole thing is even less sustainable than the current "somebody steps up and donates more when the balance gets low enough" model.

What do you all think?

As the owner of the Faucet, and having seen how far some people will go to get more than their fair share of bit-pennies from the Faucet, I've thought about this subject.

My conclusion is that instead of creating tools to try to become "the Bitcoin Police", there are probably better things you can do with your time.  Because as soon as you create the tools, the bad guys will find ways to work around them.

Adjusting the testnet difficulty every, oh, say 100 blocks (instead of 2016) seems like a good idea to me.

That's a trivial patch; I nominate ArtForz and Xelister to write it and submit a pull request.

Locking in the testnet block chain-- not so much.  I don't think it is worth the effort to either come up with a mechanism for distributing the lock-in points or manually put lock-in points in the source code.

There's one tricky accounts-related bug that I think needs to get fixed before the next release:
   https://github.com/bitcoin/bitcoin/issues#issue/25

The only other possibly critical bug is:
  https://github.com/bitcoin/bitcoin/issues/#issue/28

... although I haven't been able to reproduce it, even running bitcoind on top of the 'valgrind' memory checker.

I plan to pull patches into the integration git branch early next week, and I'll ask for help testing the result.

Improving help is definitely helping-- thanks!

And it would be fantastic to get somebody who knows, or is willing to learn, git to step up and volunteer to submit translation file patches.

I'll soon be asking for building and testing help, too (after fixing another couple of bugs, I think it'll be time to pull non-controversial patches into the integration tree and start some serious testing to prepare for another release).

The list of possible new features and bugs at https://github.com/bitcoin/bitcoin/issues is getting longer every day; I'd like to see the bugs resolved before the bug list gets so long we all just start ignoring it.

So:  who is willing and able to help out?  Don't ask permission, just jump in, grab a bug that catches your interest, add comments to it as you start to figure out what the problem is (or isn't), and submit a PULL request when you have a fix.

Your reward will be recognition, admiration and respect.  It is time to take bitcoin from, essentially, a single-programmer project to a robust open source project with lots of contributors.

That is wxWidgets' internationalization machinery complaining about... something (the catalog is probably the list of english strings -> other language strings).

As for fixing it:  "Not It!"   (I don't know nothing about wxWidgets internationalizations stuff)

Should we start a betting pool to see how long it takes Google to decide bitcoin mining should be against its terms of service?

I think.... three months.

RE: point you in the right direction:

File rpc.cpp, the CommandLineRPC method:

I suspect what needs to be done is to properly JSON encode any strings passed via the command line.

And then properly decode/recode any strings returned from the JSON RCP call before printing out the result.

CORS support doesn't change this.

IF the browser has a bug that lets JavaScript code read the local filesystem, THEN JavaScript code can get your rpc username/password from your bitcoin.conf file.

And IF the JavaScript code can do that, then it can send rpc commands to bitcoind running on localhost (because, surprisingly, the same-origin policy does NOT apply to localhost: urls-- we learned that lesson here six months or so ago).

That is all true right now, with the released bitcoin/bitcoind.

Character set issues give me headaches.

So I just ran a test at the command-line, moving 500 testnet bitcoins to an account named "฿"

The account created is named "\u00E0\u00B8\u00BF", which is not what I intended.  E0 B8 BF is the utf-8 representation of the unicode Thai Baht character.

Thinking this through, trying hard not to get a headache...

My terminal window has:  LC_CTYPE=en_US.UTF-8
So when I copy&paste the Thai baht symbol, it is being encoded as UTF-8.

I pass a UTF-8 string to bitcoind, and it uses the JSON-Spirit library to convert it into a JSON string (which is defined to be Unicode... encoded using backslashes, I think: see http://www.ietf.org/rfc/rfc4627.txt ).  And there's the bug.  Maybe.  I think?

Command-line bitcoind should be looking at the locale and converting JSON strings to/from that locale.  Anybody motivated enough about internationalized account names (and send comments) to teach it to do that?