ghtdak
commented
8 years ago A couple months ago, I did a quick but fairly in depth reorganization of the codebase. The first to go was the path adjustments in the code which preclude static analysis (linting). Then, I created a joinmarket module... moved the code around, followed by fixing how imports were used... etc.
I also found some module-level dynamic variables (dynamic global shared (danger!!!)) which, IIRC, I was fairly successful in changing (I'll take another look soon).
There is some code which was bright red under static analysis. From what I can tell, much of that is unused (different kind of red flag :-)
Joinmarket isn't a large codebase and many of the larger structural problems can be fixed in a couple days. However, recognizing / communicating that there is a problem needs to happen first. The code doesn't really follow "best practices" and has a few major red flags (e.g dynamic module level variables) which are guaranteed to cause bugs and will be impossible to find. Because these bulk changes will affect everyone, community buy-in is critical.
My efforts can be found at: https://github.com/ghtdak/joinmarket/commits/master-refactor_v1
raedah
AdamISZ
chris-belcher
I want to open a discussion on what needs to be done to start creating tags. How best to do it and what to include. Whether to use releases or version numbers, also.
I would propose we have 2 milestones as of now. In broad terms, the first is "tidy up what we currently have, and merge tested, useful improvements", the second is "make all improvements to the protocol that have broad agreement, maintaining backwards compatibility"( here '0.1' and '0.2' for short).
0.1 : Tidy up and merge improvements.
329 - hopefully @chris-belcher can decide whether this should be merged, if it is an improvement. Perhaps one possibility is to add it as a second version of the simplest yield-generator script for now?
308 #338 - not the highest priority, and not yet complete, but very desirable; if it's too much work to do now, at least bump up the default fees.
283 is a bugfix.
0.2 : Upgrade the protocol (try to preserve backwards-compat.)
Two points to start: (1) @adlai emphasises the idea of using new order types to avoid breaking compat. This seems like a strong principle, although no guarantees it will cover all situations. (2) Our goals in making these changes seem to be broadly: to preserve privacy, to preserve usability for taker side, to prevent DOS and to improve scalability.
171 is an attempt to bundle up protocol changes from earlier - some of it interacts with some of the things mentioned above, but it should be included/merged with the results of these discussions. There are various suggestions for this, difficult to categorize. E.g. #229 #287 #334 #337 #105 .
To summarise this '0.2' milestone: 2 basic objectives: general improvement of the protocol (mostly for privacy but also usability), and creating a more scalable and stable messaging layer.
Since this is so complex I would propose documentation. We currently have this only for the messaging layer, and #336, and a lot of useful user level information in the Wiki, but to give a framework for discussion on the protocol changes, I suggest a full "protocol documentation" doc (target for 0.2, so not immediately).
OK, to finish: let me know what you think about the above, but also how milestones, tags, releases should be managed. I have no real experience in that kind of thing, so my opinions are limited.