Yeastplume - Progress update thread - Mar 19 to Sep 19

Update Friday March 22, 2019

Tons of effort over the past week to get these working:

Those are images of the rustdoc documentation I’ve been putting together for the v2 wallet API, and the self-testing documentation for the generated JSON-RPC stubs.

It looks like simple rustdoc documentation, but there’s a lot going on behind the scenes to produce this. That ‘json_rpc_example’ in the image isn’t just documentation, it’s the input to an entire integration test that runs against a sample chain in the wallet’s test framework, with the output carefully compared to the expected results in the documentation. By ensuring documentation and testing are integrated this way, we can pretty much guarantee that both the rust and generated JSON RPC APIs will stay consistent, current and documented going forward. Hugely important, and definitely worth the work.

And what work it is. It goes something like this:

  • Sit down to create the json doc/test for a particular function
  • Realize function args aren’t that json-friendly, fix them
  • Come across obscure bug in serialization preventing example from working, spend hour tracking down and fixing
  • Realise fix has to go into grin core, create that PR
  • Realise function needs a statically-seeded test RNG to produce consistent output every time, implement that,
  • Realise doctest helper functions need more work to support this particular function, implement and test that
  • It’s 4 hours later and I’m still working on documenting the same function.
  • etc, etc, etc.

It’s been like this for just about every single function, and it’s only just been since I got to the last few functions of the owner API that the testing started to go a bit smoother, as most of the bugs and changes required for testing have been ironed out. The upside is that this has been a great test of the V2 API generation, and this should be invaluable going forward to keep the V2 API clean, consistent and documented. The downside is it’s tedious as hell and I can’t stand looking at it anymore right now. Luckily, it’s mostly there, with most API functions and their doctesting complete. I’ll come back and complete when I’m more fresh, but luckily this big push to get the API documentation started should only have to happen once. Doc and test changes from here on out should be incremental and more focused, and hence easier to bear.

Right, I need to go do something that’s not aligning JSON brackets. Enjoy weekend!


Update Friday, March 29th, 2019

Had a good time at Grin Amsterdam during the early part of the week, all a bit of a blur but there’s plenty of video and other documentary evidence from the event. I can never watch videos that include myself, so I’ll leave the simple job of tracking them down to any interested readers.

As for the rest, I’m just in the process of merging a final v2 PR finishing up the API documentation and making a few tweaks and changes to make it as friendly as possible. What’s there after this PR is merged should more or less be what the V2 API will look like for 1.1.0. It is by no means perfect, and minor version numbers (1.2.x, 1.3.x etc) with additions and changes will hopefully be coming on a more frequent basis than the main Grin executable. However, all of this work the past few weeks was vital to ensure changes will be (more or less) self-testing and as self-documenting as possible, which should greatly benefit all future work.

So short terms tasks are now:

  • Wire the rpc-json API into the http listener (so there should be a v2 api listener on the endpoint as well as the previous)
  • Merging grin’s master branch into the 1.1.0 branch, to prepare for 1.1.0 testing
  • Much testing of the wallet 1.1.0 branch to ensure things aren’t completely broken (though hopefully the amount of code not covered by unit testing is significantly shrunk)
  • … All other bits and pieces related to the release of 1.1.0

Looking very forward to getting all that done… see you next week!


Update Friday April 5th, 2019

Going to be a very short and quick update as Mrs. Yeastplume has gone away with several yeastlings so there’s debauchery to be had. All the short term points from last week have been addressed, and we have a 1.1.0 beta which I urge everyone to try. The past week has basically been getting that prepared and then testing away, and a fuller description of the release and how you can help with the testing here:

Have a good weekend, I know I will. (So long as Mrs. Yeastplume retains her habit of never reading these things anyhow).


Update Friday, April 12th 2019

A quiet week from me PR wise, mostly due to the (hopefully) imminent release of 1.1.0 and my own need to do some testing and sanity checking to ensure that 1.1.0 doesn’t have any obvious problems. From what I can gather I think it looks okay, and I haven’t heard about any major issues from anyone (which I hope is due to an absence of serious issues rather than an absence of people trying out 1.1.0). I’m keen to get a release done soon so we can get a baseline in place and start branching so there’s a place for new feature development, as well as remove the wallet code from the grin server master so people stop submitting PRs to it :smiley:

So, given I’m light on detail this week, I thought I’d take a few minutes to organize and relay all of the upcoming tasks that swirl around in my head during the night, many of which I hope should be coming fairly quickly after 1.1.0 with the V2 API and (more importantly) supporting framework out in the wild.

  • Invoicing, i.e. recipient-initiated transactions, should be straightforward and will do next after 1.1.0 release.

  • Fixes and improvements based on the ongoing audit effort, which should be focusing on the wallet right about now.

  • Full wallet lifecycle management via API - I’d like to get to the point where a wallet can be created and instantiated fully through the API, but some thorny issues around password management exist around this that need to be thought through and discussed.

  • More interactive command-line client, i.e. one that starts up and accepts commands as opposed to one-shot invocations (as wallet713 does).

  • Client API Generation, would like to be able to generate client code to call the V2 API in several languages (but could be a big project, just javascript would be a good start)

  • Proof of payment, something that’s being actively discussed but I don’t think anyone has come across the perfect solution. I’m very much in favor of keeping a light touch here and just providing enough to enable the community to build in their own solutions, so we’ll see where these discussions take us.

  • And as an added bonus, I think the Grin server API itself should be redone using the wallet V2 API as a model. May be a good project for someone else to get involved in

I’m looking forward to working on some of these in the coming weeks, and by the way, many of these issues are fairly compartmentalized, and could be very good tasks for anyone looking to get involved with development and wanting to start getting up to speed with Grin.

That’s it for now, enjoy weekend and see you at the next dev meeting!


Update Friday 26th April, 2019

Apologies for missing last week’s update, but it fell through the cracks with all of the school holiday interruptions (how I hate them). Some good development action the past couple of weeks, with a few more things squeezed in for 1.1.0 (which should hopefully drop over the next couple of weeks!):

  • First, a large messy merge update of master branch into 1.1.0, which we then decided to merge back into master so that master becomes pre-1.1.0 and gets some testing before we decide to release. I incorrectly preferred the wrong version of one or two things while merging, but @gary and a few community members managed to catch them, so I think master is in good shape for pre-1.1.0

  • A fix for V2 slate compatibility with @bdap’s help. This will ensure that post-1.1.0 the foreign api will be able to accept and parse earlier versions of slates, as well as return earlier versions to the caller. I suddenly realized this was missing from 1.1.0 and definitely wanted to get this in before release. It’s also handled much more cleanly than in the V1 api, so there’s a ton of code I look forward to ripping out once we drop the V1 API in favour of V2 and beyond

  • Adding a check_version function to the foreign_api, to let callers know that a wallet is alive and what slates it can accept before trying to send it anything. Should be a help for wallet developers.

  • And the current body of work is on the long awaited Invoiced Transactions feature, which is essentially the inverse of the regular transaction workflow. The payee generates an invoice for a certain amount, adds their output, then sends to the payer to accept it, add their inputs and send back. Will talk about this in more detail once it’s complete, but I’d definitely like to get the API firmed up before 1.1.0 is released.

And as always, other bits and pieces. That’s it for now, and will get back to you next week, hopefully with more info about when 1.1.0 will be shunted into the wild.

Enjoy weekend!

Update Friday, May 3rd 2019

Just a quick update this week as I’m currently travelling over a long weekend

  • Work on the api support for invoice transactions is complete, documented, tested and merged. Complete details for those interested in trying it out via the
    API can get all the documentation via rustdoc

  • I’m currently working on the obvious follow up, enabling invoice transactions in the command-line wallet. Progressing steadily there and should have it ready for 1.1.0 (coming any week now!)

  • As a skunkworks side project/learning experience, I’ve been putting together a rust implementation of SLIP-39: Shamir Secret Sharing for mneumonic codes, which I hope to integrate into the wallet as some point a nice feature-add. Basically, master key sharing where you can take your bip39 mneumonic and split it into a 3 of 5 (for example) threshold scheme to distrubute to family members. The underpinnings here also relate to future multisig wallet features. Much more on this later, but intend to get the implementation public as soon as I’ve got all the embarrassing bits out.

That’s all for now, enjoy long weekend (provided you have one).


Update Friday, May 10th 2019

Good week of steady progress, I think, with demonstrable results for everything mentioned in last week’s hasty post.

Firstly, the command line support for invoice transactions is now completely in place in grin-wallet master. Instructions on how to use it are in the executable help, and writing this has just reminded me that I need to document the new commands on the wiki (unless someone else gets there first). Will get to that shortly.

In slightly bigger news, @quentinlesceller has completed his work migrating CI from travis to Azure pipelines, which means we’re now able to produce builds for grin and grin-wallet for all 3 major platforms with a single tag. Since I’m pretty much done with feature adds for 1.1.0 wallet, I went ahead and did the 1.1.0-beta-2 build, which you can now download and start playing with. However, I don’t believe a 1.1.0-beta.2 build has been created for grin server, so you’ll either have to wait for that or compile grin from master. I’d imagine the grin 1.1.0-beta.2 should be out any day now (going to check on gitter right now)

Also, as mentioned last week, I’ve been working on an implementation of SLIP-39: Shamir secret sharing for mnemonic codes, which I’ve now made public on github at I’ve been working on this as a bit of a side project in the background and hope to get it up a decent enough standard for inclusion in grin’s wallet. The process of doing this has given me a good education in secret sharing, which leads into future research on supporting multisig in the wallet since threshold signatures work using the exact same concepts. The wallet also gets a nice little feature add which I don’t think exists on any other wallet at present. Here’s a small example, from the lib’s test output:

My 12 Word wallet master key (BIP39 mnemonic) is run through the lib and split into a 3 of 5 scheme. The output is as follows:

Group 1 of 1 - 3 of 5 shares required:
pajamas walnut academic acne already upstairs perfect soldier stay trial always cradle midst dryer debut desktop snapshot kernel belong dramatic
pajamas walnut academic agree desktop lobe breathe avoid mule rapids injury task obesity briefing heat born level making medical painting
pajamas walnut academic amazing apart exhaust tenant away yelp mayor blessing prisoner plunge pants very calcium credit unfair rainbow negative
pajamas walnut academic arcade early disease fragment slow pulse software guilt flea paper lizard profile dynamic isolate calcium course agency
pajamas walnut academic axle deliver scene health afraid recall hormone lawsuit kernel cards holy fatigue cradle sympathy award much force

I can then take these split shares and distribute them to 5 family members. Each share is useless on its own, but when I get hit by a bus tomorrow (“he should have quit drinking vodka before noon”,) then any 3 of my 5 family members can get together, recreate my master key and enjoy my grins. There are multiple levels to the scheme, so it’s also possible to create splits that divide your key among multiple groups, like '2 of my personal shares can recreate the seed, or one of my shares plus 3 of 5 family members if I lose a share). There are literally infinite possibilities here, and I hope this implementation is a step toward making key management more… manageable.

So that’s it for now. I’m gonna split now (ROFLLMAOLOLLOLetc…). enjoy the weekend!


Great update, thanks. I know this is probably the wrong place to ask, but is 1.1.0 planned to include Windows binaries?

Great Job Specially Lib and Split one :+1:

Hi Chronos, as you can already see here: With the addition of the new CI we are able to produce macOS/Linux/Windows binaries, so yes 1.1.0 will have Windows binaries.

1 Like

Update Friday, May 17th 2019

Got very sucked into completing tests and puttin finishing touches on the Shamir Mnemonics code this week, and happy to say it’s fairly close to completion, with the major remaining tasks being completing some integration testing, CI and release work, and of course whatever reviews we can get on it.

That little segue mostly aside, grin-wallet 1.1.0-beta.3 is released alongside Grin 1.1.0 beta 2., and I hope this is a short lived beta so we can move on to creating a 2.0.0 branch and get started on some major wallet work in advance of the scheduled hard fork.

No firm commits here as to what will get into what version, but as far as major near-term work I’m considering:

  • @jaspervdm’s updated recovery scheme, which should allow for more flexibility with structing wallets (which I still need to review in detail (sorry @jaspervdm).

  • @mcdallas has been looking into encoding slates into minimized base-64, which many people think is worth including.

  • Complete lifecycle management via the API, meaning that you should be able to create and manage multiple wallets via the owner api. Naturally there are a lot of other small little issues that need to be dealt with here, particularly around master key management. This will probably be a meta issue under which some discussion and refactoring work will fall in order to allow it

  • Pulling the BIP-32 code out of grin and place it into a separate repository (as a) it really doesn’t belong in grin and b) and I’d like it split out to be included by the wallet API as part of lifecycle management work above to give greater flexibility in generating keys)

  • Integrating sssmc39 as an option in the wallet api

That’s it for now. Enjoy weekend and hope we can get our final 1.1.0 releases early next week!


Update Friday, May 19th 2019

Don’t have huge amounts of exciting things to report this week, mostly do to the fact that the state of 1.1.0 on both the grin and wallet sides are so un-exciting that it looks like it’s about launch time. Covered this week:

  • A few bugs within the wallet, including, which basically fixed invoice transactions for self-sends but involved quite a bit more doing than I’d originally thought.

  • Some updates and fixes to the Shamir sharing lib

  • Reviewing all outstanding PRs that I may have overlooked while being stuck in code the past couple of weeks

  • Various documentation updates around the place.

I’ve currently branched a 2.0.0 of the wallet off locally, and have started to work on the breaking changes for the hard fork (which will need to be prioritized over anything else given the time constraints. This should entail (not an exhaustive list):

  • Removing the V1 REST api from the code
  • Implementing the wallet http send commands via the V2 api (it currently uses V1 for compatibility)
  • Implementing the grin and grin-wallet portions of @jaspervdm’s updated recovery scheme mentioned last week (as soon as he’s made some progress on libsecp256k changes

Thanks for listening, and this time we should really, really, really have 1.1.0 out next week (well, hopefully)


Update Friday, June 7th, 2019

Apologies for missing last week’s update, but had quite a few things going on domestically that had me doing far more hospital runs (and other enjoyable activities) that I would strictly have liked, so it genuinely slipped my mind until about Tuesday morning, at which point I just thought I’d leave it until now. (All fine and over now, no worries).

Here’s what you may have missed (or probably didn’t miss, if you’re following Grin to the point where you’re read these updates as part of your Friday routine):

  • The major thing that went on over the past couple of weeks is the release (finally,) of 1.1.0. Much has been said about this already in all other channels, so I don’t need to repeat much here. It’s chock-full of new features, many of which I’ve been discussing here over the past several months and is generally good for you, so UPDATE NOW! (It’s shocking the number of people still running Grin 1.0.0)

  • Many small tweaks, updates, fixes and points of order going into the 1.1.0 to get it over the line. I won’t outline each and every one, but the PR history of grin-wallet is available should you feel the need to peruse them.

  • There was quite a lot of meeting, negotiating and organizing going on over the past couple of weeks as well, particularly with respect to the exact contents of 1.1.0, and more importantly the upcoming 2.0.0 hardfork release. The exact technical changes that were agreed there are captured in this PR, and the results there have found their way into all of the recent communications about the upcoming fork.

  • Since the HF is soon upon us and we want to be try to ensure there are as few moving parts as possible to keep track of, we also collectively decided to keep anything that’s non-Hardfork related out of the code until 2.0.0 is released. I personally believe this is necessary right now to try and ensure as smooth an upgrade for everyone as possible.

  • I’ve also done some further thinking on how the Grin project can possibly restructure itself to be more inclusive and less centralized moving forward. The current council have been discussing this topic as of late, and I’m not going to share anything specific right now, other than I hope we have a more specific proposal to discuss at the next Governance meeting (but no promises, this is all very much still brewing)

So all of that said, my priorities over the next couple of weeks are to do my part to help ensure everyone has smooth a transition to 2.0.0 as possible. The particular issues HF issues that we’ll be addressing should all now be labelled with the appropriate milestones in both repositories. I’m moving forward on my particular bits, everyone else is doing the same, and barring any unforeseen circumstances we should hopefully all arrive in smooth order.

That’s it for now, and hope to get back to you next week with a similarly optimistic outlook.


2.0.0 preparation work was the basic order of the week, with everyone trying to get all changes in for the upcoming 2.0.0 beta builds in anticipation of Floonet’s hard fork. On my side:

Someone also took it upon themselves to run up the Floonet difficulty to about 1.5 million and it took us a couple of days to get it back down to usable levels. Please don’t do that.

Also, I urge and request everyone to read and think about the proposed governance structure changes: Proposal: Grin Governance Iteration. This is the most important change to come to the Grin project, perhaps ever, and I hope the lack of public comment means that most people are on board as opposed to not having any opinions!

Expect next week to be much like this one, enjoy the weekend!


Quick this week as I have to go bake a cake for a ungrateful yeastling:

  • As expected and anticipated, most of this week’s work had to do with integrating and testing all changes for the upcoming hard fork. The Final wallet PR had to do with enforcing the original rules as agreed, and ensuing that wallets will continue to operate normally pre-and-post fork.

  • Nowhere in particular to link the results just yet, but we managed to put together and perform a quick pre-Floonet-hardfork test. Everything mostly behaved as expected, I personally tested transaction during and after, ensured that transactions created before the fork can’t be applied post-fork, and that restore works. Looking good so far and we’ll see more on the real floonet fork in a couple of days.

  • Plenty of governance structure thinking and discussion, I’ve set up a new repository here with the proposed RFC structure, RFC0 and RFC1 which I hope we can nail down over the next few days.

Provided the floonet fork goes well and we can relax a bit, upcoming are a few issues I want to look at ( mostly). Intend to spend more time on getting the initial RFCs into shape, and also intend to create the first sample RFCs on the subject of the full wallet lifecycle API. Hopefully the act of doing that will give us a better idea of whether the template in RFC0000 as described is adequate.

Time for the ingratecake. Enjoy weekend!


Update Friday June 28th, 2019
(Or Saturday if you want cause I forgot to hit ‘post’)

Building, verifying, lots of testing in anticipation of the 2.0.0 release, scheduled for Monday July 1st and from everything I can see it’s on track. Particular care was given to ensure that various combinations of node and wallet or wallet and wallet behave as expected, which in most cases means that the 2.0.0 wallet helpfully informs uses of what the problem is when it encounters an incompatibility. This mostly consists of outputting a message saying ‘your node/other person’s wallet’ is too old, so get it updated’, but at least this exercises all of the code meant to manage versioning going forwards.

Aside from this, a lot of thinking and discussion has be going on regarding the new RFC and governance processes, which has culminated in the creationg of the Grin RFC repository, which as of right this moment contains the most up-to date thinking on both processes. If you haven’t got involved in this and have opinions on how Grin is run and how changes are introduced, now would be the time to make your opinions known.

I hope we can start getting these processes implemented over the next couple of weeks. On the governance side I look very forward to subteams forming, which I very much hope will make planning new feature development much more open and inclusive. For instance, on the Wallet side it’s been very much a matter of me saying what goes in and what doesn’t, which I don’t think is healthy for long-term anything. I hope we can get a wallet subteam together where decisions are taken via consensus and with a much broader consideration of community needs.

Of course, all of this comes with a bit of a downside as well. I have several large features in my head at the moment that I want to see introduced into the wallet. Whereas before I would just have just started coding away, now I need to get RFCs together where I’ve already more or less figured out how I’d code it, as well as considered and documented all of the implications and effects of the changes. It’ll make the project more robust overall, but it is markedly slower. Still, given the stage the project is in and our recent transaction difficulties, it’s probably no bad thing to slow down feature development and make sure everything that goes in have been properly considered and debated.

I’ve started preparing an RFC for Full lifecycle support in the wallet API, which I hope to complete with a wallet subteam. There are 2 or 3 other potential RFCs I’ve been thinking about around making transactions a bit more friction free, but I’m not quite ready to talk about them just yet. But of course, these are just what’s in my head, and I hope to work with a new-formed wallet subteam to determine whether these changes are appropriate and desired.

That’s where I am for now, enjoy weekend!


Update Friday, July 5th 2019

Very busy over the past week what with all the things going on, just going to give some quick highlights here:

  • 2.0.0 was built and released, much has been said about it all over the Grinternet already, so I won’t go into too much more detail here. A few support issues aside, (particularly with the V2 wallet API as explained here) I think it generally seems to working for most people.

  • The RFC process RFC is underway, as is the Governance process RFC

  • The grin-wallet subteam has been announced, and we’re trying to get it bootstrapped, see this post for more details.

  • I’m busy getting together the first batch of RFCs for future wallet development, which I hope, with the grace of the wallet subteam will comprise the short-to-midterm wallet roadmap. 2 RFCs are up as very first drafts, 2 more are in my head to get up over the coming week. These are:

Among plenty of other smaller tasks and concerns. Going to get back to it now, so will leave it there and see you next week for the Grin HF#1 Pre-show and commentary!


Update Friday, July 12th 2019

Going to be a very quick update from my end this week, since it’s mostly been a deep-dive into coding mode:

  • Mainly, a large refactor/reworking of the ‘lifecycle management’ for a wallet in anticipation of the corresponding RFC. The goal of this PR is to ensure all of the traits and structs are properly re-worked to support full lifecycle management via the API, without actually changing anything from the user’s or API consumer’s perspective. Once this is in place, the new API functions in the RFC should be fairly easy to implement. Much struggling with the Rust compiler with respect to the borrow and lifetime checks, but I think all of these changes will make things easier to work with, and the entire code will be very well modularised.

That’s pretty much it, and I’d expect at least a couple more weeks on this PR in particular and refining the RFC before it’s ready to merge.

On the wallet-subgroup front we don’t have an exact structure for the wallet working group, we’re basically just running the channel now to see what happens. I can say that there seems to be more relevant conversation and feedback about wallet changes than there was before, so from that perspective (though it’s early days,) it seems to be having a positive benefit. A good start, and I hope to see a lot more activity in the group over the next few weeks.

Oh, and I’ll be at the Grin London meetup next week with @lehnberg and @jaspervdm… should be good times, and hope to see anyone who can make it!

That’s all for now, have a good weekend.


Update Friday, July 19th, 2019

Well, that turned out to be possibly the most uneventful hard-fork in the history of hard forks. I think the worst issue we had was that wallet listeners need to be restarted if they were running over the course of the fork (and I’ll take 100% responsibility for that one). Like the whole Y2K thing, all of the work that gets put into ensuring these events run smoothly goes completely unnoticed by most people if it’s done correctly, and everyone involved in Grin has done a great job making sure this one was completely unremarkable. Well done everyone!

Also, everyone should be on the same page with respect to running the 2.0.0 node, V2 Slate, V2 APIs etc and as far as I can tell everyone is able to transact again without these compatibility issues. We’ll all be being extra careful from now on that this remains the case, and will be highly unlikely to be making slate changes without a) very, very good reasons or b) at a scheduled hardfork opportunity

So on we go. For my part this week:

  • The large aforementioned wallet refactoring is mostly done, or at least to the point where everything works again and all tests now compile (and I took the opportunity to refactor a few tests to make this a bit easier in future). I’ve paused development there a bit to have a think, because one of the aspects of this refactor is to handle passwords and seeds over API calls in a relatively secure way. Currently researching and discussing to come up with a scheme here, and will be incorporating thinking there into a revised version of the RFC next week.

  • The London Grin Meetup went well, was good to see a few familiar faces and meet a few new ones. Also took the opportunity to have some decent technical brainstorming with @lehnberg, @jaspervdm and @ravidio (on keybase) about possible improvements and directions for Grin. I won’t go into too much detail about any of those, but I expect we’ll be relating some of these ideas in both the wallet and node subteam channels very soon.

That’s it for now. Enjoy post-hardfork bliss everyone! (for a little while before we all start worrying about the next one)


Update Friday, Aug 2th 2019

Apologies for missing a week there, but when I go into deep code mode I lose the ability to be social, and need to step away and decompress for a while before I can talk to people in a civil fashion again. Naturally, Mrs. Yeastplume loves this.

So that’s pretty much the story of the past couple of weeks, deep-code mode with a couple of very large PRs. The first one was intentionally large, the second one ended up larger than I thought due to the sheer number of places arguments had to be changed. The end result of these changes to the end user of the wallet or a user of the JSON API should be absolutely nothing, which is exactly what I’m aiming for here. However, with these changes in place the wallet lifecycle RFC implementation should consist of a few relatively small and much more incremental PRs on top of the groundwork that’s been done here.

In a bit more detail:

  • (The wallet lifecycle PR)[] was finished over the previous week, and contains a fairly large refactor that better defines a wallet instance, in such a way that functions such as create_wallet and open_wallet can exist. This adds a new WalletLifeCycle trait to provide these kinds of functions which can be implemented however it’s needed (and a default implementation is also provided for the reference wallet). Much code around creating/recoving/restoring wallets etc was moved from disparate places around the CLI implementation into the much better contained DefaultLCProvider. This cleans up the code considerably as well as paves the way for exposing this functionality via the OwnerAPI.

  • Once that was done, I focused on adding a more detailed security model to the wallet lifecycle RFC. The proposed solution XORs the stored wallet seed with a random mask in memory, and clients must provide this seed as a token on each API call. There is also a layer that encrypts JSON-RPC traffic using an ECDH derived key. I hope this gives sufficient security for passing sensitive data via JSON-RPC calls (even if it is just over localhost in many instances).

  • And I have just finished up the second large preparory-PR related to the above, implementing XORed wallet seeds. There’s not a huge amount to say about this, other than API changes are implemented in a backwards compatible way, and yet again there should be no changes whatsoever from a user perspective. Those interested in the details can have a look through the PR, but the vast majority of the changes there are just tests, doc fixes, and ensuring the XORed wallet seed mask is propagated when it’s needed.

  • Less visibly, also spent quite a bit of time getting the Grin donation address back up and working, and ensuring the key is split among council members via the Shamir share splitting lib I did a few months ago (which I hope to get into the wallet as a feature add one of these days, but far too many more important things to focus on first.

That’s the story of my past two weeks. Just as a warning, it’s coming up on ‘running out of runway’ time in the yeast coffers, and the council has been discussing whether it’s worth running another donation campaign. Some of the reasoning for doing this, despite having “a lot” (air quotes, will get to that in a second) of money in the general fund is thus:

  • The amount we have sitting there (600-700k) is a lot for an individual, but absolutely nothing for a real-world development team. The amount there wouldn’t run an average-sized development team for a year in the corporate world. This is why we haven’t gone mad with spending it and artificially inflating the team, it would disappear very quickly if we did this.
  • Yes, we can easily cover my current needs from the general fund, but Grin is always in a state of needing money and we’ve taken the foot off the accelerator with respect to funding, partly because of the large 50BTC donation. We should always be doing our ABCs (Always Be Campaigning). This might be a good excuse for a bit of a campaign drive, cause even if a sliver of money is raised from a separate campaign effort, it’s a sliver that might not have been there before.

And a couple of seemingly good reasons for not doing a campaign and begging directly from the general fund:

  • It’s less confusing to those who want to donate to donate to a single council address. Most who’ve done so have done so on the assumption the funds will be put to good use. There was definitely some confusion on my last campaign where those who thought they’d donated had donated to the general fund.
  • There may be reluctance to donate more when we have an (apparently, see above) large amount of funds still untapped.
  • Running a campaign in light of the above may seem cheeky, and I’ll have to go to great lengths to explain why it’s being done and why we don’t actually have all that much money. (On the plus side, we’d get some amusing twitter-trolling as a result).

So basically, still undecided what I’m going to do here, but need make a decision over the next week or so. Would appreciate any thoughts from people who have an opinion on this one way or another.

That’s it for now, long weekend here (i.e. everyone else gets a holiday and I get stuck with hellspawn Yeastlings for an uncomfortable number of subsequent days).