[16:56:17] @aguycalled I'm testing your PR for cfunddb right now [16:56:25] Looks good so far [16:56:42] This PR breaks backward compatibility with the old versions right? [16:57:09] IE, if you use newer wallet with older DBs, it will upgrade the DB (Merge the coins and cfund DBs) [16:57:44] IE, if you use this version to create a bootstrap (IE the bootstrap server), the bootstrap will not work with older wallets? [17:46:50] yep [17:56:33] ACK [17:56:41] I will test upgrade scenario then 😄 [17:56:58] BTW, you think there would be any benefits to updating to BDB 5.x? [17:57:20] I see that upstream btc core is still on 4.x (Could there be a reason)? [18:35:14] yes its for wallet backwards compatibility [18:35:48] coinsbd uses leveldb [18:35:52] bdb is only used for the wallet [20:01:08] I see [20:02:11] BTW, is there a reason why the wallet is still saved in bdb? can't we use something like JSON for mnemonic keys? [20:02:28] I mean, we only really need the master key right? [20:03:00] And it can be saved in JSON as an encrypted value that represents the key (Since we added mnemonic support) [20:03:29] And other data in wallet.dat (Like tx and addresses) can be stored in a db still. [20:03:52] Sorta like a cache that can be cleared or re created by a rescan of the chain [20:04:08] the tx are also saved, and different keys derived from the master [20:04:24] so it does not have to go through all the process every run [20:04:38] sorry wrote before ur last sentences [20:04:42] 😄 [20:05:23] everything can be done sure, the thing is to value if it brings more than it breaks (backwards compatibility) [20:05:34] Yeah [20:05:40] That is the big question [20:06:18] I guess ideas like these are best put in a wishlist for a new FULL node codebase that is more modern [20:06:29] One that has all the features that the current core has [20:06:50] But is coded fresh with new tools and a cleaner base [20:07:01] But I guess that is what NEXT is for... [20:07:11] IDK, just talking ideas, haha 😄 [20:17:16] next is just lite wallet [20:17:20] no full node functionality [20:21:18] I meant how it has navcoin-core running for staking [20:22:09] @aguycalled On another note, if you were to code a full node from scratch, what tech stack would you use? [20:22:57] its been years i dont do anything different from c++ [20:23:13] for big projects, i mean [20:23:33] i've started learning go, but did not keep on [20:23:40] Well, a new full node could still use c++ [20:23:53] But I'm talking about the db, libs and build system [20:24:09] i'm not sure i can properly answer that question without dedicating more time on finding an answer [20:24:23] Like ninja is a really nice build system (I think has a few features worth using) [20:24:27] Yeah, I hear yeah [20:24:35] havent thought about it, it would be randomish answer [20:25:13] I was also wondering if we could somehow lower/lessen the resource requirements for the nodes [20:25:21] But I can't really think of a way to do it [20:25:36] Would be beneficial for something like a node renting service or a staking pool [20:25:57] As it stands now , navcoind needs 1.5GB to run a full node right? [20:26:04] That's like the minimum [20:26:43] I think that was why @prole was having issues running a node on 1GB VPS [20:26:44] its been 2 years working on nothing but navcoin-core so no idea of what are the alternatives currently out of what we use [20:27:18] that's because the whole block index is loaded on memory on startup [20:27:33] see LoadBlockIndexGuts() [20:27:39] Hmmm [20:27:52] Is that something we inherited from btc core code? [20:27:57] yes [20:28:15] I wonder if they have optimized anything in that [20:28:28] I'll investigate [20:28:32] i don't think its a matter of using other libs but how everything is architected [20:28:44] Yeah, might be [20:29:55] their block time is 10min [20:30:11] so they only have 1 header for every 20 of navcoin [20:30:18] Hmmm [20:30:33] Good point [20:30:52] also we store a few extra things in the header structure [20:31:04] probably we can clean it as most things come from very old pos implementations [20:31:44] for example, nNonce [20:31:53] should be completely removed [20:32:00] proof of stake does not need it [20:32:58] but anyway our proof of stake needs to be redesigned [20:33:06] its "broken" [20:36:26] if you are interested in knowing more: http://fc19.ifca.ai/preproceedings/180-preproceedings.pdf https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806 [20:38:19] besides what is documented there, reorganizations is another thing i'm not happy about how it works [20:39:00] How big of an issue is the "Fake Stake" attack? [20:44:11] it is half-patched so the attack is kind of mitigated [20:45:43] but as the article says, every pos based on bitcoin using utxos is affected [20:45:50] its a design problem [20:52:45] Hmmm, I'm still reading up on the article [20:52:55] Alot of this info is still foreign to me [20:53:07] I've got alot of catching up todo [22:03:16] ' its "broken" ' I read about the attack but as far I understand its just a RAM attack to kill a node. And blockchain reorganizations should not be possible with the verify of the block hash in the source code? [22:12:09] @aguycalled Do I have to scan the entire wallet pwalletMain->mapWallet to get the oldest stake? Or do we have a util function or other code that already does this?