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

[kiba]

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).

That's what just I need, although it seems a little bit complicated.

[kiba]

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.

Well, I don't know how to do that programmatically. I already test the request from bitcoinmonitor earlier. I just need to expose my development environment to bitcoinmonitor.net so I can see if everything works together.

I believe I have written all I need, it's just that I need to debug and fix any bugs that prevent my app from demonstrating proof of concept.

[Herbert]

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).

That's what just I need, although it seems a little bit complicated.

It's not really complicated. Most important is the router setup. You need to establish port-forwarding rule to route incoming http requests from your router to your development machine. I think all routers support such functionality. Then you can trigger the test requests from bitcoinmonitor.net to your external IP (check e.g. http://whatismyip.com if you don't know your IP). Your router will forward the request to your development machine and you test locally.

Last thing to make sure on your development machine is that it is listening on your local IP-Address (e.g. 192... or 10....) and not just on 127.0.0.1, which is the safe default e.g. when working with the django development server. If you are not sure, just let it listen on IP-Address 0.0.0.0 which basically means all local IP-addresses.

[Herbert]

FYI: I just detected a race condition that can lead to duplicate notification for 0/unconfirmed transactions.

This happens if:
- You have an agent set up which only notifies on 0 confirmations
- The time between receiving the unconfirmed transaction and the next block containing it is unusually long (in my case it was about 50 minutes)
 
Under this scenario my periodic "garbage collection" would delete the transaction from the watchlist as it already has been notified about and no additional notifications at >0 confirmations are requested. If this happens before the next block comes in, a failsave mechanism kicks in: At each new block all contained transactions are checked if they should be notified but are not on the watchlist (e.g because the initial transaction message was lost/not received). As the transaction has been removed from the watchlist already by the garbage collection it is considered "missed" and immediately the 0 confirmation transaction is triggered for it...

I have this fixed temporarily by increasing the transaction purging intervall to 2 hours which should be more than enough to have at least one block received until a transaction is removed from the watchlist. Of course proper codefix will also be done later.

Did anybody else experience this bug or am I the only one? Looking at my commit history i think I introduced this race condition on March 5th.

[Herbert]

Btw, real fix for this problem is online since yesterday.

[Herbert]

New Feature: XMPP notifications!

I just deployed a new build enabling Instant messaging notifications using XMPP protocol. This is the protcol behind Jabber, Google Talk and who knows what other services.
I am not entirely sure how the various clients handle receiving of messages from people not on your roster; therefor you can test if your account can receive messages - check the tab "test xmpp/jabber notification" in the support section. If you don't receive a testmessage try to add "bitcoinmonitor@jabber.org" to your contacts and allow incoming messages.

Have fun :-)

[mcorlett]

The service is working excellently, and I can see you taking steps to increase its reliability proactively. Thank you.

Because I'm using it to accept zero-confirmation payments, I'd like to know that steps are taken to increase the difficulty of a race attack.
For example: disallowing incoming connections, connecting to well-known nodes (pools, blockchain.info?), or waiting a couple of seconds and checking if a race is in progress before sending the notification to my server.

Is this something I can expect to see?

[Herbert]

The service is working excellently, and I can see you taking steps to increase its reliability proactively. Thank you.

Because I'm using it to accept zero-confirmation payments, I'd like to know that steps are taken to increase the difficulty of a race attack.
For example: disallowing incoming connections, connecting to well-known nodes (pools, blockchain.info?), or waiting a couple of seconds and checking if a race is in progress before sending the notification to my server.

Is this something I can expect to see?

Well, I don't have this on my roadmap at the moment, but indeed I am very interested in this topic. I am closely following e.g. what zipconf is doing to prevent double-spends.
Having this implemented would be another real advantage of using bitcoinmonitor for implementing a payment solution compared to the standard "run-your-own-bitcoind" solution. So as a summary you can expect some improvements in this area, but it will take quite some time until it will be available on the production system. When I have a decision on the steps I want to take I will update this thread also with a timeline.

Until then, suggestions and discussions are welcome!

Some thoughts/comments on your points above:

• disallowing incoming connections, connecting to well-known nodes (pools, blockchain.info?)

We have to consider that this adds a dependency on third party systems. Although it is unlikely that the big nodes have trouble at the same time it is still a single point of failure compared to the normal p2p-network.

• waiting a couple of seconds and checking if a race is in progress

This will add a delay in notifications (sth like 10 seconds should be enough?). This could be implemented without adding additional dependencies. Should be combined with multiple bitcoinds running on different network segments, probably with a patch to have more concurrent connections than the default setting to be sure to catch all double-spend attempts. And of course should be configurable per agent, to allow the user to prefer instant notifications over additional security.

Question:
What would be the expected behaviour when a double-spend attempt is detected? Common opinion is to wait until 6 confirmations to be sure that a transaction is fine. So i would track both transactions until one of them gets 6 confirmations. Only then notifications will be generated and the loosing transaction would just be dropped.
Makes sense?

[mcorlett]

• disallowing incoming connections, connecting to well-known nodes (pools, blockchain.info?)

We have to consider that this adds a dependency on third party systems. Although it is unlikely that the big nodes have trouble at the same time it is still a single point of failure compared to the normal p2p-network.

No, it does not. You can still connect to other peers and nodes as usual, it just disallows them from connecting to you. Connecting to well-known nodes is not necessary, but will help in detecting race attacks faster.

Consider this scenario:
I create two transactions:

• I send 1 BTC from address A (under my control) to merchant B (using bitcoinmonitor for 0-conf transactions)
• I send 1 BTC from address A (under my control) to address C (also under my control)

I broadcast the two transactions at the exact same time, but because I'm able to connect to bitcoinmonitor's node, I broadcast the first transaction only to you, and the second transaction to DeepBit, Blockchain.info, Slush's pool, etc.

Bitcoinmonitor noticed the first transaction, and immediately sent a zero-confirmation notification to the merchant, who gave me the digital good or whatever. Because I sent the second transaction to a larger subset of nodes, including mining pools, it is very likely that the transaction sending the coins back to myself is going to get accepted in a block, screwing over the merchant. A simple short waiting period should be sufficient to protect against this. (See below.)

• waiting a couple of seconds and checking if a race is in progress

This will add a delay in notifications (sth like 10 seconds should be enough?). This could be implemented without adding additional dependencies. Should be combined with multiple bitcoinds running on different network segments, probably with a patch to have more concurrent connections than the default setting to be sure to catch all double-spend attempts. And of course should be configurable per agent, to allow the user to prefer instant notifications over additional security.

10 seconds is more than enough. Somewhat relevant: http://eprint.iacr.org/2012/248.pdf

[Stephen Gornick]

Question:
What would be the expected behaviour when a double-spend attempt is detected? Common opinion is to wait until 6 confirmations to be sure that a transaction is fine. So i would track both transactions until one of them gets 6 confirmations. Only then notifications will be generated and the loosing transaction would just be dropped.

I'm not sure I follow.  If I have an agent set to notify on 0 confirmations, you send that out.  But then let's say you detect a double spend at the first block (e..g, a Finney attack was successful).   Shouldn't that trigger a notification alerting me to the double spend immediately then?

[Herbert]

Consider this scenario:
I create two transactions:

• I send 1 BTC from address A (under my control) to merchant B (using bitcoinmonitor for 0-conf transactions)
• I send 1 BTC from address A (under my control) to address C (also under my control)

I broadcast the two transactions at the exact same time, but because I'm able to connect to bitcoinmonitor's node, I broadcast the first transaction only to you, and the second transaction to DeepBit, Blockchain.info, Slush's pool, etc.

Bitcoinmonitor noticed the first transaction, and immediately sent a zero-confirmation notification to the merchant, who gave me the digital good or whatever. Because I sent the second transaction to a larger subset of nodes, including mining pools, it is very likely that the transaction sending the coins back to myself is going to get accepted in a block, screwing over the merchant. A simple short waiting period should be sufficient to protect against this. (See below.)

Ah, makes sense now *taking notes* 

Question:
What would be the expected behaviour when a double-spend attempt is detected? Common opinion is to wait until 6 confirmations to be sure that a transaction is fine. So i would track both transactions until one of them gets 6 confirmations. Only then notifications will be generated and the loosing transaction would just be dropped.

I'm not sure I follow.  If I have an agent set to notify on 0 confirmations, you send that out.  But then let's say you detect a double spend at the first block (e..g, a Finney attack was successful).   Shouldn't that trigger a notification alerting me to the double spend immediately then?

The idea would be to delay also the 0-conf notification by a few seconds to monitor the network for a possible double-spend attempt. So what should happen when a double-spend is detected? At that time i can not know which of the attempts will make it, so there is no way to decide if the notification should be done or not.
One option would be to wait untill one of the transactions is confirmed (has 6 (?) confirmations) and only then fire the notification(s). So there would be a delay in notification, but i think this would be better than firing a notification and few seconds later "revoke" it by issueing a double-spend alert.

[Herbert]

Currently I am working on extending bitcoind to provide notifications in case a double-spend attempt is detected (Incoming tx with inputs that are already spent by other tx in mempool). This will for sure take some time until ready for production - but i was thinking about a preliminary improvement:
The whole idea of this double-spend is based on the possibility of an attacker to make a direct connection to "my" bitcoind, resulting in bitcoinmonitor.net performing 0-confirmation notification while the rest of the network gets at the same time a different tx with different outpoints controlled by the attacker.

So, if i move the main bitcoin daemon(s) i use for bitcoinmonitor.net to different systems (different IPs at different subnets), no one will know which bitcoind to target. Problem solved?

Of course this would only be security by obscurity, but untill the proper double-spend detection is in place this could already help.

What do you think?

[mcorlett]

So, if i move the main bitcoin daemon(s) i use for bitcoinmonitor.net to different systems (different IPs at different subnets), no one will know which bitcoind to target. Problem solved?

Of course this would only be security by obscurity, but untill the proper double-spend detection is in place this could already help.

Yes, this would probably work. As I said, a delay of only a few seconds would make the attack entirely unfeasible to perform, so that would be the ideal solution.

[Stephen Gornick]

So, if i move the main bitcoin daemon(s) i use for bitcoinmonitor.net to different systems (different IPs at different subnets), no one will know which bitcoind to target. Problem solved?

Well, you don't even need to do that.  Until you have listening nodes, you can lessen the exposure to a race attack by disabling listening on bitcoind ( -nolisten) and by explicitly connecting (using -connect= ) to a well connected node.  It doesn't mean a race isn't possible, but that the chance that your notification will jive with what comes through in the next block will be > 50% (presumably) even if there were a race attack attempted.

[Herbert]

Until you have listening nodes, you can lessen the exposure to a race attack by disabling listening on bitcoind ( -nolisten) and by explicitly connecting (using -connect= ) to a well connected node.  It doesn't mean a race isn't possible, but that the chance that your notification will jive with what comes through in the next block will be > 50% (presumably) even if there were a race attack attempted.

What would be the best way to get a list of well-connected nodes? Is there some list of "trusted" nodes existing already which have valid DNS entries?

[Herbert]

Delayed notifications today

Today bitcoinmonitor.net had some trouble. Starting somewhere yesterday night the process handling new block events was hanging.

This had the following consequence:

• 0-confirmation notifications were triggered and executed as usual (they are not depending on the new blocks handling)
• All other notifications (1 to 10 confirmations) were not triggered

The site is now working again fully functional, and all missed notifications should be delivered by now.

I am still investigating what is the root cause of the hanging daemon process.

[Herbert]

On the topic of preventing double-spend attacks (race attacks):

• The site's bitcoind now runs with -nolisten and increased number of connections (currently 100). So the chance for a successful race attack is dramatically reduced 
• I am still working in parallel on providing active race-attack detection and notification

[Btc4Domains]

Hi, nice project, I just opened an account to take a closer look.
I'm wondering.. if I created a dedicated wallet, say in Armory, and I loaded in the root characters needed to calculate all possible addresses, or a watching only copy, could this system keep track of any transactions that come through on the blockchain to a matching address? Say it was possible, how much might you need to create and maintain it? And could you pickup outgoing transactions as well using the same principal?

[Herbert]

Hi, nice project, I just opened an account to take a closer look.
I'm wondering.. if I created a dedicated wallet, say in Armory, and I loaded in the root characters needed to calculate all possible addresses, or a watching only copy, could this system keep track of any transactions that come through on the blockchain to a matching address? Say it was possible, how much might you need to create and maintain it? And could you pickup outgoing transactions as well using the same principal?

Let's see if I understand you correctly:
You use a client with deterministic wallet. You want to provide only the "seed" of the deterministic wallet to the bitcoinmonitor agent, so it can derive all bitcoin addresses automatically. Correct?
I can not say if this would be possible or how much work would be involved. I did not follow the deterministic wallet concept in detail so far. But it sounds very cool, because you would not need to enter all addresses manually/by API 

Regarding outgoing transactions: It is already possible to get notifications also on ougoing transactions. This can be configured for each agent individually.

[Btc4Domains]

You got it, exactly! Load the 'seed' to a deterministic wallet - much better lingo thanks

It would mean if you have a dedicated wallet, say for a GLBSE Asset or a share business with multiple owners - if you implemented some basic templates enabling the user to classify the Outgoings (Purchase, Deposit, Investment, Fee etc) can do something similar for the Incomings (Interest, Dividend, Bond Payment, Loan Repayment etc) - anyone with a vested interest in that particular wallet could follow the flow - everything is transparent! Recurring addresses are already tagged, addresses known in advance can be tagged and classified from the beginning - the user just needs to update the tags for any new addresses that show up in the Outgoing or Incoming transactions.

You could even provide a nifty suite of exportable formats, colourful graphs and bells and whistles used in any other accounting reports - you could charge for it!   

Are you interested in investors??