Topic: [Announce] bitcoinmonitor.net - Free professional notification/payment service - page 5. (Read 19523 times)

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.

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?

Ah, makes sense now *taking notes* 


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.

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?

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

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

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?

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?

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 "[email protected]" to your contacts and allow incoming messages.

Have fun :-)

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

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.

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.

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.

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

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.

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

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

Yes, it should be predictable and easy to use.

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?

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

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://bitcointalksearch.org/topic/python-code-for-validating-bitcoin-address-1026
So it is both checked for formal correctness and for stuff like version and checksum.