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?

davout said (at the github pull request):


If you've opened up access to the rpcport, then I don't think CORS support adds any significant vulnerability to password brute-forcing.  I suppose it means a 10-year-old non-programmer can repeatedly enter a username and password into a website to try to brute-force your rpcpassword... but anybody capable of writing or running a script could just write a brute-forcer that doesn't run in a browser.

And, come to think of it, turning on CORS explicitly wouldn't stop the ten-year-old, either: they could just repeatedly browse to URL  http://your-bitcoind-machine:8332/ and try different usernames/passwords.

Also, bitcoind already has anti-brute-forcing code.

The only security vulnerability I could imagine with CORS is that it might encourage people to add:
  rpcallowip=*
... to their bitcoin.conf, so they can connect to bitcoin from any IP address.  And I worry that they might not bother to setup SSL, in which case their rpc username/password will be sent across the net in the clear.

I wrote a blog post about peak oil a couple of years ago:
 http://gavinthink.blogspot.com/2008/04/peak-oil-more-like-speed-bump-really.html

I still believe my conclusion:  we'll be fine.  We'll use less oil and more of something else.  After all we survived Peak Whale Oil (you know, whale oil, that essential commodity that was so great for high-tech oil lanterns).

"Just turn on Berkeley db encryption and you're done" -- ummm:

First, unless I'm reading the bdb docs wrong, you specify a password at database creation time.  And then can't change it.

So, at the very least, somebody would have to write code that (safely) rewrote wallet.dat when you set or unset or changed the password.

Second, encrypting everything in wallet.dat means you'd have to enter your wallet password as soon as you started bitcoin (because user preference are stored in there right now), when ideally you should only enter the password as you're sending coins.

And third, there are all sorts of usability issues with passwords.  Users forget their passwords.  They mis-type them.  I wouldn't be terribly surprised if doing the simple thing and just encrypting the whole wallet with one password resulted in more lost bitcoins due to forgotten passwords than wallets stolen by trojans.

I think creating a safe, useful wallet protection feature isn't easy, and there a lot of wrong ways to do it.

The CPU miner code has all sorts of now-mostly-worthless (because GPU mining is so much more energy-efficient than CPU mining) optimizations.  Maybe hardened Linux doesn't like the assembly code or SSE instructions?

I agree with mh-- if there are real compatibility issues or weaknesses, then those would be a good reason to switch curves.

If there aren't, sep256k1 seems plenty good enough for the forseeable future.  I think most programmers (myself included) have a tendency to worry about small-probability "what if" problems that we know how to solve, when we'd be better off thinking about high-probability problems that we don't want to think about because we don't already know how to solve them.

Like multifactor wallet authentication so trojans don't steal users' wallets....