Couple of Issues - Githubissues

lurchinms commented 4 years ago

First Master will not build using db4.8, but will build on db5.3. Second Master dnsseed out of date, because no Nodes are loaded in order for the coin to sync.

BioMike commented 4 years ago

Thank you for your feedback.

Auroracoin switched to db5.3 a few years ago. It is adviced to use that version. You can still build against db4.8 by passing --with-incompatible-bdb to configure, when starting fresh with auroracoin.
Only the electrum1 seed is offline, the three others (electrum2, electrum3 and electrum4) should be working (don't have IPv6 though). Both the names and ip adresses are mentioned on the aurarad/Auroracoin github wiki. Could you try to connect manually to them and see if it starts syncing?

BioMike commented 4 years ago

Regarding point 1, I've changed the documentation to reflect this difference against other coins and updated the configure message to let people know it is looking for Berkeley DB 5.3 instead of only telling when it fails.

lurchinms commented 4 years ago

Thank You

On Jul 6, 2020, at 2:56 AM, Myckel Habets notifications@github.com wrote:

Regarding point 1, I've changed the documentation to reflect this difference against other coins and updated the configure message to let people know it is looking for Berkeley DB 5.3 instead of only telling when it fails.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aurarad/Auroracoin/issues/29#issuecomment-654078395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5JIUKQY6GKP64F7T2PCN3R2F7UFANCNFSM4OQHPMWQ.

lurchinms commented 4 years ago

I have it installed and synced. Will test it this evening. https://kriptokyng.com

Ron Lonnborg Jr. lurchinms@gmail.com (228) 234-4811 KriptoKyng.com Gulfport, MS.

On Jul 6, 2020, at 6:11 AM, Ronnie Lonnborg lurchinms@gmail.com wrote:

Thank You

On Jul 6, 2020, at 2:56 AM, Myckel Habets notifications@github.com wrote:

Regarding point 1, I've changed the documentation to reflect this difference against other coins and updated the configure message to let people know it is looking for Berkeley DB 5.3 instead of only telling when it fails.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

laakie commented 4 years ago

one more issue,

The version numbers in the wallet are displayed different at different places. Example: Version from getinfo() returns : 2018090100 Version from getpeers() returns : 2018.09.1.0 Version at git : 2018.9.1

We use the version numbers to detect updates, So it's key that we can compare them with each other :)

Not sure how much work it is to change, but if possible we'd like to see one interpretation.

BioMike commented 4 years ago

I'll have a look at it when I get back to coding. Probably somewhere in the next two weeks.

BioMike commented 4 years ago

Let's see how bitcoin handles versions in its rpc calls: getpeerinfo: "version": 70015, "subver": "/Satoshi:0.20.0/", getnetworkinfo: "version": 200100, "subversion": "/Satoshi:0.20.1/", Version at Git: 0.20.1

How auroracoin handles this: getpeerinfo: "version": 3000000, "subver": "/Gubrandur orlksson:2018.9.1/", getnetworkinfo: "version": 2020070100, "subversion": "/Árni Magnússon:2020.7.1/", version at Git: 2018.09.1.0

Taken together let's see how we could change things to suit your situation:

Version from getinfo() returns : 2018090100 getinfo is removed from the new wallet, the thing closest is getnetworkinfo, but both "version" and "subversion" return the version of the running wallet and isn't suited for detecting new versions on the network.
Version from getpeers() returns : 2018.09.1.0 Changes into the getpeerinfo call. This gives the network versions the client runs (3000000 in the old wallets and 2020070100 (updated to the new version release) in the upcoming wallet), while we move to a more release-centric version numbering there is no guarantee that will skip updating this in the future. The code uses this number to determine the services a wallet supports and should not be used for determining new releases. The "subversion" field could however be used to determine new versions as this reflects the client's User Agent string. This is the same as "subver" in getnetworkinfo.
Version at git : 2018.9.1 It is "2018.09.1.0" not "2018.9.1". The git version is the best way to determine if a new version is released. It has the form of yyyy.mm.r.l Where: yyyy is the year of the release mm is the two-digit month of the release r is the release number l is the minor release number, normally 0 unless we need to make a urgent patch release.

So, suggestions for improvement: getpeerinfo needs to return the full version number in "subver", the "mm" and "l" part are wrong. If that's fixed you can check this field in the same way as bitcoin (split the string at ':' and use the latter part in combination with the git version).

Would this suit your situation?

BioMike commented 4 years ago

Oops one mistake. In the new wallet "version" in getpeerinfo will be "protocolversion" in getnetworkinfo. This will be in the format: 3020191 (which is 30yyyyr).

BioMike commented 3 years ago

New release that cointains above fix. Closing

aurarad / Auroracoin

Couple of Issues #29