[Announce] bitcoinmonitor.net - Free professional notification/payment service

[Herbert]

bitcoinmonitor.net will shutdown.

I hope to have it running 2-3 more days, but circumstances are out my control. So right now there is nothing I can do about it, and it seems unlikely that it will be back up soon.


Original post from 2012-02-16:

Ever since the ugly end of bitcoinnotify.com last december I was thinking about implementing a better notification service myself, including a secure, easy-to-use payment service. This idea kept bugging me, so over Christmas holidays i started working on it. Now, after many hours spent thinking, coding, learning and testing I think it's time for a public announcement!

http://www.bitcoinmonitor.net

Of course I know there are other services already existing, but it seems many of them offer notifications as a kind of add-on to other stuff, not really focusing on providing a decent user experience. And in general it never hurts to have a choice - especially for the area of providing payment services I consider it absolutely necessary to have multiple choices which could even be used in parallel for added security/reliability.

Important: The notification service will stay free for everybody. Of course i need to think about covering the costs for server and traffic, but this will not be done by charging the average user. One idea which might have potential is embedding advertisement into the notifications, or offering complete payment integration modules for the well-known shop systems - but this is not decided yet.

Major goals I had in mind when working on this site:

• Usability:
  To make it easy also for non-techies to understand how the site works I introduced the concept of agents. Of course usability is a subjective matter, so if you have any improvement suggestions let me know.
• Control:
  Full notification history - You can track each and every single notification in your dashboard, including status e.g. on the response of http callback. API access is quite high on my TODO-list, which will make it possible to setup and manage your agents via json-based http API. Also a retry-strategy for failed notifications is clearly defined.
• Speed:
  The main point in providing payment notifications is to have them as fast as possible. So the whole architecure is event-driven - no polling anywhere.
• Stability:
  Use existing, rock-stable frameworks and tools whenever possible. This means: Mysql and django for the core, celery and rabbitmq for task handling, YAML css framework for the layout. Especially bitcoinmonitor.net does NOT require any additional tool/database/whatever to interact with the bitcoin network. It is just a stock bitcoind with small patches applied to trigger on new unconfirmed transactions/blocks and allow retrieving of arbitraty transaction information.
• Scalability:
  Direct benefit of using existing technology versus NIH-syndrome is scalability. If necessary each component can be moved to it's own hardware, made redundant or be load-balanced.

This is the initial public launch (well, few days ago I posted it on G+ ;-), so the site is still considered in betaphase and is not yet finished.
The layout and design is really just the default YAML template and definitely needs some beautification and improvements. The list of right now available notifications is rather short. Content and texts are probably rather clumsy. API access is only half-way done and not yet available to the public.

tl;dr:
Please checkout http://www.bitcoinmonitor.net and let me know what you think!

[1713282986]

1713282986

[1713282986]

1713282986

[1713282986]

1713282986

[kiba]

This sound good! Is there any source code example I can see on how to use this service?

[Herbert]

This sound good! Is there any source code example I can see on how to use this service?

Good point - I will add some usage examples to the support section soon.

[Herbert]

Documentation for using the http callback feature added:
http://www.bitcoinmonitor.net/help/

[kiba]

Documentation for using the http callback feature added:
http://www.bitcoinmonitor.net/help/

Awesome!

[mcorlett]

Friendly note: PHP's support for grabbing the raw POST data is spotty - I solved it with:

file_get_contents('php://input')

You can manipulate the object however you'd like from there.

[mcorlett]

How many addresses can you handle?

[Herbert]

How many addresses can you handle?

Currently i have a limit of 800 characters for Address input for each agent, which should be enough for 20 Addresses. But this is just an arbitrary limit, if there is demand i can increase it.

[kiba]

Is this site open source? What's it written in?

[mcorlett]

Is this site open source? What's it written in?

The POST requests are coming from Python 2.6 via urllib.

[Herbert]

Is this site open source? What's it written in?

The site itself is not opensource and written using django as the main web framework. I forked bitcoind to implement some custom rpc-commands, this fork is of course publicly available at github: https://github.com/TripleSpeeder/bitcoin.

[kiba]

Is this site open source? What's it written in?

The site itself is not opensource and written using django as the main web framework. I forked bitcoind to implement some custom rpc-commands, this fork is of course publicly available at github: https://github.com/TripleSpeeder/bitcoin.

So services that are dependent on your site will be doomed if your site goes down or goes out of business. I think it's a cool service to use though.

[Herbert]

The site itself is not opensource and written using django as the main web framework. I forked bitcoind to implement some custom rpc-commands, this fork is of course publicly available at github: https://github.com/TripleSpeeder/bitcoin.

So services that are dependent on your site will be doomed if your site goes down or goes out of business. I think it's a cool service to use though.

Probably yes - one of the reasons I started work on this site was actually the sudden disappearance of bitcoinnotify which I used for txt4coins.net :-) But i do hope that eventually there will be multiple services like bitcoinmonitor.net available (afaik there is at least one similar open-source implementation available at bitping.net), so as a shop owner i can subscribe at multiple services to not depend on one single service.

Also there is no final decision about going open-source with the full site. Overall I am a big supporter of open source and use it everywhere possible. But at the moment this site really is my baby so it would be hard to "give it away" :-)
But If I ever have to decide to take the site down for any reason it is more than likely that I will at least make the whole thing open source before i leave. That's only fair for all users.

[stcupp]

Just wondering are you using the bitcoind patch I made for MORA?

[Herbert]

Just wondering are you using the bitcoind patch I made for MORA?

No, extending bitcoind was one of the first things I started. Should be around 2 months ago (here is one of the first commits: https://github.com/TripleSpeeder/bitcoin/commit/1a6f1ae144568ac4086e64d649c4595c09393564). The callback implementation is based on a quite old branch by Gavin he posted long time ago somewhere here... Otherwise i definitely would have given you the credits :-)

[mcorlett]

Where are you hiding your donation address?!

[Herbert]

Where are you hiding your donation address?!

Okay, you asked for it
Donations for supporting bitcoinmonitor.net are welcome at 12AxBpvmqzYbSHmvZML6Xv9TPncJgdnikm 

[kiba]

Hmm. It looks like I am going to have to experiment with it to totally understand what the heck I am seeing.

[Herbert]

Hmm. It looks like I am going to have to experiment with it to totally understand what the heck I am seeing.

Let me know if you need any assistance. Any hint to improve support section is also welcome :-)

[MORA]

Good to see another alternative to the old notify service

It would be neat if we all could agree on a subset of POST data, that we all send, so that the same code could be used with any notify service, afaik theres 4 to pick from now.

That does not prevent each software from adding extra data, just as long as the basic data is what is used for signature verification.

That would also mean any shop modules could easily be adapted for each site.