Topic: [PATCH] monitoraddress/blocks (Read 5484 times)

See -blocknotify and -walletnotify command-line options in the latest code, which will run an arbitrary command when new blocks happen or transactions hit your wallet (and that arbitrary command can be "POST information to this URL...").

old topic, old patch. But i need this.
Is it possible to merge this patch? (impossible after the long time)
Or do i have to use this old bitcoind version?

nBits is difficulty in 'compact' format?  (if I recall correctly...)

It should be reported as floating-point 'difficulty', like you get from the 'getinfo' rpc command.

I will add that.

jgarzik's getblock patch has some extra information that your patch doesn't have.  Is it possible you could add them to your patch, particularly nBits?  For now I wrote some lines to patch your patch.

This is line from jgarzik's patch for nBits:

It would be nice for both of your patches to be merged into one.

Fatal error: Call to undefined function http_get_request_body()

I apparently don't have the HTTP extension and am uncertain how to provide it.

Workaround is: file_get_contents('php://input')

Pass "allwallet" to monitoraddress and you'll get all transactions that put coins in your wallet.

RE: getting the data POSTed in PHP:  Try:

json_string = http_get_request_body();

Also, POSTing to www.postbin.org (create a postbin there first) is really useful for debugging.

From my tests, the data is passed as the body of the POST request. For example, the following Perl code using the Mojolicious web framework will extract data from the POST:


Here the $params variable contains the decoded JSON data equivalent to what 'getblock' returns if this was posted as a result of 'monitorblocks'. It will return the equivalent of what 'gettransaction' returns if it was posted as a result of 'monitoraddresses'. I wasn't sure what it expected as a result so I just return an empty JSON method result.

I agree.  A "monitorall" command would be quite useful.

This should show the data that is passed along.

Incorrect.  See response at link.

Just a quick note that this patch is not compatible with https://bitcointalksearch.org/topic/m.8053

I automated updating/patching the monitorreceived patch, and just updated to Satoshi's latest:
  http://gist.github.com/604574
(use the "raw" link there for a link to latest version of the patch)

And I fixed the bug reported by doublec.

I updated most of my git branches to svn rev 161 last night, including monitorreceived.  That's easy:
   git svn fetch   (but you have to have an "svn-remote" setup in your .git/config)
   git merge refs/remotes/svn/trunk    (I could git rebase instead, but merge seems less magical to me)
    ... fix any merge conflicts and test then git commit, if needed  (usually there are none)
   git push   (to push up to github)

Repeated on each branch (I'll try to keep svn, svnTEST and monitorreceived up-to-date).

Keeping the patch file up-to-date is another couple of steps, and I could/should automate it.

doublec: thanks for the bug report, I'll look into it as soon as I get this machine setup.

With the existing patch (and the git repository) if you call monitoraddress with a monitor value of 'false' (to remove a monitor) but pass a URL that is not being monitored then the bitcoin daemon process will exit. Possibly it's indexing into the map of monitor URL's, not finding it and throwing an exception.

Poor wording on my part. At that step (after you've done the 'git rebase or git merge') you have a repository equivalent to svn revision 161 with the monitor changes applied. The 'git diff' command that follows produces a diff of only the monitor changes.

I do not understand this step.  Did my previous steps update Bitcoin svn code to revision 161?  I do not understand "rebasing."

I am a git newbie and therefore it may be worthwhile or better time spent for someone who is experienced to maintain or produce a patch.  I could learn, but I have other priorities I must tend to.

Here's another approach to automatically generate a patch (or an update repository). Clone Gavin's repository and create a branch for your own changes based on origin/monitorreceived. Then rebase your branch on top of origin/svn. Git will then automagically apply the changes in the monitorreceived branch on top of the new svn changes. You can then either work on your new branch or generate a diff to get monitorreceived's changes only. Here's the steps:

git clone git://github.com/gavinandresen/bitcoin-git.git
cd bitcoin-git
git checkout -b mybranch origin/monitorreceived
git rebase origin/svn
...now you can build the new code updated to svn...

To get a diff:

git diff -U8 origin/svn >myfile.patch

I just tested and the rebase occurs without requiring use intervention.

You also merge if you prefer instead of rebasing:

git clone git://github.com/gavinandresen/bitcoin-git.git
cd bitcoin-git
git checkout -b mybranch origin/monitorreceived
git merge origin/svn

gavin: A question: If I continuously generate a new diff of your source code compared to latest svn repository and claim that as a patch, wouldn't that additionally produce a patch to an outdated or previous version?  e.g. if your patch initially worked with svn 158 (example) and currently latest is svn 500 (example), producing a patch comparing your source to latest svn and making it as a patch would then convert the bitcoin client to be very outdated and similar to svn 158.  This is my understanding.  Is this accurate/true?

As of right now the patch you supplied is not compatible with svn 161 and while I could technically create a diff comparison to generate a new patch, I fear that it will additionally revert changes that are unrelated to monitor functionality and ultimately produce a monitor-specific patch that reverts data not related to monitor capabilities.

Any suggestion on how to proceed in maintaining/preserving updated patch for this feature is appreciated.

gavin: If you are too busy to maintain a patch, perhaps someone could take over?  Is a btc bounty/donation helpful?  I, for one, will offer 5btc towards someone who will actively maintain this patch.

-Update-

Here is my attempt to produce a patch for Bitcoin svn 161:

I have established Bitcoin SVN in /downloads/svn/bitcoin/.
I have established gavin's Bitcoin-git in /downloads/git/bitcoin-git/.

Reviewing gavin's initial patch I know that only the following files are patched:
db.cpp
db.h
init.cpp
main.cpp
main.h
net.cpp
rpc.cpp
rpc.h

So I will generate a diff for only these files and additionally I will manually review each diff to make sure it is similar to gavin's submitted patch and does not include reverting unrelated changes due to further changes in Bitcoin svn.

db.cpp:
LC_ALL=C TZ=UTC0 diff -Napur /downloads/svn/bitcoin/trunk/db.cpp /downloads/git/bitcoin-git/db.cpp
Comparing this diff to gavin's I see
which I believe should not be included in the patch.  I will figure out how to manually exclude this and to preserve the patch as being correct in syntax.  Yep, it's unnecessary, and removing that block of patch, the remaining block of patch for db.cpp is identical.

Humm, manually modifying `diff`s is difficult, especially with rpc.cpp

Okay, yeah, I definitely give up.  I was doing pretty well until rpc.cpp when I realized that gavin's code contains WAY TOO MANY other patches besides only monitoraddress and monitorblocks and I have no idea how to remove these pieces from the patch data.

Additionally, using gavin's git-diff suggestion wasn't usable considering the svn code in his git repo is outdated.

If it is of any help, here is a manually compiled collection of diffs (using same switches as link above): http://pastebin.com/tN7hRZWH up to and not including rpc.cpp  (check file list above)

gavin: Would you be willing to provide a patch file for monitoraddress/blocks so that I may include it in my gentoo linux ebuild?

Here it is


Thanks gavin

Today:  a brand-new keypair (address) is created and added to your wallet when you have change.

Soon (I hope; I think satoshi is working on it...) bitcoin will pre-generate a bunch of addresses to use for change, and use one of them (and re-generate a bunch when it runs out).

I'd kind of like an option to put change back into one of the addresses it came from; that'd be simpler, quicker, and would make your wallet smaller...

BTW...  how do change transactions work?  what bitcoin address is chosen to receive the change?