In the old wallet version, name_firstupdate was activated automatically when 12 confirmations were reached.
In the new wallet version this operation requires password to proceed.
Is there a way to automate this process? I tried to unlock my wallet in advance, but again it wants a password.
(Brandon is best-placed to answer this, but I'll give it a shot since he hasn't posted in this thread yet. I'll point Brandon to this thread.)
The old client duplicated a lot of wallet functionality in the name GUI code. This made it extremely difficult to maintain that code, since every time upstream Bitcoin Core changed the wallet GUI code, we had to port over the changes to our custom code. This was exacerbated by the fact that Daniel isn't fond of touching the Qt code.
Brandon's solution was to make the name GUI simply call the RPC commands. This strongly simplified the codebase and made it easier for us to maintain. Unfortunately, due to time constraints, the simplest way to do this was to call name_new and name_firstupdate, and name_firstupdate has 2 constraints on how it can be called. name_firstupdate can't be called before the name_new transaction has been mined, and name_firstupdate requires that the wallet be unlocked. These 2 constraints, combined, mean that the wallet has to be unlocked twice: once for name_new and again for name_firstupdate.
The "right" solution for this is probably to use the raw transaction RPC commands instead of name_new and name_firstupdate. The workflow here would basically be to create a name_firstupdate transaction at the same time that we create name_new, sign both of them, and then lock the wallet and broadcast the two transactions 12 blocks apart without needing to unlock the wallet again.
I think we'll probably do this in the foreseeable future, we just wanted to get something out the door as quickly as possible, and the existing code was the best way to do that.
Note that there's actually a small issue introduced by the "right" solution: the name_firstupdate transaction can be DoSed by a malleability attack against the name_new transaction. This is a fairly difficult attack to pull off (most miners and relays will reject such attacks, so you'd probably need to mine it yourself), it's only a nuisance in terms of damage (you can fix it by re-generating the name_firstupdate), and it will be properly fixed by SegWit, so I'm not really that worried about it.