G+ is the way to go

Interesting idea!

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

@Joric: +1 for the default passphrase

Closed without comment 

Seems we have to do it on our own then

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.

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 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?

Would I use a decentralized exchange? Hell, yes!

But i don't have much trust in this mintchip-thingie, so if this is a condition: No!

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://bitcointalk.org/index.php?topic=1026.0
So it is both checked for formal correctness and for stuff like version and checksum.

https://bitcointalk.org/index.php?topic=74946.0 

Works great on my home machine (Arch linux) and also as (slightly patched) daemon on bitcoinmonitor.net since it's available. No problems so far  And I'm impressed at the blockchain download speedup.

Great!

Thanks theymos 

Definitely interesting. Could you elaborate on your motivation? It seems you want to do this "just" to bring bitcoin forward? Or any other background?

 
@Mods: Any chance to get this integrated? It's kinda shame that our forum doesn't support our own standards...

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

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

Just tried to add a bitcoin-uri to my signature, but no luck. Board keeps adding "http://"-prefix as it does not recognize the bitcoin-uri.

What i want to do:

What gets stored:

I have no idea if this can be added easily or not...

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