I suggest to have some cache at your side that is initialized with a scan and than subscribes for updating ttansactions.
The stateless calls can consult that cache. I would persist the cache and rescan from the server at startup from the time point it was last persisted. This avoids having inconsistent state with the servrer and gives best performance.

The matchRequest or scanRequest is to scan the block chain. This would be useful if you import a private key or rescan history for a wallet.
You can submit a long list of patterns (addresses) with a single matchRequest, that is more effective, than one by one. The scanRequest is the same but with abloom filter, this would be useful for to scan for an ever larger set of patterns.

The filterRequest is an ongoing subscription to transactions coming in and matching the filter.

Beware that the bloom filter (for scanRequest or filterRequest) is probabilistic so you can get some transactions you do not care, but it reduces the regular transaction feed by magnitudes. The filter also gets updated automatically, so it will e.g. match for transactions spending a transaction that previously matched the filter. You might want to periodically reset the filter on a long standing connection.

The filter is a bitmap in style of a bloom filter at the moment I can only refer to https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/BloomFilter.java
how it is compiled from byte patterns (keys, addresses, outpoints) you want to filter for.

The Java class https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/DefaultAccountManager.java
shows how filter subscription and scanning is used to implement a client side wallet.

I try quick and dirty here:

All messages are STOMP ByteArray where the payload is Protobuf as defined in https://github.com/bitsofproof/supernode/blob/master/api/src/main/protobuf/BCSAPIMessage.proto

Messages go to queues and topics. Queues are read by a single server instance (this does the load balancing) while topics are broadcast to all server and clients listening.

The following broadcast is allowed from clients to servers
/topic/newTransaction - send a new Transaction
/topic/newBlock - send a newly mined block

Synchronous requests from client to server:
Client sends a message to a request queue and sets the reply-to queue of the message to a temporary queue /queue/temp.XXXXX
The server that picks up the request will send reply to that temp queue.

The following synchronous requests are allowed from clients to a server:
/queue/blockRequest - send a Hash message to get a Block message on the reply queue
/queue/headerRequest - send a Hash message to get a Block message on the reply queue, but transactions field is empty
/queue/transactionRequest - send a Hash message to get a Transaction message on the reply queue
/queue/filterRequest - send a FilterRequest message to get a ongoing feed of Transaction messages on the reply queue that match the Bloom filter, this will keep going until you disconnect
/queue/matchRequest - send an ExactMatchRequest to scan the blockchain for transactions matching the filter, where filter is a list of byte vectors. The byte vectors can be addresses, keys or any data in a transaction script. This scans once starting from an optional time point "after" in the message. Resulting transactions will appear on the reply queue.
/queue/scanRequest - works like match request with bloom filter
/queue/ping send a ping msg to server you get back the same. This is to measure latency or to check availability.

Just a few days of patience please. We are in conference mode. Probably I get it written up while in the airport lounge

It is implemented.
Product release is tomorrow.

Bits of Proof already operates several servers at world class data centers in Germany.
Incremental server locations will be aligned with our customer's need and preference.

You can run the server yourself, and we have also hosted offers, as of:

Bits of Proof launches world's first enterprise-ready Bitcoin server

we even have a complementary offer during Bitcoin 2013.

Pricing is not by request, but we offer maintenance and support contracts of several levels and hosted servers, the later will be priced by vCPU allocated.

The hosted solution saves you the effort to set up a server for development and I hope you will find it care free for your production.
We will have shared and dedicated servers and also load balanced server farms depending on your need.

The primary API is the Bus, that speaks STOMP and is transporting Protobuf format messages, so you can connect e.g. with python, ruby or PHP, I am sure you find examples using both STOMP and Protobuf quickly with google for your choice of language.

The rest API  in the bop-explorer is just a demo how easy is to create one. The BCCAPI that powers the Android app is also technically a REST adapter over the Bus.

The clients side Java code using the Bus API adds a layer of abstraction, that can surely be achieved with other languages. I hope that a community around the product will share those that are popular. You are not exposed to java directly if you do not want it. In the hosted case you do not even have to care of compiling and running the server using java.

The weakest point in our offer is the documentation, but this is just temporary as all resources went into development to hit the target for Bitcoin 2013, and we did. Next focus is documentation. I believe the example code you find in our GitHub repos give a head start.

The BOP Enterprise Server supports multi wallet configuration at your side and asynchronous notification of payments to your addresses.

It will be launched in two days in San Jose.

An alternative that can really take the heat of a web service is the BOP Enterprise Bitcoin Server.

You can run several instances of it and send requests to them through a load balancing message bus.
See the example repository https://github.com/bitsofproof/bop-explorer that shows a simple REST API forwarding to the bus.
The server code is in https://github.com/bitsofproof/supernode

Bits of Proof will launch its offer in two days in San Jose, dramatically reducing the pain of integrating with the Bitcoin protocol.

Sure it is. http://bitsofproof.com.

The site is sparse at the moment but be assured, we are working behind the scenes to fill with content soon.

I am in central Europe too, more specifically in Budapest.

Drop me a mail to tamas@bitsofproof.com for personal assistance with the code.

You are talking about my product the BOP Enterprise Bitcoin Server

It is modern implementation of a full node that allows running sever instances accessible through an API in form of a load balancing industry standard message Bus.

Product launch is in three days in San Jose.

See you there. I will share more details here thereafter.

Yes, Bloom filtering is a significant improvement to the core protocol.

In addition to serving SPV clients it is used to optimize the BOP server's communication to lightweight clients connected to its message bus.

The BOP message bus also offers an API to get blocks.

Welcome to the club!

Having a choice of implementations unlocks innovation and will benefit all of us. Good Luck.

I cant wait to reveal you all features of the BOP Enterprise Bitcoin Server (formerly known as the bits of proof supernode)
and related offers of my company at the conference.

Yes, bits of proof is open source and the plan is to remain open source.

My company offers support, custom development, consulting and more ... to be revealed in 5 days in San Jose, 9am the Lightning session room or at the exhibit booth #28.

You might want to take a look of the bop-api-example and bop-bitcoinspinner, bop-explorer projects to see the power of the backend
supporting a command line, an Android app and a web application, in a load balanced enterprise server fashion.

command line
Android
Web

Thanks a lot, Cheers!

Thanks, I amended.


This is definitely part of the plan. Let's leave some surprises to attendees in San Jose. Thanks for your support.

Added examples of how bits of proof can be the backbone of your Bitcoin enterprise:

       - BitcoinSpinner running against any bits of proof node, enabled through a BCCAPI over BCSAPI implementation https://github.com/bitsofproof/bop-bccapi

       - a primitive block explorer REST API, see https://github.com/bitsofproof/bop-explorer.git

Please consider that both examples are demo only. Although the BitcoinSpinner clone you can build from there works on any android mobile, I do not advise or support running it for other than test purposes and do not guarantee the continuous availability of the server backing it.

Credits to Jan https://bitcointalk.org/index.php?topic=53353.0 for creating both the BitcoinSpinner application and the BCCAPI spec that enables the connection of lightweight, server trusting clients.

See You in San Jose, 9am Saturday in the Lightning session room and at the exhibit booth #28, where I will give further insight to bits of proof connectivity and launch a limited product offer to attendees. Conference schedule at: http://www.bitcoin2013.com/topics--schedule.html

The idea is to use this by the mining pool operator, not in the wild.

The pool operator would add value by validating blocks agains multiple implementations and versions before distributing to work on it. This would be a value add for the pool, since reducing chances that work is wasted in a branch orphaned later by majority.

Spotting a problem with code review might be successful, but this is more about expected behavior than
code differences.

In this concrete case we have tests that document expected behavior. Those can be executed against
several implementations. They might miss something you spotted, therefore I suggest you formulate
the case you think exposes different behavior in that JSON notation, then let us review, then give me
a few days to fix and then ...

... you get the glory and the community a new test case that is a piece of the standard for implementations.

Thank you for taking a deep dive into the code and reporting your findings. I am not (yet) convinced that the difference you spotted by reading the code does lead to exploitable different behavior, since there are numerous tests shared between Satoshi and bits of proof targeted exactly at these subtleties. Specifically the tests https://github.com/bitsofproof/supernode/blob/master/server/src/test/resources/script_valid.json
and https://github.com/bitsofproof/supernode/blob/master/server/src/test/resources/script_invalid.json would have very likely caught the difference you claim.

The process you followed by notifying the author with the details in the first place is correct. It would be fair to wait for a confirmation of a vulnerability and its fix before you announce that you found something, just to avoid it sound like FUD-ing an implementation. There are bugs in every software and there must be countless differences between implementations. Bugs have to be fixed but differences have to be carefully evaluated if they really offer a practical exploit.

Your work is valuable to all of us, please continue but be vary not only the network security but the reputation of the implementations that in some respect also support security.