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.