BIP34 and BIP66 activated

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: BIP34 and BIP66 activated

Post by biolizard89 »

flound1129 wrote:You may also want to set the title for the Namecore repository to "Namecoin Core", and/or move it into the Namecoin repository, so that it's the first result when searching "Namecoin core".

Currently, the first result for "Namecoin core" is the old repository and the second result (domob1812/namecore) which is the real repository does not give any indication that it is official.
Thanks for feedback. I've added a note to the top of this thread.

The official Namecoin Core repo is namecoin/namecore. We will probably rename it to namecoin/namecoin-core shortly, for the SEO reasons that you listed. domob1812/namecore is Daniel's personal repo, which gets updates a bit before namecoin/namecore does, but has had less testing.

Thanks again for the feedback -- I wish this transition had been a bit smoother. I'll let Daniel answer your question about renaming _target, as I don't know myself what that might affect.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BIP34 and BIP66 activated

Post by domob »

biolizard89 wrote:Thanks again for the feedback -- I wish this transition had been a bit smoother. I'll let Daniel answer your question about renaming _target, as I don't know myself what that might affect.
The decision to change "target" to "_target" was made in discussion with F2Pool. The reason is that the field is, in fact, a legacy one. It is not the same as "target" of "getblocktemplate", as it has the byte-order reversed. To highlight this, we decided to rename the field. Everything else is highly inconsistent. Code should ideally use the "bits" field to determine the target.

I understand that this causes issues with legacy mining software, but I believe that the reason given above is much stronger. It is easy to work around the mining incompatibilities, by either making the mining system look for both "target" and "_target" (or, ideally, interpret "bits" directly), or by patching the Namecoin code if you are sure you want the legacy behaviour.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

flound1129
Posts: 7
Joined: Wed Sep 16, 2015 6:21 am
os: linux

Re: BIP34 and BIP66 activated

Post by flound1129 »

domob wrote:
biolizard89 wrote:Thanks again for the feedback -- I wish this transition had been a bit smoother. I'll let Daniel answer your question about renaming _target, as I don't know myself what that might affect.
The decision to change "target" to "_target" was made in discussion with F2Pool. The reason is that the field is, in fact, a legacy one. It is not the same as "target" of "getblocktemplate", as it has the byte-order reversed. To highlight this, we decided to rename the field. Everything else is highly inconsistent. Code should ideally use the "bits" field to determine the target.
OK, but why was the byte order reversed? Why not just keep everything compatible?

flound1129
Posts: 7
Joined: Wed Sep 16, 2015 6:21 am
os: linux

Re: BIP34 and BIP66 activated

Post by flound1129 »

biolizard89 wrote:
flound1129 wrote:You may also want to set the title for the Namecore repository to "Namecoin Core", and/or move it into the Namecoin repository, so that it's the first result when searching "Namecoin core".

Currently, the first result for "Namecoin core" is the old repository and the second result (domob1812/namecore) which is the real repository does not give any indication that it is official.
Thanks for feedback. I've added a note to the top of this thread.

The official Namecoin Core repo is namecoin/namecore. We will probably rename it to namecoin/namecoin-core shortly, for the SEO reasons that you listed. domob1812/namecore is Daniel's personal repo, which gets updates a bit before namecoin/namecore does, but has had less testing.

Thanks again for the feedback -- I wish this transition had been a bit smoother. I'll let Daniel answer your question about renaming _target, as I don't know myself what that might affect.
Thanks! So the code in that repository is stable and supported? It doesn't appear that there have been any releases made.

If not, is there a patch available that will bring the old version in line with the referenced BIPs?

flound1129
Posts: 7
Joined: Wed Sep 16, 2015 6:21 am
os: linux

Re: BIP34 and BIP66 activated

Post by flound1129 »

Also why was rpcssl support removed? And recommended to replace with a self signed certificate? This hardly increases security, and in many cases decreases it.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: BIP34 and BIP66 activated

Post by biolizard89 »

I'm guessing that the byte order disparity was Vince's doing (he founded Namecoin in 2011). Given that he retired many years ago, I doubt anyone knows why he made it that way. Maybe Daniel knows more.

The code in https://github.com/namecoin/namecoin-core is as stable/supported as you can get for mining purposes. We will hopefully make formal releases fairly soon. The old codebase will not be brought in line with those BIP's, so it is not usable for mining (and for general use it has semi-SPV security since it doesn't validate those BIP rules for blocks).

rpcssl was removed by Bitcoin Core upstream. I think this is (1) because they want to remove the dependency on OpenSSL, and (2) because the RPC port shouldn't be exposed to untrusted networks anyway (because it's trivial to DoS it). While this makes me a bit sad, there is nothing we can do about it, since we follow Bitcoin upstream on such things. Complain to the Bitcoin Core developers about it if you dislike that decision.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: BIP34 and BIP66 activated

Post by biolizard89 »

@flound1129, I never heard the conclusion to this; were you able to get Namecoin Core working properly on your pool? Is there anything you need assistance with?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

johnc
Posts: 89
Joined: Sun Dec 28, 2014 10:03 am

Re: BIP34 and BIP66 activated

Post by johnc »

flound1129 wrote: OK, but why was the byte order reversed? Why not just keep everything compatible?
I'm not really sure, but i think that this "target" was a legacy from bitcoin, since namecoin uses merged mining, it does not check the difficulty with this field but by checking if the aux-proof of work (from a bitcoin block) meets the target. So it may have been reversed to highlight that this value doesn't matter or doesn't have the same importance than in bitcoin mining and it just stores a hash in case you try to mine Namecoin alone.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: BIP34 and BIP66 activated

Post by biolizard89 »

johnc wrote:
flound1129 wrote: OK, but why was the byte order reversed? Why not just keep everything compatible?
I'm not really sure, but i think that this "target" was a legacy from bitcoin, since namecoin uses merged mining, it does not check the difficulty with this field but by checking if the aux-proof of work (from a bitcoin block) meets the target. So it may have been reversed to highlight that this value doesn't matter or doesn't have the same importance than in bitcoin mining and it just stores a hash in case you try to mine Namecoin alone.
AFAIK we're not talking about getblocktemplate, but rather getauxblock. getauxblock is not a legacy from Bitcoin; it doesn't exist in Bitcoin. I believe that getblocktemplate's target in Namecoin is the same format as Bitcoin's (but there's no reason to use it).
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BIP34 and BIP66 activated

Post by domob »

biolizard89 wrote:
johnc wrote:
flound1129 wrote: OK, but why was the byte order reversed? Why not just keep everything compatible?
I'm not really sure, but i think that this "target" was a legacy from bitcoin, since namecoin uses merged mining, it does not check the difficulty with this field but by checking if the aux-proof of work (from a bitcoin block) meets the target. So it may have been reversed to highlight that this value doesn't matter or doesn't have the same importance than in bitcoin mining and it just stores a hash in case you try to mine Namecoin alone.
AFAIK we're not talking about getblocktemplate, but rather getauxblock. getauxblock is not a legacy from Bitcoin; it doesn't exist in Bitcoin. I believe that getblocktemplate's target in Namecoin is the same format as Bitcoin's (but there's no reason to use it).
The byte order in "getauxblock" is reversed for what I believe are simply legacy reasons; I don't really know why that was done. "getblocktemplate" is, indeed, the same as Bitcoin's - and that's one of the reasons why we decided to rename the "target" field of getauxblock to "_target", since it is precisely not the same as the target field of getblocktemplate.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

Post Reply