snailbrain: testing the latest branch and it looks like (from the debug.log) the name_new pop-up is creating the "Automatic name_firstupdate ... " transaction twice?
Automatic name_firstupdate created for name d/bluewall, created tx: 5a6efa37eab3399d808365632257493d3313e47af8a7f5ed2e687205fe64cefb
sending: inv (37 bytes)
updateWallet da6f03cbfc3bbddf80a4451adab890435b47ebe35e764c32aa7ce77a5edefd8c 1
inWallet=1 inModel=1 Index=12-13 showTransaction=1 derivedStatus=1
updateWallet c41ad2083ef317d14400c8e1c829cf81470a8e4f29a8954ff69596becf834103 1
inWallet=1 inModel=0 Index=12-12 showTransaction=1 derivedStatus=0
updateWallet da6f03cbfc3bbddf80a4451adab890435b47ebe35e764c32aa7ce77a5edefd8c 1
inWallet=1 inModel=1 Index=13-14 showTransaction=1 derivedStatus=1
sending: inv (37 bytes)
sending: inv (37 bytes)
received: getdata (37 bytes)
received getdata for: tx c41ad2083ef317d14400
sending: tx (257 bytes)
received: getdata (37 bytes)
received getdata for: tx c41ad2083ef317d14400
sending: tx (257 bytes)
sending: inv (37 bytes)
received: getdata (37 bytes)
received getdata for: tx c41ad2083ef317d14400
sending: tx (257 bytes)
sending: inv (37 bytes)
sending: inv (37 bytes)
received: getdata (37 bytes)
received getdata for: tx c41ad2083ef317d14400
sending: tx (257 bytes)
received: getdata (37 bytes)
received getdata for: tx c41ad2083ef317d14400
sending: tx (257 bytes)
received: getdata (37 bytes)
received getdata for: tx c41ad2083ef317d14400
sending: tx (257 bytes)
sending: inv (37 bytes)
14/06/13 22:29:11 Flushing wallet.dat
Flushed wallet.dat 87ms
received: inv (37 bytes)
got inventory: tx c41ad2083ef317d14400 have
sending: inv (37 bytes)
keypool added key 134, size=101
keypool reserve 34
keypool keep 34
total value = 1500000
keypool added key 135, size=101
keypool reserve 35
keypool keep 35
Automatic name_firstupdate created for name d/bluewall, created tx: 156e4aa85ea82f56be91245bac112195e9f597c2ad5fa16692987648c298347f
and they have different tx number? Is this expected behaviour?
there is a few problems with it atm (the auto first update)..
it signs a transaction, but if within 12 blocks you send NMC, the transaction may become invalid. So coins for firstupdate have to be locked somehow.
Example: you have 100 NMC on a single address, create a name_firstupdate. Then you spend 1 NMC. 99 NMC are sent to you onto a new address (the change) and the firstupdate becomes invalid, since its tx-in refers to the old 100 NMC address.
also some other issues.. working on them (will get the log looked at thanks)
