Yeastplume - Progress update thread - July to Sept 2020

Another funding period, another thread. A little bit delayed starting this one, was taking a bit of time off due to too much Beastpluming Slatepack work pre-hf, and then a family emergency precipitated a bit longer of an absence than I would have strictly liked.

But back into it now, and easing back with a PR Performing all sorts of post-HF3 cleanup. There was tons of cruft in the code to support the 2-week period between 4.0.0 launch and the actual HF, and the first order of business is to clean all of that up.

Our planning for 5.0.0 (and any 4.1.0) is a little bit up in the air still, but some obvious next things I’d like to focus on after this cleanup are:

  • look a bit deeper into (mostly) lock-free transactions. We’d set them up in the 4.0.0 release and there are a few things that still need to be sorted out (such as how do we handle fees, what do we do in the invoice case?)
  • Look into simplifying the wallet commands, now that the slate state is recorded within the slate, there should really be no need for separate (recieve/finalize/pay) commands, just some sort of ‘process’ command that invokes the next stage

Anything beyond that will become clearer as 5.0.0 planning progresses.

That’s all I have for now, hope to be in full force next week!


Great that your back. I would keep receive/finalize/pay command just add an additional command to perform those automate in the back, e.g. make_transfer that invokes them as part of the transfer process.

Update Friday Aug 14th, 2020

A lot of bug fixes over the past few weeks, looking into issues, maintaining the build, as well as a few more PRs cleaning up what’s left of the pre-HF3 conversion cruft. Also quite a bit of time spent looking over and trying to make sense of the the copious number of new ideas and RFCs, which is like drinking from a firehose. It seems there are so many things going on again that it’s hard to know where to focus, which I guess is a good sign overall.

As far as something to bury myself in without causing too much trouble anywhere else, I’ve started an earnest effort at what I’m now calling 'Late Locking`, e.g. mostly lock-free transactions. I doubt this will be merged anytime soon, but I’d like to get it working in a test case at the very least, so as to be better informed about the RFC that would most likely have to be put together to support this.

Also (belatedly) beginning to look at @phyro’s RFC for replay protection, I’ve been a little bit out of the loop here, but starting to catch up (there’s a ton of information to digest and think about here). Like everything else I do I’ll be coming at it from more of an implementation standpoint than a theoretical one, so am hoping that between late locking and whatever (possibly experimental) implementations of replay protection need to occur, I should have enough to keep busy for the next few weeks.

Remain safe!


Update Friday August 28th 2020

Unfortunately had another series of family issues to attend to over the past couple of weeks (part of a never-ending stream), so mostly been spending time quitely plugging away on (in addition to the usual project maintenance. Had it working for a bit, decided I didn’t like the way I’d implemented it, and now settled on a cleaner approach which I hope should be flexible enough to one day support whichever one of the 4,000 variants of alternate transaction flow proposals currently underway that the community eventually agrees on.

Feel like we’re in a little bit of a quiet period development-wise with only a few minor items agreed for HF4, so hope this picks up a bit after summer is well and truly over. You also can’t help thinking that a lot of plans and ideas would be made redundant if we converge on a workflow that everyone can agree on that reduces the number of exchanges required in transaction creation by exactly one.

Anyhow, remain safe and enjoy the return to school and the possibility of getting a good part of your day back.


Update Wed, Sept 30th 2020

Apologies for the long delay between updates, but the month has been hectic. I think I’m on iteration number 5 of late-locked or mostly-lock free transactions, and turns out it’s a rabbit hole with a lot more considerations than I’d originally thought. I have a large chunk of code that I hope to be presenting sometime soon, but just want to spend a bit more time getting a few considerations right. Since the workflow for late-locked and lock-free transactions is mostly the same, I’m hoping to be able to introduce it experimentally, i.e. you’ll need to explicitly choose lock-free transactions, but the wallet will default to ‘lockful’, (or whatever you want to call them) transactions. This is a bit of functionality that we’ll have the luxury of experimenting with in this manner, since it doesn’t affect consensus, doesn’t produce any legacy we’ll need to maintain if it doesn’t work out, etc.

As I mentioned in yesterday’s meeting, I’m leaving the full-time Grin payroll for the time being, so this will be my last of these updates for a while at least. I’m not actually going anywhere as far as Grin’s concerned; I have no intention of disappearing and will continue to be contributing in my corner back on a more hobby-part time basis (like most people who contribute to Grin).

I’ve been working on Grin for about three years, about 2.5 of those on a full-time basis, and it has been without question one of the greatest experiences of my professional life, from the people to technological innovation and freedom to help build something meaningful via whatever contributions you see fit. It is also unique in that it allows you to switch gears; when you leave a company you can hardly go do something else while contributing part-time to the original project. With Grin you can. And that’s one of the reasons why I think this project will endure for a very long time, even if it sometimes feels like a slow-burner compared to other projects.

In terms of what I’m doing next; I’m still a few weeks away from being able to freely talk about my next full-time project, but rest assured I wouldn’t be working on it if I didn’t think it was genuinely worthwhile and at least had the potential to change the world in a positive way. It’s related to the background interest I’ve had in Shamir Secret Sharing Schemes, and should be of interest to a wide audience including anyone who’s ever written down a recovery phrase somewhere and wondered what to do with it (i.e everyone in crypto :D). I’ll be able to disclose more details about the project in the coming weeks, but it’s fully backed and is well on its way to becoming a thing. And want to ensure the thing it’s becoming is one that addresses a large set of shared problems while respecting security and privacy as well as it can.

Anyhow, this is not a teary goodbye. I’ve put the development meetings into the ridiculously capable hands of Antioch, (who has a far better holistic view of everything that’s going on in the project than I do at the moment, so this is a good thing). But other than that, I’ll be in the usual places, look forward to the upcoming virtual Grin Amsterdam, look forward to helping us steer to HF4 and beyond, and I look forward to more PRs around the bits of the code I know best, including the late locking I’ve been promising for a while.