@trevyn - Progress update thread

As a new contributor, I’m currently getting familiar with the grin and grin-wallet codebases by working on an assortment of PRs and issues.

Since posting an initial funding request at the end of March, I’ve been working on the items below. As April progresses, I expect to make 2-3 additional progress reports in this thread.

forum.grin.mw/8548 Diagnosed manufacturing error on iPollo G1 affecting thermal performance and hash rate
grin#3630 Add test for duplicate rangeproof inflation bug
grin#3621 Incentivized work leading to robust chain-level test of inflation bug
grin#3613 Fix verifier cache keys by hashing full Output
grin#3609 Thinking about how to implement a verify-chain command to increase user confidence in chain integrity
grin#3631 Tracking issue for deprecation of failure crate
grin-wallet#599 Sync grin-wallet dependencies to latest grin master and fix missing verifier_cache
grin#3617 Reviewed PR: “Update zip dependency and fix deprecation warnings”
grin-wallet#582 Fixed: “grin-wallet crashes when attempting to send amount larger than balance”
grin-wallet#600 Bubble init_send_tx error instead of unwrapping
Fix Windows CI cargo test silently passing
grin-wallet#479 Build error when targeting Apple iOS for grin-wallet v4.0.0

Glad the set of test cases is increasing, this is just how Bitcoin works, a huge amount of test cases to detect bugs from creeping into the code.

1 Like

Over the past 10 days, I’ve primarily worked on three projects:

A config file versioning scheme

To unblock implementation of the fix past fees RFC, we needed a principled way of versioning and updating the configuration file format without disturbing any custom edits or comments that the user may have made. This is a tricky problem, because TOML can express the same data structure in multiple format variants, and the toml crate does not have any functionality for updating a file’s data while preserving user comments, only full serializing and deserializing.

The chosen solution is to apply naive textual replacements to the file, while also making semantic edits to the struct that the file is deserialized into. After the edits are symmetrically applied to both forms, we re-read the TOML to ensure that it parses without error and produces the expected struct result. This can fail and error out if the user has made heavy edits to the file, but if it succeeds, the file is guaranteed to be correct.

This solution also suggests a straightforward templated approach to applying any necessary future config file changes.

Migrating from deprecated failure crate for error handling

Assessed the feasibility of this migration by removing failure and re-implementing error handling with the thiserror crate. Successfully performed the replacement, which passes all tests. There are some subtleties regarding differences in how failure and thiserror handle reporting error context information that I’ll clean up in the coming weeks. This also needs solid review notes to make for an easier code review due to the number of changes involved.

Formal specification & verified implementation of bulletproofs

This is a longer-term project that has important implications for our confidence in chain integrity. The general idea is to develop a clear, concise formal specification or implementation of bulletproofs that can be easily compared against the bulletproofs paper, and run as a parallel implementation to help mitigate any potential exploitable errors in the primary bulletproofs implementation.

There’s some behind-the-scenes work going on here that I’ll hopefully be able to share soon.