Welcome!

Disclaimer: This proposal is individual in nature and is not brought forward by Dash Core Group

I'm Kittywhiskers Van Gogh (kwvg on GitHub, kittywhiskers on Keybase), I've been contributing to Dash Core since Dec, 2020 (my first pull request!), contributed through the Dash Incubator program since Jan, 2021 (pull request, Incubator claim) before transitioning to a role within Dash Core Group effective Apr, 2022.

Since then, except for a brief period between Oct, 2023 and Jan, 2024, I have contributed to Dash Core in full-time capacity and in about a month, it'll be close to 4 years of contributing, in varying capacities, at least 253 merged pull requests (source) totaling ~1900 commits(1)

What do I do?

I filled the role of C++ Software Engineer in the Core team. My responsibility was, beyond routine backports, implementing features needed in Dash Core sooner than sequential backports would allow. This would often be the case for features needed to support new platforms like Apple Silicon, migrating away from legacy code, upstream deprecation or backporting features that Dash Core would benefit from having sooner.

What did I do, specifically?

Below are a list of feature milestones that I have contributed to. This is not an exhaustive list of all efforts needed to reach the mentioned milestones as it does not include contributions made by my peers and coworkers (without whom, some of these milestones wouldn't have been possible).

• Assume UTXO Support (work in progress)
  
  • Why?
    • UTXO set assumption is a bootstrapping method that allows nodes to run validating nodes while consuming less storage by fetching or supplying a serialized UTXO set and validating blocks after the set's creation in exchange for placing initial trust in the supplied set (which is offset by background validation and a hardcoded AssumeUTXO hash).
    • This would allow constrained parties to contribute to the network by reducing the resource burden required to bootstrap, in comparison to syncing the chain from scratch.
  • How?
    • General deglobalization (#4756, #4801, #4844, #4864)
    • Deglobalization of Dash entities (#4931, #4930, #4988, #5030, #5058, #5337, #5555, #5871, #5908, #5929, #5933, #5940, #5966, #5980)
    • Deglobalization of chainstate (#5235, #5531, #6078)
    • Assume UTXO backports (#4498, #4703, #5246, #5236, #5492, #5501, #6085)

• Migrating to C++20 (work in progress)
  
  • Why?
    • Bitcoin migrates to CMake in Aug 2024 (bitcoin#30454), slated for v29, dropping GNU Autotools as their build system. The benefits of this migration include better IDE integration, being able to build it using any of CMake's generators (Ninja, MSVC, Xcode), which in turn allow access to better analysis tools that should improve development ergonomics.
    • The migration is also done to aid in preparation for migrating to Qt 6 as Qt 5.15 reached EoS in May 2023 (source).
    • In order to begin this transition, our Autotools-based build system, toolchain, depends and build environments need to be on-par with pre-transition upstream before making the switch. Migrating to C++20 is the first step to prepare for that transition.
  • How?
    • Priming C++20 support (#6377, #6379, #6387, #6382, #6383, #6384, #6385, #6389)

• Implementation of BIP-324/P2Pv2 (in testing)
  
• Why?
  • BIP 324 is a proposal that implements opportunistic encryption of P2P traffic meant to frustrate passive eavesdropping, MiTM tampering and traffic analysis without having to resort to using overlay protocols like Tor or I2P, which come with overhead or tunneling protocols, which limit node discoverability.
  • As LLMQs and CoinJoin have greater P2P involvement and affect consensus/functionality, measures to protect communication integrity, especially on clearnet, where the vast majority of nodes reside, are valuable.
• How?
• Primitives (#5575, #5873, #5902)
• Moving application layer to net processing (#4891, #5168, #5352, #5952, #5964, #5977, #5982)
• Preparation work (#4323, #6004, #6007, #6067, #6289, #6276)
• Implementation (#6280, #6324, #6329, #6330)

• Implementation support for TorV3 (completed)
  
• Why?
  • The Tor Project signaled deprecation of v2 onion services in Sept 2020 and disabled it from the client in Oct 2021. v2 services are considered insecure due to their usage of RSA 1024 and truncated SHA 1 on top of the directory system that leaked information to HSDir relays (source).
• How?
• Preparation work (#4028, #4035, #4036, #4037, #4164, #4166)
• Implementation (#4181)

• Improved Mac support (completed)
  
• Why?
  
  • It was observed on Apple Silicon Macs that wallet tests performed significantly worse on them compared to AMD64-based systems despite being at parity or exceeding the latter in performance benchmarks. Compared to upstream, this regression in performance was reproduced unless the tests were run on SQLite-based wallets.
    SQLite-only builds displayed no performance disparity AMD64 and Apple Silicon-based systems.
    
• How?
  
• Implementing SQLite wallets
• Preparation work (#4735)
• Refactoring Berkeley DB logic (#4714, #4765, #4919)
• Implementation (#5072, #5198)

• Migrating away from Gitian to Guix (completed)
  
• Why?
  • Gitian was deprecated in 2021 as Bitcoin migrated to Guix (source). As the project was no longer being actively maintained, work on Guix migration started. It comes with the benefit of not being a virtualization-based solution and cache-able.
• How?
• Preparation work (#5120, #5372)
• Guix backports (#5355, #5408, #5426)
• Later work (#5448, #5449, #5464)

• Implementing support for I2P and CJDNS (completed)
  
• Why?
  • While you can run nodes "dumb" (i.e. without knowledge of an overlay network through, for example, a SOCKS5 proxy), it restricts their ability to be full-fledged participants in the network as some details about peers would be abstracted away by the proxy while all traffic, meant for clearnet or the overlay network, would go through the proxy.
  • Implementing support for I2P and CJDNS makes the client cognizant of these networks, classifying them separately, communicating with overlay-specific agents (like I2P SAM) and using peer-protection logic to ensure that nodes that serve as a bridge between clearnet and the overlay network hold onto overlay nodes even if better clearnet nodes are available.
• How?
• Preparation work (#5306, #5329, #5978, #6034)
• I2P Implementation (#5491, #6035)
• CJDNS Implementation (#6031)

• Reducing reliance on Boost (completed)
  
  • Why?
    • Boost is a set of libraries that aim to offer capabilities that make C++ development easier, providing capabilities not present in the standard library. It allows for writing cross-platform code without having to worry about underlying implementation quirks. Libraries that are a part of Boost sometimes get included as part of the standard library proper.
    • Bitcoin (and therefore by extension, Dash) relied heavily on Boost to make up for the relatively limited capabilities in the C++ standard library. As the standard library has either caught up or adopted Boost's libraries into itself, migrating away from Boost to the standard library allows limiting our dependency on Boost.
  • How?
    • Reducing Boost usage (#4246, #5044, #5112)
    • Migrating to std::filesystem (#6138, #6150)

Why am I asking?

As mentioned in DCG's supplemental proposal, its reserves are currently depleted. Despite cost reduction measures across the organization, there would be insufficient funding to sustain my contract with DCG, cuts included. This proposal will allow me to continue my work in the Core Dev Team, retaining my reporting structure and maintaining work output.

How much am I asking for?

160 DASH per month for the duration of the proposal period. The amount disbursed will be paid to Dash Core Group's compensation fund, earmarked for compensation to my benefit. The currently proposed amount is a reduction of the standard compensation paid by Dash Core Group in line with organization-wide efforts to reduce costs and in recognition of this proposal being raised in the later half of the budget cycle.

Verification

The below message can be verified using Keybase (source)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

https://www.dashcentral.org/p/kwvg-core-dev-nov24
-----BEGIN PGP SIGNATURE-----

iHQEARYIAB0WIQSWkYeo50/kCopIBnQwzQwGXlxKrQUCZzT1IQAKCRAwzQwGXlxK
rcUgAPURT8Tc7H2XCMZmC53V0Tcsqxsasbzu2cYA0FEBxrP4AQCsGGPIRVKZCd3K
G5DzQQocYolEPhClfnLYfpaWhWb9BA==
=yOjX
-----END PGP SIGNATURE-----


Notes

(1) - Calculated using 'git shortlog --summary --numbered --no-merges | grep "Kittywhiskers Van Gogh"' on be97bfee, rounding down to nearest 100