Im a UI/UX designer and id love to lend a hand in whatever way you see fit.
@birdonawire @darsmith @permaetheus that’s fantastic! We’d love to have your help. As Yeast mentioned below we’re trying to figure out user stories / use cases and we’ll have this drive a brief for a front end experience. Once there’s such a brief I’ll be sure to reach out to you all (pm me your emails if you prefer otherwise we’ll just post to here / GitHub).
In the meanwhile, a good way to help before the brief would be to work with us on the user stories.
I can help with the UX design too. Please, count me in. Later, will post some relevant use cases in Github.
Update Monday November 12th, 2018
Missed out on filling in this update on Friday, but I think, just for this week’s entry, I’ll claim that I’ve already done my part in keeping the community abreast of current happenings
For posterity, Grincon0 was last Friday evening. Was a great time had by all, and playlist covering the entire thing can be found right here!
Will be back to regularly scheduled proper updates at the end of this week.
Update Friday Nov 16, 2018
Back to wallet concerns, and @mcdallas came up with an interesting proof of concept that you can take a further look at here: https://github.com/mcdallas/gringotts-rust. Basically, it’s a shim between keybase and the wallet listener that lets you exchange Slate data via keybase. Everyone on the team seemed to think this was a great idea in principle, and the conversation extended to the notion of having a common API in place to allow the community to experiment with different slate-exchange solutions .
So to this end, I’ve decided another round of refactoring on the Wallet API is in order, this time to more strongly decouple transaction operations from the actual exchange. So to this end I’m working on another large-ish PR: https://github.com/mimblewimble/grin/pull/1983
It’s work in progress so far, but I think it’s headed in the right direction. The wallet API was a bit cluttered with mostly redundant functions that did things like ‘build a transaction and send via http’ or ‘build a transaction and save to a file’. I’ve changed that to make the API a bit more granular, so now there’s a single ‘build a transaction’ function that just returns the slate to the caller and lets the caller deal with how to send it around. The caller is responsible for doing a bit more under this design, but it’s ultimately much more flexible.
As for sending and receiving, I’m trying to create a common interface to allow authors to implement different communication methods that the command-line client should just be able to pick up and use without further changes to the code. You can see here what it looks like at the moment, but keep in mind it’s preliminary and subject to change. At the moment I have an HTTP Adapter that handles sending and listening as per usual, but I’ve also implemented a File Adapter that now takes care of loading files into slates and saving them out again. As a result, the main wallet code looks exactly the same no matter what communication method is used, the only thing that differs is the type of Adapter being used. If that works out, hopefully we can test the architecture a bit more fully by integrating a keybase adapter.
So deep back into code this week after last week’s Extroversion. Plan is to just hide here for a bit and try and shape the wallet api into its final(ish) form and hammer out any remaining annoyances.
Take care, and enjoy weekend!
Update Friday November 23rd, 2018
There appears to be some sort of mandatory thanking-type holiday going on in the US, so the community’s been a bit more quiet than usual over the past couple of days. I’ve had a solid week smashing away at the keyboard in front of several vim/tmux windows. The small matter of a release date being announced (on or around Jan 15th) has helped focus the mind on what absolutely, positively needs to be done by then, so I’ve altered course slightly. Here’s what happened:
The ‘plugin’ refactoring PR referenced last week is done, tested, and merged. There should still be a few things left to work out on that functionality, such as how to pass parameters into a plugin and whether/how to separate ‘plugins’ builds from the main code base. I’m hoping someone from the community interested in seeing wallet exchanges happen over their medium of choice will have a look at it, but otherwise I’m quite interested in integrating a keybase exchange when it can be appropriately prioritised.
Of more pressing concern now is BIP39 support and better handling of the wallet seed BIP 39 simply means “wallet recovery word lists”, but some changes to how we use the password and store seeds were also necessary to support this. This, I think, was the most obvious piece of user functionality missing from the command-line wallet, and will be in place once a cursory review or two is done and I push the big green merge button. Full details on what’s changing exactly are in the comments section of the PR, and the ever-growing wallet usage doc has been updated to reflect the changes.
I’ve also undertaken to start properly documenting all of the wallet API layers as an ongoing project. Putting together documentation, especially good documentation with code examples is quite painful (rust even tests documentation code examples to make sure they compile,) and much better done over time in short, focused sessions as opposed to marathons where you start taking shortcuts cause you’re sick of looking at it after 10 minutes. So more to come there over time, particularly on the more ‘inner’ layers of the wallet libraries, which I think are less likely to change now.
Just quickly on that, while the lower layer apis (
libwallet) are of decent enough quality now (or so I think), the wrapper portion that currently comprises the HTTP
owner api listener has more or less been thrown together over time and there’s no coherent JSON api into the various functions. This will need to be addressed at some stage, but it’ll probably be on lower priority than ensuring the command line wallet is ready for launch. I know quite a few people have been using it for their own projects, so if you have any suggestions for making the HTTP wrapper more coherent, let me know. Also keep in mind that when this happens everyone will likely need to update their applications to use a newer API.
Right, that’s it for now. Please return to your thankful bird slaughter or further fraying your relationships with your family or whatever it is you do over there.
Update Friday Nov 30th 2018.
Nothing like a release date to sharpen the senses, especially one with tons of Yuletide disruption between now and it.
The wallet march continues:
Testing and bugfixes based on user findings in the field. With release date looming, and most of the functionality complete, I’ve started to pay more a bit more attention to these.
Endless documentation of the wallet APIs. Rustdoc is great, but it’s very time consuming to put together, especially given that it goes as far as compiling your code examples to make sure they’re current. I have about half of the OwnerAPI documented, with the rest coming very soon (I think I have most of the awkward ones done. Painful but worth taking time on.
Various API refinements springing from above. As I’m documenting, I come across things in the API and say to myself “this is pants” and remove or rework the offending API call rather than document it. (Actually takes less time in most cases).
Addition of an optional Slate message, basically provide a space for a user to include a signed message in the slate (should hopefully enhance UX somewhere down the line.
Also starting to do some thinking about what the HTTP/JSON api should actually look like. Thoughts thus far are in the issue, so won’t repeat them here.
Coming up: more documentation, perhaps a bit of a rework of the wallet command-line code (Igno pointed out that file was getting large, and he’s correct,) some grin-miner modifications to assist plugin developers (@hashmap is in the middle of one), more thought about how to build out the V2 plugin API, and bug fixes, performance testing,… and that doesn’t touch the backlog of ‘must-have’ issues that we have marked for release.
…and all of this with holiday disruption season coming up. Fun times ahead! (But don’t think I’d rather be anywhere else.)
Update Monday Dec 10th, 2018
Completely forgot to write anything here with all of the excitement going on, the definition of ‘excitement’ being ‘broken the build during the time I should have been writing this’.
Last week’s work was mostly about re-organising the wallet command line code properly to make it more consistent and manageable, as well as changes to support end-to-end automated testing of the command line client (to the point where tests are actually parsing a command line and executing the result). Want to get moving on this weeks task’s (more wallet fixes, wallet performance, look into these mining issues everyone seems to be having to see if there’s anything in it,) so will keep it short and save a longer update for Friday.
So off to Vim I go…
Update Friday Dec14th, 2018
Bug fixes, testing, stability, issue resolution the past couple of weeks, likely to continue for the next few weeks as we approach launch. Nothing earth shattering here, just many smaller items and fixes as befits the weeks before a release. The kind of development that makes you feel a bit over-excitable and scatter-brained. As a sampling of the kinds of things I’m addressing:
https://github.com/mimblewimble/grin/pull/2148 - Store completed transactions in file storage instead of the DB, this was causing transaction long entries to silently fail to update the database on large transactions (highly annoying to track down), and resolves issues with inconsistent transaction logs
https://github.com/mimblewimble/grin/pull/2144 - Bug with coin selection from small amounts, fixed
https://github.com/mimblewimble/grin/pull/2138 - Many automated tests were added to exercise the wallet command line as closely as possible to what happens when a user types it. This uncovered quite a few bugs and issues, resolved here.
https://github.com/mimblewimble/grin/pull/2124 - Issue allowing a transaction to be recieved multiple times, causing a mess of unconfirmed outputs in the log
And of course, the large refactor of the wallet command line code and test organisation is complete: https://github.com/mimblewimble/grin/pull/2114
Also a few mining fixes, starting to look at wallet performance, and @jaspervdm is doing some work on converting wallet outputs to switch commitments that I need to be reviewing as well: https://github.com/mimblewimble/grin/pull/2157.
All in all, things are looking relatively stable still quite a few issues left to address as ‘must-haves’ before launch, but nothing too massive. And of course, mainnet release is just another development milestone. Once this round of consolidation and main-net launch excitement is over, we’re going to keep right on with additions and improvements.
Right, expect more of the same next week from everyone, and enjoy weekend. Only 376 mod 365 shopping days until Christmas!
Update Friday December 21st, 2018
Santa’s on his way, so we’ll all be getting together with our families to roast chestnuts on our new 9-GPU rigs, the kids unable to sleep with excitement for Grin’s mainnet.
I expect I probably won’t be getting around to an update next week (or have enough to report to make one worthwhile,) so I’ll leave the next update until consumer-stimulus season is over and the Year of the Grin rolls around. I might even spend a bit of time with the Yeastlings as well, mostly just to make sure they don’t wreck anything else.
The past week has been about Floonet, which (a couple of hiccups aside), launched happily enough. For my own part, it was mostly bug fixes and knocking one or two things off the ‘must-have for mainnet’ list.
But I think I want to write about something slightly different today. After the launch of Floonet, I’m in as close to a sentimental mood as I ever get, meaning the empty space in my rib cage where my heart should be is a degree less cold than it should be.
So I’ve taken off the developer Santa hat for a few moments, cause when that’s on all I can do is focus on the massive list of things that either could be better or still need to be done. Instead, I’m just sitting back a bit and playing with all of the things we’ve all built over the past couple of years.
I recently set up a new rig (this one’s the Yeast Tsunami,) which I’ll be using to add my own paltry hashpower to the fray on mainnet, and today I went to install from scratch. I pulled and installed Grin (while carefully following the build guide, of course,) and it worked. I type
grin at the command prompt, and up comes a fairly-informative TUI telling you what’s going on with your node and the chain. Sync kicks in (not enough blocks yet for fast sync), and I’m up to date and synced and in consensus with 18 other nodes. Stats on all of my peers and what’s going on mining-wise is all available right there if I need it. Although it’s early days for floonet, nobody’s reporting being out of sync, and the difficulty adjustment that has to account for AR and AT POWs appears to be behaving well
In another tmux pane, I type
grin wallet init -h to create a new wallet. It gives me a BIP-39 recovery phrase which it tells me to write down (which of course I do, diligently,). I create a new account for mining, and start the wallet listening on that account.
So, let’s try mining. I take down the server, then turn on the stratum server in grin-server.toml and restart the server, which is configured by default to mine into the listening wallet on the default port. Because of the embedded stratum-server approach in Grin, now I can mine into my node and listening wallet from however many rigs I care to set up.
So then grin-miner… I check it out, change a config file to have it build the CUDA libs, and build. Grin-miner builds with all available plugins, and I have a range of CPU and GPU options to mine with right out of the box. I configure it to concurrently run cuckaroo29 on 2 2080s currently in the rig, and start grin-miner. Both cards hum into action and start mining away into my listening stratum server, confirmed by another TUI with useful stats about each mining device. Back on the server side, the ‘mining’ tab shows me the connected worker, and gives me more useful stats about how many shares each connected worker is contributing, and how many blocks have been found.
I find a few blocks and funds go into the wallet, which I can check with
grin wallet info. Once they’ve matured, I should be able to exchange them with other users via files, http, or even directly via keybase.
Of course, Grin is larger than its github projects. Invariably, I’d want to check the status of the chain on a block explorer… I can go to Grinscan or Grinmint’s explorer.
Speaking of Grinmint, I decided to point a yeastmonster at Grinmint for a bit, everything works, and it looks excellent… very well designed and as easy to use as it possibly can be. I also try Grinpool, which gives me a similarly successful mining experience.
And that’s just a small sampling of community projects. On the wallet side we have a few upcoming projects,such as Grinbox, as well as quite a few mobile wallets being built. Open CL miners are being worked on (which I hope will be integrated into Grin-miner) and I’m sure there are many other bits of infrastructure that have yet to be announced. If I’ve missed anyone I apologies, but think it’s safe to say that a completely open-source coin with this kind of quality community infrastructure in place is a rarity to behold.
Now, of course there are still things to do, the code isn’t perfect, and your particular machine might not be able to compile the Cuda plugins without some painful support issues. But we’ve come a long way since Voldy did his bitcoin-wizards drive-by thing and Igno decided to push a bit rust code to github (WTF is this rust thing?).
When I look at these things in front of me, I feel proud. And I mean for real, not like you’re at some corporate launch party with a few project managers pretending to give a shit. Everyone involved in Grin’s development should spend a few minutes sitting there bonding with this daftly-named Floonet, and feel some genuine pride, because there’s genuinely something here to be proud of. And that’s not something you get to feel much of in this life.
So, many congratulations to the entire Grin community. Take some time this holiday season to relish this moment, cause silly season is coming on Jan 15th, The Year of the Grin.
A very Yeasty holiday season from me and all Yeast-beings in this house. And don’t let Granny drink too much.
Keep on building the hustle is real merry Xmas to all you guys and your families .I had one question though . When grin does come online how will the tokens be distributed ? I’ve read the entire forum but have not found any concrete answers .
Thanks for a very lively and pride-inducing report, Yeastplume.
Your prose writing skills are right up there with your code writing skills!
I’m proud of where we are and what we’ve accomplished as well. And thank you for all your work and contributions to Grin. Wishing all the best things to you and your family. Cheers!
Wonderful work, build and hustle, & a great update thank you.
Real nice to read this pre-Xmas, wish the core team & contributors a good rest and enjoy the ride 2019 will be fun at the least
Update Friday, Jan 4th 2019
Happy new year (year of the Grin) all!. Been swamped with bored/rowdy kids off school/creche for the past couple of weeks so time has been limited. However, I did look to squeeze in whatever Grin work I can wherever I could, so here’s a quick rundown of what happened over the disruption season:
Many fixes and updates to Grin miner, including rewriting the build system to make it easier to manage.
A Binary release process for Grin-miner, which includes all CPU, most Cuda and the OCL plugins. You’ll still need to build manually for now if you want
cuckatoo_31_cuda support, but the binary release should be good enough for most people.
grin wallet check_repair, a needed wallet command that checks the contents of the wallet against the live UTXO set and ensuring the wallet’s outputs match. Users should no longer need to restore their wallets from scratch (and lose all their transaction history) if they come across hiccups. There’s a longer justification for this command here
Encrypting private slate data (needed security enhancement)
Floonet variants for BIP32 keys (keeping test and main net keys distinct)
Random other fixes, removal of non-working web wallet from build
Next week I’ll be doing more wallet testing, putting together a ‘howto’ section in the wallet usage doc, hopefully provide a very simplified mining ‘howto’, (now that there’s a binary build,) and whatever else comes up in the mad run up to launch!
2 more points of interest:
I’ll be joining @lehnberg (a.k.a Daniel from Grin) at the next London meetup: https://www.meetup.com/grinlondon/events/257028620/
I’ve launched my next Personal funding campaign for Mar-Aug 2018! The vast majority of the tasks I’ve outlined in these updates over the past year wouldn’t have been possible in this time frame without the support of this stellar community. Any contributions large and small are appreciated, and I very much hope you’ll allow me to continue my work on Grin into the foreseeable future!
Thanks it for now. Enjoy a nice relaxing post-holiday extended-family-free weekend.
Update Friday, Jan 11th 2019
A bit sick of writing things at the moment, so this is going to be a fairly short one. Here’s the reason why I’m sick of writing things:
Basically a lot of work getting the wiki filled with some Grin noob guides and a large pass over the wallet user documentation, which I’ve moved out of the source and into the wiki page (where it will be far more useful). Also a bit of work getting the site into a state where it’s better leading newcomers to the information they need. I’m trying to get all eyes towards the Getting Started wiki page, which should contain all the relevant links people need to get up and running with Grin
Some dev work too, mostly quality-of-life things with one major fix:
Add the ability to init a wallet from a recovery phrase added after a few users correctly pointed out the previous process was needlessly cumbersome and you should be able to recover a wallet in a single step. (though it’s two steps at the moment,
grin wallet init -rfollowed by
grin wallet restorewhich I believe should stay distinct steps, reasons why some other time)
Only update wallet outputs from the node if they’re involved in an outstanding transaction, this should give a large perf. improvement to the wallet under most conditions, as it was previously validating each and every Unspent output in the wallet each and every time to see if it had become spent. Makes sense that a wallet shouldn’t have to check outputs it hasn’t inserted into a transaction.
Automate wallet seed recovery process automagically backs up/moves your existing wallet seed file if you’re trying to recover a seed into existing wallet data. Should be useful for those who forget their seed passwords
libSecp bug fix Important fix, and very glad this was caught in floonet, as it would have made some outputs under certain conditions hard to recover and cause problems with wallet
Oh and renamed
check_repair sounds like the wallet broke, which is not the case. I very much think the
check process should become part of usual wallet operations instead of having to run it manually, just the scanning process is potentially too cumbersome to perform all the time at present (I think we need an incremental scan approach).
And thanks again to everyone who attended the Grin London Meetup! Was great seeing everyone and I hope to be coming out to a few more of these things once the mainnet launch dust settles down.
Speaking of that, Mainnet is launching in 4 days. Enjoy the weekend.
Thanks for drafting this update and being consistent every week.
You may want to check you link to “Getting Started wiki page” it is not taking one to:
Update Monday, Jan 21st 2018,
We launched a blockchain. Hope you like it! This brings the number of blockchain launches I’ve been personally involved in from 0 to 1.
We’re about a week in, and we don’t seem to have had any major surprises. The initial difficulty adjustment worked exactly as planned to ensure everyone had a fair chance to mine, and nobody ran away with the first thousand blocks simply by virtue of being first. (Actually, perhaps the fact it worked counts as a surprise.) Network mining activity appears more or less healthy, plenty of transactions are happening, fast-sync works, and nobody appears to be panicking over anything.
So there’s a chain there now. What next?
Well, as we’ve repeated many times before, Grin’s not supposed to be get-rich quick scheme for early miners. It needs to become useful as a medium of exchange. Obviously we’re not shooting to replace Apple pay right now, but we can certainly try and become useful in areas that are already predisposed to working in cryptocurrency, i.e. in situations where Bitcoin or Monero might already be accepted. In order to do that, we still have some work to do.
Transactions are cumbersome, and the vast majority of potential users don’t (and shouldn’t need to) understand the details of how a transaction works; they should be made as seamless as possible. The approach Grin is taking is to try and make the core wallet APIs as useful as possible, and leave transaction exchange mechanisms for different needs up to the community. This appears to be bearing some fruit, but there is still much more work to do here to facilitate all of the varying needs out there. We’ve always known this portion would be a challenge, and we’re working on it.
All of the potential extras and additions we’ve been talking about on the Grin project to date, (many of which would be very distinguishing features): scriptless scripts, atomic swaps, vaults, Confidential Assets… none of these exist in V1. Hopefully now some of us will have the time to start thinking about them a bit harder. Many of these are not as straightforward as they might have first appeared, but we’ll get there.
There’s performance (the network is young, so there isn’t enough data yet for the bottlenecks to make themselves known). There’s scaling (both on-chain and via enabling secondary layers). And of course, there’s the continuing march toward more perfect privacy, acknowledging the work and thought that still needs to go into the potential weak points of the system.
And of course, anything that comes up in the course of trying to manage a new chain under continual widespread continual public scrutiny, (no pressure).
So, in short I’m very happy with where we are, especially given the resources to date. But there’s still an unfathomable amount of work to do over the years to come.
I’m just going to try to take it one week at a time, and I’ll let you know how this week went on Friday’s update.
Update Friday Jan 25th, 2019
A week and a half in and nothing has exploded yet (touch wood). The run up to mainnet launch felt a bit frenzied, but that’s over now and we’re starting to settle in. In the absence of anything being totally on fire (touch wood,) it feels like we have a chance to catch our breath and continue with the business of developing Grin in a more relaxed manner.
The pace of development is going to be a bit different from now on. Since we’re actually live and need to support everything that’s out there now, development needs to be that much more thoughtful, measured, reviewed and tested. Sometimes it may seem that things are moving more slowly, but this is very much a good thing.
I think I’ll cut off what I was about to launch into there, as I’ll actually be discussing the future of Grin in SF at Grincon US next week.
So, this week, I:
- Did much preparation of presentations for GrinconUS, results of which will be obvious next week
- Did some fixing upping of error output messages, here and here to hopefully provide us with more clues when an issue is reported. It’s very difficult to sort out actual issues from user error at this point (not always users’ faults’, there’s a lot that’s non-intuitive to get wrong,) so adding more and better logging should help in many cases. Of course, these won’t be in widespread use until 1.0.1, so it may be a while before we see results (told you the pace had changed).
- Save slate messages in wallets so they can be accessed later (at the moment they’re just thrown out). Should make it easier for all parties to identify their transactions in various settings.
- Some triage, some reviewing of what’s there, some support, some reading about all of these future techs we want to put into Grin, all sorts of catch-up activities that kind of got put aside during the run-up to launch.
It’s GrinconUS for the first part of next week (11 hours there and 11 hours back). Once that’s done, my mental map of what to look at next involves:
- Recipient-initiated transactions
- Splitting the wallet and libs out of the main Grin executable
- Wallet V2 API (important one)
- Wallet Performance
- Fixes as identified!
That’s it for now, have a good weekend and look forward to seeing/meeting everyone at the first ever GrinconUS!
Update Monday, Feb 4th 2019
Another campaign brought to a close, and I’m once again delighted, privileged, and honoured to be able to continue in the service of the Grin community. This time, we’ve overshot the goal by just over a month’s worth, so happy to say I should be able to work on Grin worry-free until about the end of September 2019. All of this thanks to the community, which I still maintain is one of the best around in any open-source or crypto project currently going on.
Special thanks this time to Qtum, (with a massive 10BTC donation,) Sparkpool (With 100 ETH), f2pool, Prokapi, Bitfish, and several others who have either donated to my fund, or are continuing to donate directly into the general fund. Our friends of Grin list is growing longer by the day.
So on I go with the business of developing, improving and enhancing Grin!
Last week was mostly dominated by travel to Grincon in SF and back, as well as recovering from said travel. It all went extremely well, and thanks again to @catnic for organizing and running such a great event. Aside from that, I got a start on two important issues:
First, changes to allow for easier recipient-first sending all internal and nothing breaking here, but moves us towards making transaction building much more flexible.
Second, I broke out the windows partition and got Grin as far as this:
That’s the wallet, node (in user testing mode), and test miner running on Windows 10, which I think demonstrates Windows support is not far away. Still quite a few issues to sort out, but I’ll start a meta-issue on Github to track exactly what needs to be done.
My short list for the coming week is as follows:
- Create a windows build meta-issue, and start getting those elements crossed of
- Work on splitting the wallet out of the main Grin package, to allow it to be enhanced and versioned separately from Grin
- A grin miner update to include latest cuckoo 31 solvers
And of course, much more. Will let you know how I got on in my Friday update. Thank you again, Grin community.