[00:05:29] https://github.com/navcoin/navcoin-core/pull/530 [00:05:38] updated the pull request with a quasi-extensive description of the changes [02:38:36] im re-running my gitian builds today [05:39:30] @prole [05:39:39] I've posted my hashes for 4.7.0 branch [05:39:53] @aguycalled I've skimed your PR [05:40:13] Its alot of changes and large description, so might take a while to review, LOL [08:23:25] im just building the windows ones now and then i can check the hashes [08:23:37] my locally built osx still hangs when i try to quit [08:23:44] im going to check the gitian built one [08:34:11] so.... [08:34:23] local build the menu's are fine, but my gitian output stil makes them fuckin pink [08:34:48] but the gitian build shuts down with no deadlock [08:34:59] so 😅 [08:35:05] i dont know whats going on tbh [08:35:13] im building locally using the depends folder [08:40:54] i assume the gitian build is using the same depends, so i dont know how they can end up with different problems [08:41:24] im going to try syncing from the beginning with the gitian build and see if i can get any more info about that rejected community fund block [08:41:31] we really need to resolve that before the release is published [08:41:48] have you guys had any clues or thoughts abbout it? @developer [08:44:35] Yes, gitan builds using depends [08:44:44] But it uses clang 3.x I think [08:44:48] Not the system clang [08:45:02] Which your native build I think uses [08:45:06] Not sure though [09:21:03] @aguycalled Thanks, but not sure how to get anything definitive of the script. Been looking through the table on https://en.bitcoin.it/wiki/List_of_address_prefixes. Bitcoin’s is 128 and says K or L, which doesn’t match the decimal prefix of 128 in the table that there says t. [09:23:30] @anquii what path standard is that lib using? [09:24:08] If it's BIP44, then you should refer to this: https://github.com/satoshilabs/slips/blob/master/slip-0044.md [09:24:50] You are using that lib to build a key pair right? [09:26:09] I think it is. But I’m just trying to understand the correct regex for Nav’s compressed and uncompressed private key. [09:26:12] https://github.com/essentiaone/HDWallet/blob/develop/HDWalletKit/Wallet/UTXOBased/UtxoPrivateKeyType.swift [09:26:49] If you want to validate the address format, maybe check out the logic in validateaddress CLI command in navcoin-core [09:28:42] Try taking a look at this: https://github.com/navcoin/navcoin-core/blob/master/src/rpc/misc.cpp#L178 [09:31:46] That’s just validating an address it seems. [09:32:01] Needs to be the private key itself. [09:32:44] Ohh [09:33:04] What exactly do you need to accomplish? [09:33:12] I'm assuming creating a new key? [09:35:57] Just need to fill out the regex for a compressed and uncompressed private key relative to the link above. E.g the compressed I assume to be [P][1-9A-HJ-NP-Za-km-z]{51}. [09:37:00] I'm not sure, as I've never tried to validate an address by regex [09:37:25] I've only tried it with validating the range (Since the keys can be solved mathematically) [09:38:07] IE, checking the prefix [09:38:11] Then the data size [09:38:22] Like this: cpp bool CNavCoinAddress::IsValid(const CChainParams& params) const { if (vchVersion == params.Base58Prefix(CChainParams::COLDSTAKING_ADDRESS)) return vchData.size() == 40; bool fCorrectSize = vchData.size() == 20; bool fKnownVersion = vchVersion == params.Base58Prefix(CChainParams::PUBKEY_ADDRESS) || vchVersion == params.Base58Prefix(CChainParams::SCRIPT_ADDRESS); return [09:38:22] fCorrectSize && fKnownVersion; } [09:39:35] IE, in this sample, it's checking for a 40 size if it's a coldstakng address, and checking for 20 size if it's a PUB or SCRIPT address [09:39:40] Right I see. Need the regex though in this case as that’s how the HDWallet lib does it. [09:40:02] Gotcha, I can't really help as I've never done it before [09:40:06] Was looking through this https://en.bitcoin.it/wiki/List_of_address_prefixes [09:40:46] Well, Nav uses 53 (decimal) [09:40:53] 0x35 Hex (Not sure) [09:40:59] So that would a N [09:41:00] Prefix [09:41:07] For a pub address [09:41:37] Yeah for an address, but the private key always starts with P right? [09:41:46] Not sure [09:41:56] I've not done much reading on the private key [09:43:32] I think for NAV private keys start with P [09:43:40] Not sure if it can be something else [09:44:06] I was trying to compare with BTC, but don’t understand how 128 decimal prefix (where NAV is 150) equals K or L as leading symbols. Because looking through the table, K or L is defined by decimal prefix 47. [09:45:44] Not sure what the difference between decimal prefix and decimal version is. [09:46:35] I think that table is referring to the public key prefix generated with that prefix value [09:46:39] IE 53 = N [09:46:52] 0 = 1 [09:47:30] But for the private key, I'm not sure how the prefix is determined [09:49:09] Not sure because 47 = K or L. [09:49:20] Which is what BTC uses. [09:51:00] the prefix for uncompressed is 6 as per the example i pasted [09:51:25] # node d Compressed WIF: PHKgVuuFpLZWk9enq5LRCKgtZ7C4bRYoofanq63vjS6NnxwpC7iC Address: NUZ8ETGvwzSYvYNMtAHHxB6mbHkJpDdX3s Uncompressed WIF: 63nvMbeDRKUktvAU9dKu9uifR3JuvZkTTtLSLWEocSd7JHT5TSj Address: NcEoWDA5p27zUFUav5C8DBcGwEtLYvpGkA [09:51:48] Yes, it’s more the characters following that I’m concerned about. [09:52:04] its base58 [09:52:19] same charset [09:52:29] just different prefix [09:52:36] Btc has 5^[HJK] e.g [09:53:11] Yeah, but the first character after the prefix is a specific one for BTC. Either H, J or K. [09:53:54] you can use the script i pasted and generate many keys to see the different possibilities [09:54:04] anyway that format is not used anymore [09:54:09] (uncompressed) [09:54:16] you are not going to find it on the wild [09:54:35] Hm okay, so their lib is outdated for BTC? [09:55:06] https://github.com/essentiaone/HDWallet/blob/develop/HDWalletKit/Wallet/UTXOBased/UtxoPrivateKeyType.swift [09:55:23] They’re currently validating BTC by that format. [10:02:00] its valid but not used in the practice [12:27:38] @prole I merged PR 511 [12:27:49] And test suite for master ran in 11 minutes [12:28:00] Instead of the usual 30 minutes