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

[mcorlett]

• a specified time without transaction ("time-based expiration")

This is great for merchants who set deliberate time limits on orders because of fluctuations in exchange rate. You have 5 minutes to send the coins to the address, for example, or the order is canceled.

• a specified amount is received/exceeded ("amount-based expiration")

This is similar to the above in that the merchant is waiting for a set amount of coins before they mark the order as paid for in their system.

What I would really use is a combination, hybrid, if you will, of the above, where I set an amount and expiration time; if the address does not have <amount> in pending (unconfirmed) transactions within <time>, the address is to be deleted. Let me know if this sounds unreasonable.
Edit: You should be able to define whether you'd like notifications on every incoming transaction, or only when the full amount is reached.

• any transaction is received ("one-shot")

I also can't find any good reasons for using this. Perhaps something like a lottery where the tickets are at least as divisible as bitcoins? You send any amount to the address, and get a lottery ticket equivalent to that amount of coins. Send as little as one satoshi, get one ticket.

Edit: Thank you for noticing and following up on this.

[1714010361]

1714010361

[1714010361]

1714010361

[1714010361]

1714010361

[1714010361]

1714010361

[hex]

Any chance for incrising POST retry times ?
Something like at least 24h would be great!

[Herbert]

Any chance for incrising POST retry times ?
Something like at least 24h would be great!

Technically this would be possible. But overall i don't like the idea of storing notifications for such a long time. This whole notification concept is mostly about being quick. IMO it just does not make sense to deliver a notification days after it has happend.

Let's assume the common usecase of notifiying at 0 confirmations (for informing customer) and e.g. 6 confirmations for actually starting delivery of goods.
If the shop system would be offline for several hours there would be two notifications in the queue, each retrying every few minutes. If the shop comes online again it could happen that the notification for 6 confirmations comes in before the confirmation for 0 confirmations. This might not be handled well in the shop system.
On my side each notification is a completely independent event, so i can not define dependencies between different notifications (and i want to keep it that way for maximum modularity/scalability).

If you know your shop was offline for some time you can already now look up all failed notifications in the notification history (reminds me of the missing search/filter options there...).

An additional option would be adding a button to the dashboard to manually retry failed notifications. Maybe this would be a possible compromise?

[hex]

But what is a problem to increse retry time to for example 1 hour and try to deliver it for next 24 hours ? It would reduce a chance of lost money if site is offline.

Also you should make queue for sending so if you can not deliver 0 conf notification you should not try to deliver 6conf one.

[Herbert]

API is now officially available!

There were only minor changes from the stuff i posted above:

• Authentication is now done via an API-key which you can obtain in your dashboard
• Resource URIs are now consistently in singular (e.g. ".../agent/..." instead of .../agents/...")

See the full documentation at http://www.bitcoinmonitor.net/apidoc/!

[mcorlett]

API works wonders - thanks so much! (Just don't change it now without incrementing the API version!)

[Herbert]

API works wonders - thanks so much! (Just don't change it now without incrementing the API version!)

That's good to hear! And of course the API v1 is now stable and will not change anymore. So you are safe to rely on it 

Do you think there is anything lacking in the API? (Besides of the need of improved documentation I think...)

[Herbert]

But what is a problem to increse retry time to for example 1 hour and try to deliver it for next 24 hours ? It would reduce a chance of lost money if site is offline.

Well, I think you are right In the end it is probably better to deliver late notification instead of not at all. I will change the retry policy to retry up to one day, with an increasing time between tries.
Probably it also makes sense to have the maximum retry time a user-defined setting...

Also you should make queue for sending so if you can not deliver 0 conf notification you should not try to deliver 6conf one.

Indeed this would be better. But this will require some refactoring on my side. Might take some more time...

[kiba]

Hello, I have replicated the python example with ruby code.

Code:

require "json"
require "digest/md5"

data = '{"signed_data": {"userdata": "", "amount": 122678000, "confirmations": 2, "amount_btc": "1.22678000", "address": "12r9JzPNnyWs2j1s9KLW5keqBr4kbJjxz6", "created": "2012-04-06 08:56:00.094725", "txhash": "e0c84120068bfefddab051e751f3df963c4ed29e7b13eadac026e6f17f55fb06", "agent": "callback_test"}, "signature": "17403f7757433850382cc6bd94e09827"}'

data = JSON.parse(data)

tx_hash = data["signed_data"]["txhash"]
address = data["signed_data"]["address"]
created = data["signed_data"]["created"]
confirmations = data["signed_data"]["confirmations"]
userdata = data["signed_data"]["userdata"]
amount = data["signed_data"]["amount"]
agent = data["signed_data"]["agent"]
amount_btc = data["signed_data"]["amount_btc"]
signature = data["signature"]

sigstring = address + agent + amount.to_s + amount_btc.to_s + confirmations.to_s + created + userdata + tx_hash + "437050d0d90c72d3d357b84c098bd61ee1751ec9"

my_signature = Digest::MD5.hexdigest(sigstring)

if my_signature == signature
  puts "BEEP"
end

Now, I  am trying to learn how to use your API so that I can do something interesting with it.

[kiba]

After having no idea how to do this thing ever, I finally figured out how to get a watcher created.

[nedbert9]

Thanks for doing this.

[kiba]

What happened when you input an address that is not valid? Is it possible for me to use the API to validate the bitcoin address somehow? Or is that not possible?

[kiba]

I think I got an outline of a working system going for my bitcoin widget idea. Tomorrow is testing time and working out the bug. I hope the creator here will answer my question soon!

Or maybe other users can?

[Herbert]

What happened when you input an address that is not valid? Is it possible for me to use the API to validate the bitcoin address somehow? Or is that not possible?

The bitcoin addresses are checked for being valid. If you try to add an invalid address you will get an according error.

Edit: The check is done based on posting by Gavin: https://bitcointalk.org/index.php?topic=1026.0
So it is both checked for formal correctness and for stuff like version and checksum.

[Herbert]

This week i was mostly focussing on internal improvements regarding the connection between bitcoind and the website. For example the scenario of a complete or partial re-download of the blockchain is now handled well and should not result in duplicate or lost notifications.
Now i will start focusing on the more visible changes again:
- Increase retry time
- Add options for auto-expiring watched addresses as discussed with mcorlett

[Herbert]

I was spending quite some time on auto-expiration of addresses based on the received amount. So you would have a setting like "stop monitoring this address after 2.5 btc are received".
Let's say you have an agent configured to do a http callback at 0 and at 6 confirmations. You set up an address to expire after 2 btc are received.

Best-case scenario:

• 2.5 btc are transferred, 0-confirmation callback is done.
• ... 5 new blocks arrive...
• 6 confirmations are reached, second callback is done, address is removed from agent

Things that could go wrong:

• only partial payment is received: The address would never expire, unless the final amount is reached. This could block the address "forever"
• After e.g the third confirmation is reached another transaction comes in. What should happen? Ignore, because the initial payment is still not "done" from agents pov? Notify again with 0 confirmations for the second payment, then expire address because 6th confirmation of first payment is done, effectively never getting a 6th confirmation for the second payment? Don't expire after the 6th confirmation of the first transaction because of the new transaction, probably totally confusing the logic on the other side which expects the address to be expired after the 6th confirmation?

And I am quite sure there are more complicated cases which would result in an uncertainty on the other end. I am starting to think this amount-based auto-expire poses quite some risk for error between my end and the users end. It seems the callback receiver can never be sure if an address is still being watched or not. And if I implement some complicated logic to handle the cases outlined above in some defined manner this would be way to complicated to follow in the receiver end. So the receiver would need to poll the agent regularly to know if an address is already expired or still being watched. I am not sure if this would be a desired solution...

So currently i am in favor of dropping this auto-expire idea. I will never feel 100% confident to do the "right" (in the sense of what user expects to happen) thing. It might be better to have the behaviour of the agents less "intelligent" but 100% predictable.

Any opinions out there on this topic?

[kiba]

So currently i am in favor of dropping this auto-expire idea. I will never feel 100% confident to do the "right" (in the sense of what user expects to happen) thing. It might be better to have the behaviour of the agents less "intelligent" but 100% predictable.

Any opinions out there on this topic?

Yes, it should be predictable and easy to use.

[kiba]

I was wondering if it was possible to test the notify url with the localhost. If so, how can I do this?

[Herbert]

I was wondering if it was possible to test the notify url with the localhost. If so, how can I do this?

I don't get it - What do you want to do? Have a test notification received by your local (development) system? This should be easy, you just need to know your external IP, have appropriate port forwarding enabled in your router and be sure to listen not only on 127.0.0.1 but on 0.0.0.0 (any network interface).

[mcorlett]

I was wondering if it was possible to test the notify url with the localhost. If so, how can I do this?

If you have a development sandbox and don't want to expose it to the net, you can simulate the request from bitcoinmonitor to requestb.in and then just proxy those parameters through manually.