namecoin
Add name_autoregister RPC
This PR adds the name_autoregister RPC, with delegation support.
Note that there is a bug, which can be triggered by the testing, that causes the transaction queue to release one block later than it should in certain cases.
I've not been able to narrow it down entirely, but I believe it has to do with mempool logic, and not the transaction queue or any code in this PR. Looking at the logs, the transactions do get dequeued and entered into the mempool properly, and the failure comes after that. Nevertheless, there is a chance of about 3% that the tests will fail randomly.
To reproduce consistently, see the line commented # hack. I believe it has to do with generating multiple blocks at a time, so it might not even be possible to reproduce it under IRL conditions.
This bug is not liable to produce any serious user harm, loss of funds, etc, other than a small annoyance. The bug may make name "sniping" less reliable than expected, but that is definitely not a feature of this patch.
Thank you for your consideration.
(Edited to reflect the final PR, that's why the conversation below looks strange)
Regarding marking the inputs as unspendable: There is a "lock" functionality in the wallet (for lockunspent), perhaps you could use that. I believe it is not persistent and only stored in memory, but you could read the wallet on startup to look for all those "delayed" transactions and then go and lock the corresponding inputs for them on startup, maybe.
For splitting up the PRs, do you mean the name function refactoring vs name_autoregister? That sounds like a good idea (but I don't see any of that refactoring in the code yet, except for nameExists, which I definitely like).
@domob1812 Right, I understand I'm supposed to use the LockCoin API, but even if I copy the code more or less verbatim I can't seem to get it to work. Is there something else I need to do for it to work consistently? Something with locking maybe, or to get it to apply the changes?
I've pushed the broken code into the PR to show you what I've tried so you can have a look, but I'm at a loss.
Unfortunately, I've never used the coin-locking feature myself, so I don't really have code-level experience with it. But I will look at the code and play around with it a bit maybe to see if I can find something.
I'm currently travelling but will take a look in ten days when I'm back - sorry for the inconvenience.
Thanks for all your review Daniel!
I agree very strongly with everything you have said about delegation. I think the current situation is really hacky and frankly the code I submitted is not all that good. So I will take that out and save it for later, because it needs to be dealt with more calmly. There's already an issue for that stuff and so on.
I will look over the other stuff you said because it will take some time to fix that. Basically, am I right in thinking that I might as well just fully refactor out the issue_xx stuff and use them in name_new and name_firstupdate as well?
Thanks! And yes, if you can factor out the issue things and make them reused in the name_new and name_firstupdate RPCs (i.e. as a first step, just factor out the logic you will need to reuse into helper methods from them), that would be great! This could then even be a separate PR to get a headstart in reviewing and merging away some of the changes already.
I believe that a pre-register and a register button are sufficient.
Auto registration seems a little far-fetched. The user would have little or no control over the process, and it does not appear that such an auto registration can be cancelled, which could be problematic.
