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....

https://github.com/bitcoin/bitcoin/pull/23

Cross Origin Resource Sharing lets servers support cross-origin Javascript. It is supported by the latest browsers (although IE support is... different), and involves sending CORS headers in responses.

Adding this enables Javascript code running in a browser to connect with any bitcoin/bitcoind that allows RPC connections from the browser's IP address and has the right rpc username/password.

Code changes are minimal (4 lines of code to output CORS headers).  Thanks to tcatm for implementing and testing.

https://github.com/bitcoin/bitcoin/pull/24
This adds a new field to the output of gettransaction <txid> :  "details"

It is an array of objects containing account/address/category/amount (and maybe fee).  For most transactions to or from your wallet, it will contain just one object, but for sends from one account to another it will contain multiple objects.

Example output:


I'm not sure "details" is the right name for this information; if you have a better suggestion, speak up.

Great!  I'd like to see this good work make it back into mainline bitcoin; please talk with the other improve-the-build-process efforts and submit some patches.

Great!  I'd like to see this good work make it back into mainline bitcoin; please talk with the other improve-the-build-process efforts and submit some patches.

Great!  I'd like to see this good work make it back into mainline bitcoin; please talk with the other improve-the-build-process efforts and submit some patches.

Great!  I'd like to see this good work make it back into mainline bitcoin; please talk with the other improve-the-build-process efforts and submit some patches.

The smartcard-generates-a-private-key-itself seems like overkill.  No matter what, you have to trust the smartcard manufacturer.  Because even if the smartcard generates a private key, you have to trust that the smartcard manufacturer didn't:
 + Add a backdoor that lets them read the private key
 + Break the implementation so the private key created is predictable

If you have to trust the smartcard manufacturer anyway, it seems to me a much simpler solution is to just associated a bitcoin address with a tangible bitcoin.

Redeeming the tangible bitcoin then means turning it over to the issuer and having them send the bitcoins to one of your addresses.

It is easy to solve half of the "is this valid" problem-- you can easily check to see if bitcoins have been sent to that address and are still unspent.

The other half of the problem is "is there another unredeemed copy out there?"

Perhaps the issuer could publish a public database of unredeemed tangible bitcoins that is:
  bitcoin address -->  hash of information that the tangible bitcoin purchaser provides

I could then check that database to see if bitcoin address 1abc was sold ONLY to SHA256("Gavin Andresen 1-Jan-2011").  That stops the issuer from selling the same bitcoins over and over again.

I still have to trust that the issuer won't decide to spend all the bitcoins (since they have the private keys) and disappear.  But that's really no different from trusting your smartcard manufacturer.

(interesting thing to think about:  the issuer could actually use just one private key and generate as many public keys as they like that can all be signed using that one private key...)

Good idea.  I vote for the new wiki as the right spot, with the Discussion pages there as the place to bring up issues with the documentation/etc.

I'll put a pointer to the new wiki at the beginning of my bitcointools NOTES.txt.


Do we need a separate forum specifically for network-related stuff?  Seems to me the Development forum here is the right place for those kinds of discussions.

I've been reworking my old 'monitorreceived' patch to catch up with the latest JSON api changes, and I'm looking for feedback.

New methods I've already implemented:

• monitorblocks <url> [monitor=true]: POSTs a JSON-RPC notification to <url> when new blocks are accepted.
• listmonitored : returns list of URLs that are monitoring new blocks
• getblock <depth> : Returns information about block at depth <depth>

getblock/monitorblocks give this information (this is one of the -testnet blocks):

The monitor JSON-RPC notification wraps that information with a call to "monitorblock" -- see http://gavinpostbin.appspot.com/15depef for exactly what a notification looks like.

I'm thinking about adding notification for 0-confirmation wallet transactions, too; something like:

monitortx <url> [monitor=true]  : POST to url when wallet transactions (sends and receives) are accepted.

Information posted would be the same as you get from calling gettransaction, and I'll change listmonitored to return lists of { "category" : block/tx, "url" : url }.

Possible reasons NOT to add this to mainline bitcoin:

1. I'm using boost::xpressive (regular expression library) to parse the urls.  Bitcoin is already dependent on lots of other pieces of Boost, and xpressive is compiled as a header-only dependency (no changes to the Makefiles)... but I wouldn't be surprised if using xpressive causes problems on SOME compiler somewhere.

2. POSTing to https: URLs won't work if you're running on Windows (any windows/mingw experts want to take another crack at getting full openssl working?).

3. Related to https/ssl:  if you POST transactions to a non-ssl url, somebody eavesdropping on your packets will be able to figure out which bitcoin addresses belong to you.  This is a potential privacy issue.

As always, feedback, encouragement, and reality-checks are welcome.

... but Launchpad won't build (run the compiler on one of their machines) Mac/Windows software, or did I miss that feature when I looked at the website?

Done.

CIA...  sounds scary!

I'll make it post to #bitcoin-dev

By the way: I cleaned up the SourceForge project a bit today, adding a pointer to the Technical Support forum here for support and shutting off some unused features.

trapezoid....  are you related to Dr. Gene Ray, Cube Phenomenologist and THE WISEST HUMAN?

In the programming world, I'm a fan of what is called "duck typing" -- if it looks like a duck, walks likes a duck, and quacks like a duck, then it is a duck, even if you give it a fancy name like TrapezoidalFowl or MultiLevelBird.

Very nice!  Let me ask some dumb questions:


What does PPA stand for?

Does launchpad help solve the 'trusted build' problem-- e.g. does the build process automatically fetch from source code that we can all look at and audit?

How hard would it be to setup something similar to produce regular builds of the github integration repository?

Right now, the bitcoin build process is "Satoshi does it."  Using Launchpad to create the Linux builds seems like the right way to go.

Last dumb question:  are there services similar to Launchpad for building Mac/Windows software?

You should be honest about what you're doing:
  http://en.wikipedia.org/wiki/Ponzi_scheme