namecoin / namecoin-core

Namecoin full node + wallet based on the current Bitcoin Core codebase.

Namecoin

Namecoin is a decentralized key/value registration and transfer system based on Bitcoin technology (a decentralized cryptocurrency).

It can be used for multiple purposes, for example a secure and censorship resistant replacement for DNS.

Ownership of a name is based on ownership of a coin, which is in turn based on public key cryptography. The namecoin network reaches consensus every few minutes as to which names have been reserved or updated.

There is a FAQ.md to answer some general questions.

See http://namecoin.info or http://dot-bit.org for more information.

Technical

The Bitcoin protocol is augmented with namecoin operations, to reserve, register and update names. In addition to DNS like entries, arbitrary name/value pairs are allowed and multiple namespaces will be available. This will include a personal handle namespace mapping handles to public keys and personal address data.

The protocol differences from bitcoin include:

• Different blockchain, port, IRC bootstrap and message header
• New transaction types: new, first-update, update
• Validation on the new transaction types
• RPC calls for managing names
• Network fees to slow down the initial rush

Please read DESIGN-namecoind.md for details.

BUILDING

Building is supported on Linux, Windows and Mac. For building on windows you can use the scripts in ./contrib/easywinbuilder. Find build instructions on https://wiki.namecoin.info/index.php?title=Build_Namecoin_From_Source.

namecoin-core's Issues

Latest NMC daemon not working with p2pool.

The latest client seems to be broken with p2pool - I've been getting these errors repeatedly since updating:

2015-12-07 00:37:59.409856 > Error while calling merged getauxblock on http://127.0.0.1:7333/:
2015-12-07 00:37:59.409981 > Traceback (most recent call last):
2015-12-07 00:37:59.410021 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 577, in _runCallbacks
2015-12-07 00:37:59.410057 > current.result = callback(current.result, _args, *_kw)
2015-12-07 00:37:59.410091 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1155, in gotResult
2015-12-07 00:37:59.410124 > _inlineCallbacks(r, g, deferred)
2015-12-07 00:37:59.410157 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1097, in _inlineCallbacks
2015-12-07 00:37:59.410192 > result = result.throwExceptionIntoGenerator(g)
2015-12-07 00:37:59.410226 > File "/usr/lib/python2.7/dist-packages/twisted/python/failure.py", line 389, in throwExceptionIntoGenerator
2015-12-07 00:37:59.410262 > return g.throw(self.type, self.value, self.tb)
2015-12-07 00:37:59.410294 > --- ---
2015-12-07 00:37:59.410326 > File "/home/rig/p2pool/p2pool/util/deferral.py", line 41, in f
2015-12-07 00:37:59.410359 > result = yield func(_args, *_kwargs)
2015-12-07 00:37:59.410391 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1097, in _inlineCallbacks
2015-12-07 00:37:59.410424 > result = result.throwExceptionIntoGenerator(g)
2015-12-07 00:37:59.410456 > File "/usr/lib/python2.7/dist-packages/twisted/python/failure.py", line 389, in throwExceptionIntoGenerator
2015-12-07 00:37:59.410490 > return g.throw(self.type, self.value, self.tb)
2015-12-07 00:37:59.410523 > File "/home/rig/p2pool/p2pool/util/jsonrpc.py", line 133, in _http_do
2015-12-07 00:37:59.410558 > raise Error_for_code(resp['error']['code'])(resp['error']['message'], resp['error'].get('data', None))
2015-12-07 00:37:59.410593 > p2pool.util.jsonrpc.NarrowError: -1 CreateNewBlock: TestBlockValidity failed: (code 0)

Reset testnet or add checkpoints?

Right now our testnet is a mess. This is not a big problem because you can develop in regtest mode but new developers should be able to use testnet as a starting point.

I was using the bitcoin-seeder code to find testnet nodes, and there are to few. And even less that are running Namecoin Core. Old clients now accept and mine with version 1 blocks and new clients do not.

Is Namecoin Core Testnet2 the solution?

Chainmerklebranch always null

$ getblock ac9237ab66fb0d605f9b67497dd66832fecaba968f0d862caff63e6c02e1f9df
...
"chainmerklebranch": null,

Does it work for others? It did for me with the old client / a previous version of Namecoin core (can't recall which it was).

Assertion `pindexPrev' failed.

Hello, my Namecoin got a problem

./namecoind
Namecoin server starting
namecoin@server ~/namecore/src $ namecoind: main.cpp:3004: bool AcceptBlockHeader(const CBlockHeader&, CValidationState&, CBlockIndex**): Assertion `pindexPrev' failed.

I already tried
namecoin@server ~/namecore/src $ ./namecoind -reindex
but I got the same result.

Any advice?

0.11 trying to overwrite '/usr/local/bin/test_bitcoin'

This should probably be changed.

Unpacking namecore (0.11-1) ...
dpkg: error processing archive namecore-master/namecore_0.11-1_amd64.deb (--install):
 trying to overwrite '/usr/local/bin/test_bitcoin', which is also in package bitcoin

namecoin-qt.exe icon is very low-res

Steps to Reproduce: build Bitcoin Core and Namecoin Core for Windows with Gitian. Extract the 64-bit zips onto a Windows 10 machine. Go to the bin folders in Windows Explorer. Click "View" --> "Extra large icons".

Expected results: bitcoin-qt.exe and namecoin-qt.exe should have similarly high-quality icons displayed.

Observed results: namecoin-qt.exe's icon is very small and low-resolution compared to bitcoin-qt.exe's icon.

Note that right now Namecoin Core master branch doesn't build for Windows in Gitian; I will submit a PR for that soon. So, it may be difficult to reproduce this issue for Windows right now.

• master branch
• 0.12 branch

Rename repo to 'namecoin-core'

Migrating discussion from forum thread.

@JeremyRand and Indoling have voiced support for changing the name of this repo from namecore to namecoin-core.

The "namecore" name does not follow Bitcoin's "Bitcoin Core" naming convention and also represents a potential naming collision with the Bitcore JS library. This name change should happen ASAP before the repo gains widespread use.

Explicitly replace all architecture dependent code.

E.g. https://github.com/namecoin/namecore/blob/master/src/auxpow.cpp#L197

Works but is not so nice as values during computation differ between 32-bit and 64-bit. Also in some places where memcpy is used.

Add signal for name updates

Bitcoin and, in consequence, Namecoin Core implement a rough "signaling" mechanism for new blocks, alerts and tx in the wallet (blocknotify, alertnotify and walletnotify). Very recently, they apparently also added a messaging system based on ZeroMQ.

Should we take advantage of this infrastructure and work on a way to get notification on name updates? This could be useful for things like NMControl that cache values. On the other hand, it probably only makes sense if one can explicitly specify the set of names one is interested in. Otherwise, just using the block notification is enough (except if one is looking for pending transactions).

Thoughts?

Build errors with 0.12rc2 due to protobuf related errors

I can't get make to complete, although I've built Bitcoin Core 0.12 using the same process earlier today (no updates in between).
I'll try one more time.
Edit: nope, doesn't work.
How to repro: run configure using usual options (disable-shared, etc.), then make.

This is where it hits the fan:

make[2]: Entering directory '/blockchain/source/namecoin-core-nc0.12.0rc2/src'
  CXXLD    qt/test/test_namecoin-qt
  OBJCXXLD qt/namecoin-qt
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentserver.o): In function `Add<google::protobuf::RepeatedPtrField<std::basic_string<char> >::TypeHandler>':
/usr/include/google/protobuf/repeated_field.h:905: undefined reference to `google::protobuf::internal::StringTypeHandlerBase::New()'
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentserver.o): In function `PaymentServer::fetchPaymentACK(CWallet*, SendCoinsRecipient, QByteArray)':
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentserver.cpp:630: undefined reference to `google::protobuf::internal::empty_string_'
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentrequest.pb.o): In function `payments::Output::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const':
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:401: undefined reference to `google::protobuf::internal::WireFormatLite::WriteBytesMaybeAliased(int, std::string const&, google::protobuf::io::CodedOutputStream*)'
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentrequest.pb.o): In function `payments::PaymentACK::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const':
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:2242: undefined reference to `google::protobuf::internal::WireFormatLite::WriteStringMaybeAliased(int, std::string const&, google::protobuf::io::CodedOutputStream*)'
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentrequest.pb.o): In function `payments::PaymentRequest::SerializeWithCachedSizes(google::protobuf::io::CodedOutputStream*) const':
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:1295: undefined reference to `google::protobuf::internal::WireFormatLite::WriteStringMaybeAliased(int, std::string const&, google::protobuf::io::CodedOutputStream*)'
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:1301: undefined reference to `google::protobuf::internal::WireFormatLite::WriteBytesMaybeAliased(int, std::string const&, google::protobuf::io::CodedOutputStream*)'
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:1307: undefined reference to `google::protobuf::internal::WireFormatLite::WriteBytesMaybeAliased(int, std::string const&, google::protobuf::io::CodedOutputStream*)'
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:1313: undefined reference to `google::protobuf::internal::WireFormatLite::WriteBytesMaybeAliased(int, std::string const&, google::protobuf::io::CodedOutputStream*)'
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentrequest.pb.o): In function `GetEmptyStringAlreadyInited':
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:329: undefined reference to `google::protobuf::internal::empty_string_'
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:1176: undefined reference to `google::protobuf::internal::empty_string_'
/blockchain/source/namecoin-core-nc0.12.0rc2/src/qt/paymentrequest.pb.cc:651: undefined reference to `google::protobuf::internal::empty_string_'
qt/libbitcoinqt.a(qt_libbitcoinqt_a-paymentrequest.pb.o): In function `void google::protobuf::internal::RepeatedPtrFieldBase::Destroy<google::protobuf::RepeatedPtrField<std::string>::TypeHandler>() [clone .isra.68]':

Duplicate name creation allowed

namecoin-cli will happily create a name_new for a name which already exists. It should check for this and fail.

listtransactions command from not working correct

listtransactions "account" count from
if the from parameter is more than the amount of transactions user has in account,
the transactions will not return zero transactions list (as it should) , it will make the transaction zero.
this is not how bitcoind or litecoind client works.

Warning message "do not use for mining" inconsistent with current recommendations

The message "do not use for mining or merchant applications" in main.cpp and qt/bitcoinstrings.cpp is outdated. It contradicts the instructions in the OpenSSL Consensus thread:

... all mining pools MUST upgrade to Namecoin Core ...

Deprecate/remove sendtoname once reusable value-based sending is implemented

As discussed in #5 (comment) , I favor deprecating or removing sendtoname 6-12 months after the following features have been implemented:

1. NMControl supports sending funds to an address specified by the value of a name.
2. At least one Namecoin wallet application supports sending and receiving funds to reusable addresses (e.g. stealth addresses).

This issue will remain dormant until those two features have been implemented, and is solely present in the issue tracker as a reminder for when they have been implemented.

Namecoin-Qt generates network traffic without prompting for proxy settings

It's generally considered good practice in software that might want to use Tor, to prompt the user for proxy settings on the first run, before generating any network traffic. That way, the user doesn't accidentally connect over clearnet. At the moment, it seems that without command line flags, Namecoin-Qt will immediately connect to the Internet on first run.

This is actually an upstream Bitcoin-Qt issue, but I'm filing it here so that we can keep track of it. I'll file a bug upstream as well.

name_update should affect name_show before it is mined

Right now, a name_update needs 1 confirmation before it affects name_show. I think this is suboptimal. If a name owner believes that a key (e.g. a TLS key) referenced in the name is compromised, right now it will take on average 10 minutes for the key to be revoked. That could be a significant amount of compromised traffic for a high-traffic website. Similarly, if a name owner has messed up the configuration of a name, he will have to wait on average 10 minutes for his website to work again, which is a significant amount of downtime for a high-traffic website. Accepting unconfirmed name_update transactions would improve security and reduce downtime in such cases.

Usually, waiting for confirmations is used as a protection against double-spending. But in this case, that attack doesn't make any sense. A name owner has no motivation to double-spend his own name unless he's selling it non-atomically (a roughly useless use case), and in that case the value of the name is still not considered compromised (unless the recipient is stupid enough to point their end users at the transferred name before the transfer has been confirmed, which is also a roughly useless use case since it will have a value chosen by the original owner).

It could, maybe, be argued that forcing name_update operations to wait for a confirmation would increase the incentive to offer a high fee -- but I think requiring the name_update to meet relay requirements may be sufficient. If not, we could also watch previous blocks and enforce the fee based on those, using the same code that Bitcoin Core uses to guess good fees for our own transactions, e.g. require that an unmined name_update meet our predicted fee for being mined within 6 blocks. (1 block wouldn't work, because if that increases between blocks, then transactions created right before that block transition wouldn't be accepted.)

Tag a release candidate for 0.12

Bitcoin has already tagged 2 release candidates for the 0.12 branch; it would be great if we can tag an rc. Wang Chun from F2Pool inquired about this recently. Among other things, tagging a release candidate would be useful for testing the release process all the way through, and it would allow us to release Gitian binaries so that we can get more testers. A lot of people are still on either old 0.11.99 builds or 0.3.80 because we haven't put out newer binaries.

Test OSX Gitian descriptor

As far as I can tell, no one's tested the OSX Gitian descriptor. It needs the remote URL changed. Not sure what else.

failed test

Namecoin Core 0.11.99: src/test-suite.log

TOTAL: 2

PASS: 1

SKIP: 0

XFAIL: 0

FAIL: 1

XPASS: 0

ERROR: 0

.. contents:: :depth: 2

FAIL: qt/test/test_bitcoin-qt

********* Start testing of URITests *********
Config: Using QtTest library 5.4.2, Qt 5.4.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by Clang 6.1.0 (clang-602.0.53) (Apple))
PASS : URITests::initTestCase()
FAIL! : URITests::uriTests() 'GUIUtil::parseBitcoinURI(uri, &rv)' returned FALSE. ()
Loc: [qt/test/uritests.cpp(20)]
PASS : URITests::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted
********* Finished testing of URITests *********
********* Start testing of PaymentServerTests *********
Config: Using QtTest library 5.4.2, Qt 5.4.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by Clang 6.1.0 (clang-602.0.53) (Apple))
PASS : PaymentServerTests::initTestCase()
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::initNetManager: No active proxy server found.
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest: Secure payment request from "testmerchant.org"
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: Payment request: certificate expired or not yet active: QSslCertificate( "3" , "03" , "LxHILx+N3qwVoAcCmQ5cyw==" , () , ("Expired Test Merchant") , QMap() , QDateTime("2013-02-23 21:26:43.000 UTC Qt::UTC") , QDateTime("2013-02-24 21:26:43.000 UTC Qt::UTC") )
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest: Insecure payment request to "NACCXtKxpS66dzKujvjv4oPK1ES7H5ybnP"
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: Payment request: certificate expired or not yet active: QSslCertificate( "3" , "03" , "LxHILx+N3qwVoAcCmQ5cyw==" , () , ("Expired Test Merchant") , QMap() , QDateTime("2013-02-23 21:26:43.000 UTC Qt::UTC") , QDateTime("2013-02-24 21:26:43.000 UTC Qt::UTC") )
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest: Secure payment request from "testmerchant8.org"
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: Payment request: certificate expired or not yet active: QSslCertificate( "3" , "06" , "MiZaQ+g9lSHZGuHWkXZG+g==" , () , ("Payment Request Intermediate 5") , QMap() , QDateTime("2013-02-23 22:59:51.000 UTC Qt::UTC") , QDateTime("2013-02-24 22:59:51.000 UTC Qt::UTC") )
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest: Insecure payment request to "NACCXtKxpS66dzKujvjv4oPK1ES7H5ybnP"
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: Payment request: certificate expired or not yet active: QSslCertificate( "3" , "06" , "MiZaQ+g9lSHZGuHWkXZG+g==" , () , ("Payment Request Intermediate 5") , QMap() , QDateTime("2013-02-23 22:59:51.000 UTC Qt::UTC") , QDateTime("2013-02-24 22:59:51.000 UTC Qt::UTC") )
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: SSL error: certificate signature failure
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest: Insecure payment request to "NACCXtKxpS66dzKujvjv4oPK1ES7H5ybnP"
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: SSL error: certificate signature failure
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: SSL error: unable to get local issuer certificate
QDEBUG : PaymentServerTests::paymentServerTests() PaymentServer::processPaymentRequest: Insecure payment request to "NACCXtKxpS66dzKujvjv4oPK1ES7H5ybnP"
QWARN : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: SSL error: unable to get local issuer certificate
QWARN : PaymentServerTests::paymentServerTests() "PaymentServer::verifyNetwork: Payment request network "test" doesn't match client network "main"."
QWARN : PaymentServerTests::paymentServerTests() "PaymentServer::verifyExpired: Payment request expired "1970-01-01 00:00:01"."
QWARN : PaymentServerTests::paymentServerTests() "PaymentServer::verifyExpired: Payment request expired "1970-01-01 00:00:00"."
QWARN : PaymentServerTests::paymentServerTests() "PaymentServer::readPaymentRequestFromFile: Payment request /var/folders/kk/_xd1xzj90cj_0zz59yprzjrc0000gn/T/Bitcoin-Qt-test.M39831 is too large (50001 bytes, allowed 50000 bytes)."
QWARN : PaymentServerTests::paymentServerTests() "PaymentServer::verifyAmount: Payment request amount out of allowed range (2100000100000000, allowed 0 - 2100000000000000)."
PASS : PaymentServerTests::paymentServerTests()
PASS : PaymentServerTests::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted
********* Finished testing of PaymentServerTests *********
FAIL qt/test/test_bitcoin-qt (exit status: 1)

Reusing Bitcoin Core's Gitian dependency cache

According to @luke-jr (via IRC conversation during the OpenSSL Consensus Bug response) we can reuse Bitcoin Core's Gitian dependency cache if we keep certain strings in the Gitian script the same as Bitcoin. I'm not 100% sure which strings need to be kept the same. Is it just the name at https://github.com/namecoin/namecoin-core/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L2 ?

Rescue priority-related code from v0.11 to v0.12

Bitcoin Core v0.12 set default priority size to zero and simplified many priority calc-related code. This does not apply to Namecoin. We need to bring these removed code back.

Please start tagging releases.

Please start tagging releases. When compiling from source i con't know witch commit is considred stable or not.

regtest listen on same port as bitcoind

i run bitcoind and namecoid in regtest mode and they have same default
connect port (18444).

i propose change namecoind default port to 18445 or 18555.

RPC call for matching names by prefix.

name_filter's RegExp parsing is way overkill for the standard use case of prefix matching. I suggest adding a new RPC call that returns all names that match a specific prefix. The format should be similar to the output of name_filter.

namehistory / reindex parameter order

>namecoind -namehistory -reindex
Error: Error opening block database

>namecoind -reindex -namehistory

The second one worked. Is it possible the order of command line arguments matters?

undefined reference toCMerkleTx::ABANDON_HASH

Hi,

I downloaded the latest source codes from master branch and got compile error for a while.
./autogen.sh
./configure --disable-wallet --without-gui
make -j2

"libbitcoin_common.a(libbitcoin_common_a-auxpow.o): In function operator==': /home/jeppa/Downloads/git/namecoin-core/src/./uint256.h:45: undefined reference toCMerkleTx::ABANDON_HASH'
collect2: error: ld returned 1 exit status
make[2]: *** [namecoind] Error 1"

I have compiled BTC/LTC and other daemons without problems.
This is quite strange error.

How to migrate old wallets?

Old wallets from the previous versions on namecoin appear corrupted.
Is there a way to use the wallets or import the data?
See my question here

Make dust spam unspendable

Removing all 1 Satoshi outputs before block 50k would remove the majority of the dust-spam from the system.

Did the nc tags disappear?

GitHub isn't showing the "nc" tags for me (neither rc1 nor rc2). Did they inadvertently get removed somehow?

Compilation error

Got this error when compiling latest git on Ubuntu 64bit:

CXX libbitcoin_common_a-chainparams.o
chainparams.cpp: In constructor ‘CMainParams::CMainParams()’:
chainparams.cpp:130:76: error: expected ‘)’ before ‘;’ token
vSeeds.push_back(CDNSSeedData("domob.eu", "seed.namecoin.domob.eu");
^
In file included from chainparams.cpp:15:0:
chainparamsseeds.h: At global scope:
chainparamsseeds.h:10:18: warning: ‘pnSeed6_main’ defined but not used [-Wunused-variable]
static SeedSpec6 pnSeed6_main[] = {
^
chainparamsseeds.h:892:18: warning: ‘pnSeed6_test’ defined but not used [-Wunused-variable]
static SeedSpec6 pnSeed6_test[] = {
^
make[2]: *** [libbitcoin_common_a-chainparams.o] Error 1
make[2]: Leaving directory /home/rig/namecoin-core/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/rig/namecoin-core/src'
make: *** [all-recursive] Error 1
rig@rig:~/namecoin-core$

All previous compiled without issue using:

./configure --disable-tests --with-miniupnpc --without-gui

Boost dependencies nolonger availabe on ubuntu / apt-get

apt-get now serves boost 1.58 preventing namecoin installation.
1.58 can not be uninstalled without removing a host of dependent software

Maintain branches based on Bitcoin Core stable releases

Right now, someone who wants to test WIP Namecoin Core is also implicitly testing WIP Bitcoin Core. Would it be feasible to maintain a branch of Namecoin Core that contains all the latest auxpow and Namecoin commits but is based on a stable release of Bitcoin Core rather than the latest Bitcoin Core GitHub code?

Getting segfault when starting namecoind

Hi.

I'm getting a segfault when running namecoind.

Here is a gdb output: http://pastebin.com/yF4Zh4VX
Crash i get at startup: http://pastebin.com/mA8w3N8b

Hope this issue can be resolved as soon as possible :)

0.12 branch has wrong Linux Gitian descriptor version

The 0.12 branch's Linux Gitian descriptor name is version 0.10. https://github.com/namecoin/namecoin-core/blob/0.12/contrib/gitian-descriptors/gitian-linux.yml#L2 . It should be 0.12.

Is it okay if I submit a PR which fixes this in the 0.12 branch?

UI to renew multiple domains

I have multiple domains that I wish to renew but I'm unable to select multiple domains and click on the renew button. This forces me to pay the minimum fee for each domain.

Feature request: sendtoname

Currently this functionality can already be achieved by a combination of two RPCs (name_show and sendtoaddress). However, the sendtoname feature could become an important "unique selling proposition" in the future. Therefore sendtoname should be an RPC in its own right, I think.

testscript txn_clone.py fails

See https://travis-ci.org/namecoin/namecoin-core/jobs/117099590#L5578 for a log of the failure. It occurs on all Travis CI tests that utilize txn_clone.py, and appears to be the cause of all of our current Travis CI failures on the master branch. It doesn't happen on the auxpow branch, which suggests something Namecoin-specific is causing it. It also doesn't happen on the 0.12 branch.

Use an alert key that we control

As far as I can tell (maybe I'm wrong), Namecoin Core is using Vince's alert key, which we don't have control of. If that is correct, we should create a new alert key.

Release Process documentation is still for Bitcoin

The Release Process documentation still lists Bitcoin instructions. While these are easy to mentally convert to Namecoin instructions for people who are familiar with Gitian usage, I think it would be useful to explicitly change the relevant instructions to apply to Namecoin. I've already seen one person report issues because the documentation was unclear, and even for people who can mentally convert, I think decreasing cognitive load is a good thing.

Any objections if I submit a PR to fix this?

• master branch
• 0.12 branch

name_show and name_filter should fail by default if blockchain is incomplete

Outdated name data is dangerous because it could include TLS fingerprints that were later revoked, or even the wrong owner of a name, both of which could be exploited to cause a MITM. It's also confusing to users because some websites will work fine, while others will be mysteriously broken.

I propose that name_show and name_filter return an error by default if the blockchain is incomplete (still downloading), or if errors were encountered (e.g. "you may need to upgrade"). An optional parameter (disabled by default) could enable name lookups regardless of this condition.

See namecoin/namecoin-legacy#124 for history of this discussion.

Windows Gitian descriptor needs fixes

As far as I can tell, no one's tested the Windows Gitian descriptor. It needs the remote URL changed, for one thing. Not sure what else it needs. (Note: this ticket is for the master branch.)

Add develop branch and contributing.md?

Where should PR's go - master?

Could someone copy contributing.md from some similar project and add the guidelines to this repo?
(I see there are Developer Guidelines in readme.md, but those are from bitcoin, right?)

Several output binaries still named "bitcoin"

Steps to reproduce: Build Namecoin Core for Windows using Gitian. Extract the win64 zip file in Windows. Right click each .exe file in Windows Explorer, click Properties, go to the Details tab.

Expected results: All the outputted .exe files should have filenames and metadata associated with "namecoin", not "bitcoin".

Observed results:

1. bench_bitcoin.exe has the wrong filename.
2. test_bitcoin.exe has the wrong filename.
3. test_bitcoin-qt.exe has the wrong filename.
4. namecoin-cli.exe has the File description "namecoin-cli (JSON-RPC client for Bitcoin Core)".
5. namecoin-cli.exe has the Copyright "2009-2015 The Bitcoin Core Developers".
6. namecoind.exe has the Copyright "2009-2015 The Bitcoin Core Developers".
7. namecoin-qt.exe has the Copyright "2009-2015 The Bitcoin Core Developers".
8. namecoin-tx.exe has the Copyright "2009-2015 The Bitcoin Core Developers".

Note that right now Namecoin Core master branch doesn't build for Windows in Gitian; I will submit a PR for that soon. So, it may be difficult to reproduce this issue for Windows right now. I don't know if the same issues appear on Linux, OS X, or non-Gitian builds.

NSIS script in master branch has "bitcoin" in lots of places

The NSIS script in the master branch says "bitcoin" in lots of places, which breaks Windows Gitian builds. We already fixed it in our 0.12 branch, but are waiting for upstream Bitcoin to merge a fix for master branch.

GBT fails consistently after some time. CreateNewBlock: TestBlockValidity failed: (code 0)

$ namecoin-cli getblocktemplate
error code: -1
error message:
CreateNewBlock: TestBlockValidity failed: (code 0)

Getting lots of these in the debug log:
2015-12-23 06:35:18 CreateNewBlock(): total size 1246 txs: 1 fees: 500000 sigops 101
2015-12-23 06:35:18 ERROR: CheckNameTransaction: NAME_FIRSTUPDATE on an unexpired name
2015-12-23 06:35:18 ERROR: CheckInputs: tx invalid for Namecoin
2015-12-23 06:35:18 ERROR: ConnectBlock(): CheckInputs on fc56b9f2297a299cf59022317b50ba45ace9392932453eb027f3a77bf4c90bb1 failed with (code 0)

Value size limit

I think this issue must be well known, but I didn't see a bug for it.

Right now I understand values can be created up to 1023 bytes but updated only up to 520 bytes, which means if you create a value larger than 520 bytes you will be unable to keep it !

Perhaps documentation and code should be updated to reflect a hard maximum of 520 bytes for now.

I imagine it is technically possible to expand the bitcoin protocol in such a way that values larger than 520 bytes are allowed.

Port Namecoin-Qt 0.3.80 Manage Names tab to Namecoin Core

This issue is for figuring out what it would take to merge the Manage Names tab from the old Namecoin-Qt into Namecoin Core.

Relevant people:
@domob1812 maintains Namecoin Core and isn't fond of coding in Qt, so the code can't be a big burden for him.
@randy-waterhouse is potentially interested in funding a bounty for this. I'll let him describe details of the bounty amount, and the conditions for awarding the bounty.
@fsb4000 was awarded a bounty for GUI-related work a few months ago; I'm curious if you think you're qualified to work on this.

I think this is very important, because Bitcoin Core is one of the most active and secure Bitcoin clients, and it would be good to be able to reuse their GUI efforts as much as possible. At the same time, I don't want Domob to be bogged down in fixing Qt issues that he didn't volunteer for.

• master branch
• 0.12 branch

Change "namecore" to "namecoin-core" in Linux Gitian repo URL

https://github.com/namecoin/namecoin-core/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L20 probably needs a change.

Conflict with Bitcoin Core's '/usr/local/include/bitcoinconsensus.h`

There's another file which conflicts with Bitcoin Core.
This was built using master source dated Sep 7.

Selecting previously unselected package namecore.
(Reading database ... 147171 files and directories currently installed.)
Preparing to unpack namecore_0.11-1_armhf.deb ...
Unpacking namecore (0.11-1) ...
dpkg: error processing archive namecore_0.11-1_armhf.deb (--install):
 trying to overwrite '/usr/local/include/bitcoinconsensus.h', which is also in package bitcoin-0.11-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 namecore_0.11-1_armhf.deb

Crash bug reported by Eligius

[10:14:25] <wizkid057> Eligius namecoind crashed ~6 hours ago, nothing telling in debug log
[10:15:23] <wizkid057> by contrast the old version I had going had an uptime of over a year
[10:17:10] <wizkid057> actually, nm... it crashed again on restart
[10:17:16] <wizkid057> namecoind: /home/ubuntu/build/namecoin/depends/i686-pc-linux-gnu/include/boost/smart_ptr/shared_ptr.hpp:648: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = CReserveScript, typename boost::detail::sp_member_access<T>::type = CReserveScript*]: Assertion `px != 0' failed.
[10:17:44] <wizkid057> yep, wont restart now
[10:20:03] <Squidicuz> HEY! I am supposed to make a ticket about
[10:20:07] <Squidicuz> that
[10:20:09] <Squidicuz> .__.
[10:21:57] <Squidicuz> namecoind: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = CReserveScript; typename boost::detail::sp_member_access<T>::type = CReserveScript*]: Assertion `px != 0' failed.
[10:22:19] <wizkid057> pretty sure the wallet keypool is exhausted... testing that theory
[10:23:03] <Squidicuz> I am using p2pool, everytime the RPC from p2pool connects to namecore, I get that.  I compiled namecore with wallet disabled :s
[10:23:13] <Squidicuz> Does it need the wallet? :
[10:23:45] <wizkid057> most likely in that scenario
[10:24:06] <wizkid057> since you're generating coins they have to go somewhere, unless you have something else making templates for namecoin
[10:24:06] <Squidicuz> feck. okay
[10:25:34] <wizkid057> not sure why I never had this problem before.  it would just complain the keypool was exhausted or something previously, but wouldn't crash
[10:26:09] <Squidicuz> hmmph
[10:26:51] <wizkid057> that was with a version from like, 2 years ago though :)
[10:29:09] <Squidicuz> yeah, that was what I was using too.. upgraded and uhhh..
[11:26:10] <Squidicuz> wizkid057, yup that was my issue!  recompiled with wallet enabled, imagine that, it works now