Proposal “kwvg-core-dev-nov24“ (Active)Back
Title: | Funding kwvg for Core development (Nov 24 - Jan 25) |
Owner: | kwvg |
Monthly amount: | 160 DASH (9007 USD) |
Completed payments: | 1 totaling in 160 DASH (2 month remaining) |
Payment start/end: | 2024-11-08 / 2025-02-05 (added on 2024-11-13) |
Votes: | 542 Yes / 30 No / 16 Abstain |
Will be funded: | Yes |
Manually vote on this proposal (DashCore - Tools - Debugconsole): gobject vote-many 904bd34ee5c9db66f3506ddbf6fe439f73a837f79b5c818a05040582bb4cdf37 funding yes Please login or create a new DashCentral account for comfortable one button voting! |
Proposal description
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).
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
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)
- Why?
- 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?
- Why?
- 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?
- 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?
- 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.
- 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.
- How?
- 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?
- 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?
- 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?
- Why?
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
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
No comments so far?
Be the first to start the discussion! |
In the meantime, I am very much in favor of funding kittywhiskers independently of the main DCG prop.
solarguy
Every issue in the way of people accepting and using Dash natively should be seen as an opportunity to either use the services of one of our existing partners (e.g. Spritz) or find a new partner that can serve our needs and solve the issue.
Can you give us some more insight into the issue so that we can find a way to address it?
Due to my familiarity with DCG, having already met my compliance obligations with them courtesy of prior engagements and a positive pre-existing relationship, the current proposed arrangement provides for the least amount of friction, accounting for regulatory considerations on my end but I will take the suggestion under advisement.
On a much larger commentary than this proposal, wouldn't it be interesting if all the current DCG devs/techs/support made similar proposals by teams (e.g. core, evo, infra, mobile, etc.) ? I know what the answer would be from DCG (no!) but I hope people don't forget about this potential in the future. Especially if the SEC continues to target US corporations...
Hash: SHA256
This message can be verified at https://keybase.io/verify and look for "Signed by pasta"
KittyWhiskers (kwvg) has been an incredible member of the Core Dev team, and I wholeheartedly support this proposal. He initially started contributing to Core in the best way, organically and out of a desire to support open source. Over the past few years he’s grown from a good junior developer, into a very solid engineer.
The Core Dev team as of today, only consists of a few team members; myself, Udjin, knst and Kittywhiskers. In the v22 cycle, ~25% of all PRs merged into develop where authored by kwvg. Losing him will significantly reduce the output of core development, and reduce our ability to provide new functionality and keep up with code maintenance.
His significant contributions, specifically TorV3 adoption and BIP324 will provide significantly improved privacy gains to the Dash P2P network.
Additionally, the value provided by kwvg in my opinion is very high. At his currently proposed rate, he will only be being compensated ~50k USD per year for high quality full time software development. While hopefully he doesn’t have to maintain this rate for the whole year, the value is undeniable.
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQQCuOfQAhZ8i0Ua8F/i89eRbnItOAUCZzTzDgAKCRDi89eRbnIt
OCTfAQCldJRIMY9wml/IzXu8RbQ1RJmgh+/ltVCXiKKz2wIeRgD+PpACxCO09l1U
pneW74evEovZXgMRtC0CgTnKFXH7uwU=
=Z7DJ
-----END PGP SIGNATURE-----
Your proposal refers to the URL https://www.dashcentral.org/p/kwvg_core_dev_nov24
Why this url is not active?
How many bugs have been discovered in your code?
As for bugs, they're a part of the development process and the seeming absence of it represents something simple enough it that cannot be done incorrectly or an edge-case in something large enough that it doesn't stick out immediately. For the latter, I have submitted bug fixes like #6108, #6116, #6192, ebae59ee (#6327) and also worked with upstream bugfixes like in #6084. Just recently, #6132 was merged in to resolve an edge-case in response to community feedback.
We try to reduce the likelihood of bugs through continuous integration, unit and functional testing, running and monitoring testnets and seeking feedback. If you have feedback on bugs encountered (or code that you believe will behave unexpectedly), we have an issue tracker(1) where we would appreciate information that would help us reproduce it. If you would like to be compensated for fixing bugs yourself, the Incubator(2) will be glad to recognize your efforts (and is how I got started).
(1) - https://github.com/dashpay/dash/issues
(2) - https://trello.com/b/FPJzDcok/dash-incubator
How many bugs have been discovered in the code YOU wrote, kwvg?
Is this reported somewhere?
solarguy
Is this reported somewhere?
Does anyone knows?
But still the Mastenodes gave him 298 yes votes.
Does this make sence?
How can you vote in favor of a developer, if you have not read the statistics that reveal his credibility?
If they release finished work, and *then* it doesn't work because of unresolved bugs, that would be a real problem.
solarguy
I will not. I trust nobody.