Page 1 of 1

WDYT about soft fork to enable some Bitcoin features

Posted: Sat Apr 21, 2018 8:36 am
by domob
Recently, it is getting more and more delicate (and risky) to keep Namecoin on par with upstream Bitcoin code due to efforts that clean up soft-fork activations in Bitcoin that are not yet active in Namecoin - for instance,

We have been talking about the AAA hard fork for quite some time, but not progressed much (which I admit is likely due to me not having much time for it in the last year or so). To make things easier, I propose to instead just do a planned soft fork (activated at a fixed block height) to enable BIP16, Segwit and other things that have since activated on Bitcoin. This reduces the differences to upstream code we have to maintain, and also removes the risk of accidentally forking if I miss to disable certain things when merging upstream code. Since this will be a simple soft fork, it will be much easier to perform than the AAA hard fork.

WDYT about this? Is anyone in contact with miners to gauge how easy it would be for us to have them update their client? What versions of Namecoin are actually run on the network in general and by miners specifically?

Re: WDYT about soft fork to enable some Bitcoin features

Posted: Sat Apr 21, 2018 8:37 am
by domob
Also, just to be clear: I do not propose to cancel the AAA idea. I think we should do this "simple" soft fork as soon as possible to remove issues with forks activated now on Bitcoin already, but we should still work on AAA and land it at a later point in time (6 months to a year after the soft fork?).

Re: WDYT about soft fork to enable some Bitcoin features

Posted: Sun Apr 22, 2018 8:26 pm
by biolizard89
One of the reasons for AAA being delayed is that it's blocked by getting the name tab GUI merged to master branch (since activating AAA will break nc0.13.99-name-tab-beta1 clients). This is not as big a deal for a softfork, since we only need an economically significant subset of users to upgrade (and that means that exchanges and registrars are probably sufficient, and neither of those groups care about the Qt GUI). However, I would be opposed to doing a softfork with *only* miner support, because 2 of the consensus changes involved (P2SH and SegWit) involve repurposing scriptPubKeys that are currently anyone-can-spend (which means that if the miners are the only ones enforcing the new rules, the miners could easily choose to steal coins).

Something that would be productive would be to compile a list (possibly in the Jekyll site) of infrastructure entities who need to be notified of impending protocol upgrades. The Exchanges and Explorers list on the Jekyll site seems to handle this pretty well for that group, but it would be beneficial to cover other entities like mining pools, registrars, inproxies (like OpenNIC) and analytic websites (things like CoinMarketCap,,, etc.). It would be important for any such list to make it clear that the inproxy and registrar lists are explicitly not recommended for end users (at least until a registrar model appears that's not a web wallet). Once we have such a list, it would be straightforward to check with all of those entities and make sure that they're prepared to upgrade.

It would also be productive to create a free software tool for checking node count by version on the public P2P network. I think BitInfoCharts has a proprietary SaaSS implementation of this, and I assume there are free implementations of that for Bitcoin that we could easily port to Namecoin. Maybe Peter Conrad and Mark Polyakov already have this info via their DNS seeds...?

Other thought: IIRC, Viacoin modified VersionBits to work properly with AuxPoW (basically they right-shift the bits that enable VersionBits by 24 bits, so they end up with a much smaller number of simultaneous softforks that are possible but they don't collide with the AuxPoW-reserved bits). From my understanding, their approach is pretty easy to apply and isn't very invasive to the VersionBits code in Bitcoin Core. Might be worth considering using their approach (or merging their code after reviewing it) as a short-term stopgap until AAA is ready, since I suspect that would reduce our patchset against Bitcoin Core compared to scheduling flag-day softforks for things like CSV and SegWit that were designed to be activated by VersionBits.

In any event, I'm not likely to have time to spend on the logistical end of this until my master's thesis defense is done (it's scheduled for May 3). Anyone else is welcome to pick up some of these things if there's agreement that they're useful.

Re: WDYT about soft fork to enable some Bitcoin features

Posted: Mon Apr 23, 2018 5:17 pm
by domob
Yes, I agree, we should have support not only by miners (but those are definitely a technical hard requirement for any soft fork). Perhaps also Cassini has some insight, he did some analysis on the network in the past, IIRC.

Doing what you describe (shifting the version bits like Viacoin) is certainly an alternative, but I think a height-based activation is even simpler. In fact, I've already implemented that experimentally (not activated in Namecoin) in ... c44ce0ac2c. The code changes are very simple, and the main changes are to regtests (because many assume that segwit is always on). With Bitcoin's efforts to back-date segwit, the differences will become even less in the future as things are cleaned up (after we activate segwit). So I'd prefer to go with this for now and enable BIP9 through AAA at a later stage.

Re: WDYT about soft fork to enable some Bitcoin features

Posted: Mon May 07, 2018 3:05 am
by samurai321
i think the idea of domob of introducing a height-based activation, now, is okay since it will break the name-tab in the future, not now, and gives time to miners to update.

so as long as it's programmed with enough time for the name-tab gui to be fixed, in a future release for users, is fine, because the main objective here is make the important consensus code easyer to maintain. new name-tab could be introduced at any time in a new version without problem.

in general the sooner this things are planned on the forum, programmed into the code and the more time is given for activation (activate in 50000 blocks for example) the better. imho.

miners need time to update and don't want to update often. so a series of softforks, programmed beforehand, is better than the uncertainty of, "when will miners activate x feature?" and " how long we will have to wait for them to even update ". with planned, height-based activated, of features already in use in bitcoin, they have a deadline to update namecoin to speak off.

Re: WDYT about soft fork to enable some Bitcoin features

Posted: Wed Jun 06, 2018 4:03 am
by biolizard89

Have the following things already been thoroughly verified?
  1. P2SH rules are enforced properly for name outputs after the fork?
  2. Recognition of whether a P2SH output is a name output is unchanged before and after the fork?
  3. (1) and (2) for P2SH-wrapped SegWit outputs?
  4. (1) and (2) for pure SegWit outputs?
  5. (1) and (2) for arbitrarily higher-versioned script outputs (since SegWit enables script versioning)?

Re: WDYT about soft fork to enable some Bitcoin features

Posted: Wed Jun 06, 2018 10:44 am
by domob
For P2SH, we already have a regtest since a long time ago - I don't recall off-hand what exactly it verifies, but names certainly do work with P2SH (feel free to take a look yourself at the test to see if there's anything more you'd like to test).

Segwit should work as well from looking at the code, but I don't think I've ever tested that so far.