- By enabling
-namehashindex
, Namecoin Core can now keep track of a separate database that maps hashes to preimages for all registered names. With this,name_show
andname_history
can now optionally look up names by hash. This has uses for light clients, as discussed in #329.
- The mempool now allows multiple updates of a single name (in a chain of
transactions). This is something that is allowed in blocks already,
i.e. it is just a policy change. The
name_update
RPC command still prevents such transactions from being created for now, until miners and relaying nodes have updated sufficiently. More details can be found in #322.
-
BIP16, CSV and Segwit will be activated at block height 475,000 on mainnet and 232,000 on testnet. See #239 for a discussion.
-
The
options
argument forname_new
,name_firstupdate
andname_update
can now be used to specify per-RPC encodings for names and values by setting thenameEncoding
andvalueEncoding
fields, respectively. -
name_scan
now accepts an optionaloptions
argument, which can be used to specify filtering conditions (based on number of confirmations, prefix and regexp matches of a name). See #237 for more details. -
name_filter
has been removed. Instead,name_scan
with the newly added filtering options can be used. -
ismine
is no longer added to RPC results if no wallet is associated to an RPC call.
-
Previously,
createrawtransaction
supported a separate argument for creating name operations. This has been removed, so thatcreaterawtransaction
now has the same interface as the upstream version in Bitcoin. Instead, a new RPC methodnamerawtransaction
has been added, which takes an already created transaction and changes its output to be a name operation. For more details, see #181. -
The optional "destination address" argument to
name_update
andname_firstupdate
has been removed. Instead, those methods as well asname_new
now accept an optionaloptions
argument. The destination address can now be specified by settingdestAddress
in these options. In addition, one can now also specify to send namecoins to addresses (similar tosendmany
) in the same transaction by using the newsendTo
option. See also the basic proposal, which is not yet completely implemented, and the concrete changes done in #220 and #222. -
listunspent
now explicitly handles name outputs. In particular, the coins associated to expired names are now always excluded. Coins tied to active names are included only if theincludeNames
option is set, and they are marked as name operations in this case. More details can be found in #192. -
The
transferred
field in the output ofname_list
has been changed toismine
(with the negated value). This makes it consistent withname_pending
. In addition,ismine
has also been added to the other name RPCs likename_show
orname_scan
. See the proposal and the implementation. -
name_new
now checks whether a name exists already and by default rejects to register an already existing name. To override this check and get back the old behaviour (where aNAME_NEW
transaction can be sent for existing names), set the newallowExisting
option to true. For more context, see the corresponding issue. -
Names and values in the RPC interface (and to a limited degree also the REST interface and
namecoin-tx
) can now be specified and requested in one of three encodings (ascii
,utf8
andhex
). This fixes a long-standing issue with names or values that were invalid UTF-8, by adding proper support for pure binary data as well as validation of the data before returning it as ASCII or UTF-8. The encodings default toascii
now. To get back behaviour close to the previous one, specify-nameencoding=utf8
and-valueencoding=utf8
. The detailed specification of the new encoding options can be found in the Github issue. -
The
namecoin-tx
utility has now support for creating name operations based on the new commandsnamenew
,namefirstupdate
andnameupdate
. For the exact usage, see the proposal. -
The "magic string" used for
signmessage
andverifymessage
has been updated to be specific to Namecoin (previously, the one from Bitcoin was used). This means that messages signed previously won't validate anymore. It is, however, still possible to verify them customly; so old signatures can still be used as proofs in the future if necessary.