Walletnotify => Mint Alert!

So if you are trying to mint on a properly-aged single set of coins in your wallet, you probably want to quickly remove your wallet passphrase from memory as soon as the anticipated coinstake transaction occurs.

Fortunately, Peerunity includes the walletnotify feature that makes it quite simple to trigger an action whenever transactions occur in the wallet. Thus, the owner of the wallet can be notified of transactions even if the wallet is running in a headless environment. Although it is very simple there isn’t a lot of documentation on this feature, so this post is an attempt to raise awareness and explain its use.

The details below pertain specifically to Windows; but if you’re using Linux you’re likely capable of adapting these ideas accordingly.

Walletnotify is a config option that goes into the root data directory of the Peerunity wallet in a simple text file named “ppcoin.conf.” In a standard Vista or higher installation, the data directory is “C:\Users[i]{Your Username}[/i]\AppData\Roaming\PPCoin.” The file “ppcoin.conf” does not exist by default, so you have to create it yourself. The file only has to contain the single following line:

walletnotify=command string

command string is anything that you want to be triggered when a new transaction occurs in your wallet. The syntax is exactly the same as you would type into the Windows command shell.

For example your “ppcoin.conf” could contain the following single line:

walletnotify=start "" "C:\Windows\System32\calc.exe"

This example would launch the Windows calculator every time a new transaction occurs in the wallet.

(Actually, walletnotify is called twice for each transaction: once on the transaction’s initial arrival in the wallet, and again after the transaction’s first confirmation. This can be kind of a nuisance depending on your design, but there are definitely ways to work with it!)

In the above example, the start command followed by empty “” is a bit of Windows quirkiness that is needed to prevent the shell from keeping a console window open while your triggered application/script is running.

In my personal case, I use walletnotify to run a script that sends an email to my cell phone carrier’s SMS gateway so that I get an instant text alert on my phone whenever there is activity in my wallet!

However, to perform even more fancy tricks you can consider adding these additional lines to the top of your “ppcoin.conf” file:

server=1 rpcuser=anyrandomstring rpcpassword=anyrandomstring

These lines enable the RPC interface making it possible to issue requests to the wallet through “C:\Program Files\Peerunity\daemon\peerunityd.exe”

For example, you could use walletnotify to automatically run “peerunityd.exe walletlock” and immediately lock your wallet following the anticipated coinstake transaction.

Or you could run “peerunityd.exe getbalance” as part of a triggered script to include the wallet’s current total balance in the desired notification.

If you prefer to use the standard wallet for minting instead of Peerunity you can use the same “ppcoin.conf” file to enable RPC. Then, although walletnotify isn’t available yet in the standard wallet, you can run the following bit of a kludge to achieve a similar effect:

Just copy the below text into an empty file with either .bat or .cmd extension and run it alongside your standard wallet. (Note: please adjust the first 2 lines as necessary to match your system and/or preferences!)

[code]@echo off

REM Make sure that the following path matches your installation
set DAEMON=“C:\Program Files\PPCoin\daemon\ppcoind.exe”

REM Replace the following with the program/command you want to run on wallet balance change
set NOTIFY=“C:\Windows\System32\calc.exe”

REM Store initial balance in variable “BALANCE”
for /f %%a in (’%DAEMON% getbalance’) do set BALANCE=%%a


REM Wait one minute
timeout /t 60 /nobreak > NUL

REM Store current balance in variable “NEWBALANCE”
for /f %%a in (’%DAEMON% getbalance’) do set NEWBALANCE=%%a

REM If variables aren’t equal execute NOTIFY and update value of BALANCE

REM Repeat above loop indefinitely
goto loop[/code]

So while we wait for a secure minting solution, you can at least use these methods to prevent your wallet from being “needlessly” unlocked during periods when you have no expectation of minting a block. Also, there is theoretically some increased risk of attack immediately following minting a coinstake block in that the network will gain some information about your balance and, with the proper analysis, possibly your exact location, so by immediately locking your wallet you mitigate this additional risk.

Finally, I have a question for anyone who is still reading and has a better understanding of how Peercoin clients behave in the face of attempted double spends… specifically, I am wondering if the following scenario is possible:

[ol][li]Pre-pepare and store my own raw transaction sending all my unspent outputs to an address I own.[/li]
[li]Start minting with a hot wallet.[/li]
[li]Use walletnotify to run a script that immediately broadcasts the above prepared transaction to the network if any new transaction (other than coinstake) occurs in the wallet.[/li]
[li]The pre-prepared transaction is accepted into the next block instead of the unexpected/unwanted transaction.[/li][/ol]

In other words, if an attacker has attempted to spend my coins, is it possible to immediately “chase” it with a double spend?
Is there >0% chance that this method might prevent the theft, or will the attacker’s transaction always be preferred as valid?
With Bitcoin, it appears that I might increase the odds of success by including a comparatively larger transaction fee in the pre-prepared transaction. Is there any way to similarly improve the chance of my transaction being accepted over the attacker’s in Peercoin?

Thanks for reading!

Thanks for the explanation of walletnotify. I’ve been resorting to regular refreshes of ppc.blockr.io to keep an eye on my wallet from afar. LOL!

In regards to your question, it’s my understanding that at least as far as Bitcoin clients are concerned, the 2nd spend is always the one rejected.