[PULL] monitortx monitorblocks listmonitored getblock

[MrJoshua]

From reading your other posts, I get the impression that you want to know about addresses that are not in the wallet.  I don't think this patch gives you that.

Oh doesn't it?  That was my understanding, as posted above, and no one has corrected me on that yet.

j

[1713930949]

1713930949

[1713930949]

1713930949

[1713930949]

1713930949

[1713930949]

1713930949

[kjj]

My C++ is really rusty, and I'm reading the diff out of context, but I believe that this patch just lets you add URLs to two lists, one that gets POSTs for every new block that comes in, and one that gets POSTs for every transaction that comes in related to the running wallet.

[2112]

... but I'm not 100% happy with it. I'm not sure it properly handles block chain re-orgs and dependent orphan transactions. Would be nice to write some tests to exercise those edge cases, and figure out what it SHOULD do in those cases.

In addition to the above this patch doesn't seem to have any mechanism for garbage collecting stale notification callbacks. From the cursory look I would guess that it doesn't even try to be idempotent, i.e. one could add multiple identical callback URLs with no limit that I could see.

[BitcoinLocator]

My C++ is really rusty, and I'm reading the diff out of context, but I believe that this patch just lets you add URLs to two lists, one that gets POSTs for every new block that comes in, and one that gets POSTs for every transaction that comes in related to the running wallet.

I hope this is not the case, and it doesn't make sense.  If you're receiving blocks complete with all transactions and you have addresses in your POST queue for monitortx why would you go out of your way to filter results based on the wallet?  It's an extra step to reduce functionality.

[Furyan]

Gavin,

I have been running with this patch for a few weeks now (decided to go ahead and see how big the problem might be).

So, orphaned blocks received from the network definitely do get posted via the monitorBlock workflow.  However, when bitcoin eventually re-orgs the block chain to replace the orphaned blocks with the real block from the longest chain, those blocks are not being posted.  For now I have a process that runs once in awhile to detect these cases and updates the values stored in the db, but I'm wondering if something can be modified in the patch to address it.

Interestingly, if the orphaned block is one of my own, I actually want to retain the old value for tracking purposes.

With regard to dependent orphaned transactions, I haven't run into those yet so can't comment.