I should have been clear:  this is a patch against the latest 'vanilla' svn.

I just updated the code/patch:
   monitoraddress allwallet <url>
... gets triggered for all transactions that go into your wallet.  That includes 'change' transactions that can occur when you send somebody coins, which I expect will strike some people as a bug and others as an important feature.

And I combined the getblockby methods into one.  I know I would've never remembered  "is it getblockybycount or getblockbynumber or getblockbyheight or getblockbydepth" -- I will remember "getblock".

Good Idea, and that aught to be easy.

I'm thinking it should be:
  monitoraddress allwallet <url>
... instead of a separate monitor command.

Come to think of it, maybe I should combine the getblockby* routines into one; there's no chance of mistaking a 64-character hex block hash for a 5-digit (or, in many years, a six or seven or ten digit) block number.

This patch adds the following JSON-RPC commands to bitcoin/bitcoind:

• monitoraddress <bitcoinaddress> <url> [monitor=true]
  When coins are sent to <bitcoinaddress> POST JSON transaction info to <url>.
  If <bitcoinaddress> is 'allwallet' then monitor coins sent to all of your addresses.
  Pass false as third param to stop monitoring.
• monitorblocks <url> [monitor=true] [startblockcount=0]
  POST block information to <url> as blocks are added to the block chain.
  [monitor] true will start monitoring, false will stop.
  Pass [startblockcount] to start monitoring at/after block with given blockcount.
• listmonitored
  Returns list describing where blocks and transactions are being POSTed.
• getblock <hash|number>
  Returns details of the block with <hash> (hexadecimal) or <number>.
• gettransaction <hash>
  Returns details of transaction with <hash> (hexadecimal).

This patch also modifies the "sendtoaddress" function so it returns the transaction ID on a successful send (instead of the string "sent").

If you use the monitor* functionality to POST information be sure to think through the security of your application.  For example, if you use monitoraddress to get notified of customer payments you should think about whether or not a customer could fake a payment by POSTing bogus information to your web server.

Full source code is at: http://github.com/gavinandresen/bitcoin-git/tree/monitorreceived
As always, bug reports, suggestions for improvement and feedback is welcome.

---

Updated monitoraddress/getblock commands as discussed below

blkindex.dat contains all the transactions, in records that look like:
  key:  "tx" + HASH_OF_TRANSACTION
  value: serialized CTxIndex

The CTxIndex points to a record in one of the blk000n.dat files.

That does bring up an interesting point, though:  if lightweight clients are implemented, they wouldn't be able to support an arbitrary 'gettransaction'.

I've been working on a "monitoraddress" / "monitorblocks" patch, so bitcoind will POST transaction/block information to an arbitrary URL.

And it seems to me "getblock" should be split into "getblockbycount", "getblockbyhash" and "gettransaction".  I also have some suggestions for making the naming more consistent:

I'd suggest getblockby* return:

Reasoning:
  blockcount instead of 'height' or 'depth' because getinfo returns "blockcount"
  getblockbyhash might return a block not on the "best" chain; return blockcount=-1 in that case?
  version instead of 'ver' because abbrvs shd b avoided (thy cn b hrd to rd/rmbr)
  only return transaction hashes; if you need more transaction details, call gettransaction.
  No n_tx (or n_anything) because it is implicit in length of returned array

(stuff I'm not sure about:  what is 'bits' in the implemented getblock?  Is that difficulty?  Does anybody really need all the detailed merkle tree info?)

I'd suggest gettransaction return:

Reasoning:
  Returning the CScript string seems like it is both too much detail AND not very useful (I want the bitcoin addresses, NOT OP_DUP 0xblahblahblah ...)
  "from" is just a list of pointers to previous transaction "to"s
  confirmations is duplicate info (you could getblockbyhash and then look at its blockcount), but is so useful I think it belongs here.

Separate "accounts" (addresses with labels) to accumulate Jackpots is the right idea.  Users buy tickets, bitcoins are moved to the appropriate Jackpot account.  When a Jackpot is won, transactions flow out of its account back to whoever won.

The "label" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.

If the API was extended as I describe below, would it solve the same problems as having multiple wallets?

Proposal:

+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>
  (change generated would be automatically tagged with <label>)
+ add optional [label] param to getbalance.
+ new method: listsentbylabel
  (returns array of [ "address" : "bcaddresssentto", "amount" : x.yz, "confirmations": n ])

Each customer "account" would be a bitcoin <label>.  Account handling would look like:

Create account / create new address for account:
  getnewaddress [account_id_label]
   ... tell user "fund your account by sending coins to {the address returned}"

Customer withdraws/spends:
  sendfrom [account_id_label] [address] [amount]
   (FAILS if balance for that account too low)

Show customer their balance:
  getbalance [account_id_label]

Show customer their transactions in/out
  listreceivedbylabel [account_id_label]
  listsentbylabel [account_id_label]

---------

Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer.  At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.

An irresponsible central bank.

I think that scenario is unlikely for dollars, because the Federal Reserve central bankers already have a lot of dollar-denominated wealth, so have a strong incentive to avoid hyperinflation.

Compare that to the Zimbabwe central banker, who is basically under the thumb of a dictator who most likely holds his wealth in foreign currencies.  Their incentive is to squeeze as much wealth out of the economy before it collapses and they're deposed in the next coup.

For extra credit, give an Object as the return value:

{
  'isvalid' : true,
  'ismine' : true,  # true if isvalid and you have the private key (can spend coins sent to this address)
  'version' : 0,  # ADDRESSVERSION
  'address' : '1frt6531....'    # might as well echo back the address...
}

With just a web browser you can open an account at bitcoinmarket, mybitcoin, or mtgox and send/receive bitcoins.

The only thing you're not able to do is try to generate bitcoins, but you said you don't have a computer at home and it sounds like your employer wouldn't be very... uhh, supportive... of you using their electricity to try to generate bitcoins.

If they would be supportive (long ago I wrote software at a hardware company where they actually LOOKED FOR CPU-intensive applications to run during system burn-in, so they'd ship fewer dead-shortly-after-arrival units) then they'd probably be happy to open up outbound connections to port 8333.

"Mainstream" users want a more-selection, less expensive, just as fast variant of iTunes.  Frankly, I don't think an illegal filesharing site can scratch that itch and stay in business for long (I'm curious to see how long mulve.com lasts).

If it could, I think a bitcoin-revenue-sharing business model would work well-- "We'll give you 50% of the revenue from any downloads of stuff you upload"  (and "we" charge x-bitcoins-per-download).

But I think even if such a service existed there would still be a bunch of people who refuse to pay a bit-penny for downloads.  But I agree with lfm-- I think many of them would be willing to pay indirectly for downloads; you just have to tell them that they're paying for "X gigbytes of premium bandwidth" or something...

I think a big publicity splash should wait until Bitcoin 1.0.  Bitcoin still has way too many rough edges for ordinary folk to use (watch them run away screaming as you try to explain that it is NORMAL for it to take half an hour to download the block chain the first time you start Bitcoin....).

I believe that the statement: "bitcoin is new kind of money" passes the duck test.

Bitcoins function as money (they're a unit of account, a medium of exchange, and a store of value), and if PayPal started allowing Bitcoin transactions tomorrow I'm certain they'd treat them as Just Another Currency.

If you like, call it a commodity, but I think all you'll accomplish is confusing potential users who might think they'll end up getting pork-bellies delivered to their porch if they don't get rid of their bitcoins.

I shoulda been more clear:  I've now got a 1.11 payment to {some random address} in Bitcoin; I want to take that {some random address} and give it to MyBitcoin (or you, the merchant) and see what's up with that payment.  Ideally, it would pick up the payment process as if the PAYMENT TIMED OUT never happened.

And MadHatter:  keep the change.

Hmm...  I guess I was too slow:
  "PAYMENT TIMED OUT! We didn't receive a payment from you. Try again."

I copied the generated BTC address, but forgot the amount by the time Bitcoin launched, so sent you 1.11 (eleven is my favorite number) bitcoins.

Now I didn't get whatever it was I paid for.

Definitely cool, but also definitely clunky.  Where this needs to go, in my humble opinion:

1. MyBitcoin should get rid of the CAPTCHA for most users (do the Google thing, and only show the CAPTCHA if it detects potential abuse)  (oh, you didn't know Google search does that?  Yup, they do, if you do enough weird-looking searches quickly enough you'll get a CAPTCHA...)

2. Bitcoin needs a 'refundtransaction' feature, to get rid of the scary "Do not ever reuse a temporary payment address or your Bitcoins may get lost" warning.  Sending to an old address should just do an immediate refund.

3. I want to be able to put the payment address into MyBitcoin and see the status of my payment.

4. Gotta get rid of the "memorize the amount and then copy and paste to Bitcoin" (need a bitcoin-payment-request MIME type, in my humble opinion).

5. Gotta improve Bitcoin startup speed; at the very least, make the UI come up quickly while it re-verifies the block chain (I think that's what it is doing...).

No, both IP and port are encoded in the #bitcoin IRC usernames (see the EncodeAddress/DecodeAddress routines in irc.cpp).

(so mizerydearia:  no need to do what you done did...)

RE: hippich XML/JSON:
XML ain't gonna happen, and I think JSON is overkill for this.  Using the same format as the bitcoin.conf file is the right answer, I think (easy to implement, human-readable, comments allowed in the file, easy to extend as necessary).  That's what I mocked up at skypaint.com.

RE: nimnul http://localhost:.../
If you've never installed bitcoin, or bitcoin isn't running already, you get an unhelpful error message.  One advantage of a "payment request file" is many users will understand that you need something called "Bitcoin" to open a "Bitcoin Payment Request" file.

RE: mizerydearia Linux support:
In my research I briefly an across a reference to a KDE startup file to associate mime types with applications, so I think it would work nicely cross-platform if you've already installed bitcoin. (UPDATE: cross-desktop spec here)

RE: nimnul clipboard monitoring:
Seems to me that's a feature for geeks, because only geeks would happen to know that if you highlight a bitcoin address when bitcoin was running you could automatically launch bitcoin.  And there's no way that would be turned on by default.  And it also seems to me clipboard monitoring is perfect for a standalone, general-purpose utility ("if selection matches any of THESE regepxs, launch THAT applications with arguments "beginpayment %{address} %{amount}" ... ).

RE: mizerydearia portable devices:
I've never programmed for Android or iPhone; anybody know how they handle non-standard MIME types?  Can apps register themselves as content handlers?



Thinking about actually implementing this, the hard part is getting a running (or just launched) Bitcoin's attention in a cross-platform way.  Using the existing command-line control (which uses JSON-RPC under the covers) would be the most straightforward, but that requires that you set a rpcuser/rpcpassword in the bitcoin.conf file AND run bitcoind or bitcoin -server.  Yuck.

I suppose, as a special case, payment request JSON-RPC calls could be allowed with no rpcpassword, and -server could be made the default.  Makes me a little nervous, though.

Running  bitcoin /path/to/browser/cache/with/payment_request_file  (which is what the web browsers will do) should:
 IF bitcoin isn't running:  launch it, and wait until it is ready to receive payment request messages
 Send running bitcoin (...somehow...) "Hey, we got a payment request here for you to deal with" messgae.

bitcointools can tell you all transactions to a particular bitcoin address:


Feed that to a little script that just looks for value: (something) pubkey: 1HZNsUq  and totals up the (somethings) and you can figure it out.

I agree with nelisky-- not a bug.  Here's what the unix cat command has to say about "":