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

Pulled into git integration repository.

Pulled into the git integration repository.

OK.  Lets talk here.

Done.  Please feel free to make it better.


Good idea.

Mirroring all of the information that bitcoin keeps about transactions inside your bitcoin-oriented web app is probably not the right way to go.

It violates the zero/one/infinity principle, and you're likely to have subtle bugs if (when?) the two copies get out of sync.

See:  http://www.bitcoin.org/wiki/doku.php?id=accounts   for "best practices".  If you're willing to share what kind of thing your web app is doing, I'd be happy to brainstorm other approches, too...