Reply to topic  [ 3 posts ] 
Automate name_firstupdate operation 
Author Message

Posts: 8
os: linux
Reply with quote
Post Automate name_firstupdate operation
Hi,

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.


Sat Jul 01, 2017 10:12 am
Profile WWW

Posts: 1919
os: linux
Reply with quote
Post Re: Automate name_firstupdate operation
PeerName wrote:
Hi,

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.

Cheers!

_________________
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5


Fri Jul 07, 2017 8:07 am
Profile

Posts: 8
os: linux
Reply with quote
Post Re: Automate name_firstupdate operation
Thank you very much for the answer!


Fri Jul 07, 2017 9:59 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 3 posts ] 

Who is online

Users browsing this forum: Baidu [Spider] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.