Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 60 min.
Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.
Community attendance:
- antiochp
- dtavarez
- jaspervdm
- johndavies24
- joltz
- lancelot_n
- lehnberg
- mcmmike
- seddd
- tenthousandlakes
- tromp
- yeastplume
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
- yeastplume: Hope everyone is remaning safe and calm. We might just have everyone sound off briefly on what they've been up to the past little while. We've been prioritising breaking changes for 4.0.0, so to that end I've mostly been looking a more compact slate format, (which I've just got working).
- 🚀: lehnberg, yeastplume, antiochp, joltz, jaspervdm
- jaspervdm: From my side I've mostly been working on moving p2p to async. Managed to do a full sync from scratch and maintain a connection with ~100 nodes for mutiple days, but there's still a bunch of things to be improved/fixed.
- 🚀: yeastplume, lehnberg, antiochp, joltz, tenthousandlakes
- antiochp: We have a revised nskr proposal based on duplicate kernels "no recent duplicates" (nrd) that potentially gives us a simple way of implementing relative locks against kernels.
- 🚀: lehnberg, jaspervdm, joltz, yeastplume, tromp
- antiochp: And potentially shifting focus to investigate relaxing our "no duplicate outputs" consensus rule (for 4.0.0)
- jaspervdm: We would have to think also what removing the duplicate output rule means for wallets.
- yeastplume: The duplicate changes were mostly to avoid arbitrary data, is that right?
- antiochp: Yes but nrd also lets us do the same thing with very little changes to the current kernel code. Both are feeding back into a soon to be done rewrite of the "relative kernels" RFC.
- yeastplume: Wallets already have a degree of support for duplicate outputs as a measure to deal with multiple wallets using the same seed. Wallets already store mmr postion when it's available.
- antiochp: (and nice side effect is no room for arbitrary data).
- jaspervdm: Yeah but I do not think that solves all cases.
- 👍: antiochp
- yeastplume: No, but it's a start at least
- antiochp: Ok so we need to take a look over wallet impl for duplicate outputs. Kernels with references to prior kernels was a big invasive change. Kernels that reference the same kernel implicitly is a far smaller change. To be clear - both changes are non-trivial.
- 👍: yeastplume
Proposed agenda reviewed, with points added based on comments in the issue. Testing, packaging & releasing, and how to handle network upgrades past v5.0.0 points were tabled until next meeting due to the number of topics on agenda.
- lehnberg: I've not made any progress on triaging. You can shame me. Thinking maybe I should just move it to an issue under grin-pm? It's defo not a priority (I think).
- 🔔: jaspervdm
- yeastplume: I think moving it to a grin-pm issue would be fine
- yeastplume: That was to be moved to an actual separate 'executable' respository to include all grin projects and unit tests, which is still on my mind but will likely be a post hf thing, this should just be an issue in the grin repo for the time being.
- 👍: lehnberg, antiochp, jaspervdm
- mcmmike: Some wallets are using basic auth to query their local or remote node, so I tested it with our apis which not require and basic-auth and it worked even the wallet did send an string for basic-auth.
- antiochp: Sounds like this should be an issue on grin itself.
- jaspervdm: Not sure if it needs to be an issue. auth header is just completely ignored if auth is disabled. Which imo is fine.
- yeastplume: Sure, I think an issue in the grin repo should suffice, and we can think about and respond to it properly there.
- antiochp: @mcmmike want to open an issue on grin repo for this?
- mcmmike: Can do it, in general I just wanted an answer during the dev meeting. But I got confused by the date of the dev meeting, because @lehnberg did the summary on the 17th but dev meeting is tomorrow. :)
- lehnberg: The dev meeting is happening this very moment :) Right here, right now.
- mcmmike: Now I am really confused ! :) sorry for the mixup
- jaspervdm: No worries, create an issue in grin repo and we will discuss there.
- yeastplume: @mcmmike no worries, we need to move on a bit because we still have quite a few things to discuss, but if you create an issue we can respond from there.
-
yeastplume: So on the planning front, I was thinking that given the unpredictable nature of the times, we should really be aiming to try and limit the 4.0.0 release to what's already done + consensus / breaking changes we've already discussed, and not much more. Though some of the points still need to be decided, I'd say we should probably be very close to having a complete list of what we're looking to include?
-
lehnberg: #248. These 6 items was what I gathered from last meeting. If you can help me iron out the question marks / update etc would be great.
-
lehnberg: #3 on the list @yeastplume
minimal slates / serialisation (?) / meta-data support (?) / qr code standard (?). In the issue you're asking for an rfc potentially.- yeastplume: There will definitely be an rfc for minimal slates.
- lehnberg: If so I'm happy to try to put a draft together this week, maybe I can work on it with you?
- yeastplume: You might have stronger opinions on qr code standards, sure I think co-authoring will work.
- lehnberg: Not sure I do tbh, I'm just trying to wrap my head around the scope. Do all these things come together with that?
/ serialisation (?) / meta-data support (?) / qr code standard (?) - yeastplume: If we have a mini-mini slate format they might.
- lehnberg: I started thinking about creating separate issues for all those, but realised they are all interconnected in terms of why and how.
- yeastplume: Yes, we can discuss all of these things starting with the experimental pr I have.
- lehnberg: But it does need an rfc, we're all agreed there?
- 👍: joltz
- yeastplume: Yes, definitely. At the very least we're looking at the minimal transaction init, in which initator only sends excess without revealing change outputs and inputs. Which is a slate change, obviously.
- lehnberg: Oki. Let's begin iterating on that then. If you want to write it, I'm happy for you to. otherwise I'm happy to begin on it and take a general approach on it.
- yeastplume: Sure, if you want to begin the rfc itself it might give a more broad perspective than if I were to do it, I'm already kind of working on it from the technical side anyhow so we should be able to meet in the middle.
- 👍: lehnberg
-
jaspervdm: Do we want to add mimblewimble/grin#3206 to the list? It would require a lot of testing before I am confident enough it can be merged, but not sure on the timeline.
- yeastplume: Would be happy to leave it until after the release, it could be good for a 4.1.0.
- jaspervdm: Ok
-
yeastplume: It would look like item 2 is now 2 separate question mark items (for @antiochp) - I think duplicate outputs should probably be treated separately from nkotb/nkvd/rbmk whatever it is these days.
- lehnberg: The former blocks the latter?
- antiochp: Yes separate thing. We need both to do anything useful with the kernel locks - and both are consensus breaking changes. But neither blocks the other directly
- 👍: lehnberg
-
yeastplume: (and you might as well add 'removal of insecure v2 wallet api as an explicit point, because that's done: mimblewimble/grin-wallet#351
- 👍: lehnberg
-
lehnberg:
deprecate node api v1? Is that going in? (quentin is not here though). -
lehnberg:
parallell ibd?- yeastplume: I think the plan is to remove (not just deprecate) node api v1 ?
- lehnberg: Can we do that? Without announcing its deprecation first?
- yeastplume: Right, thought it had been announced, but I might be mistaken.
- jaspervdm: My impression we would only deprecate at v4.0, but I could be wrong
- 👍: mcmmike
- lehnberg: Same
- yeastplume: Okay, let's leave it as is for now, and ensure there's at least a deprecation warning in the code from 4.0 on, (and announce, of course).
-
lehnberg:
announce deprecation for running http listener for external addresses?? If it's to be gone by 5.0.0, that needs to then happen. In 4.0.0.- yeastplume: I think we need to know what the alternative is first
- joltz: That's related to the next point.Maybe that discussion will help inform this one.
- yeastplume: Yep, which I'd really like to hear about.. so on planning... do we need to do more than just update the list right now? I think any further refinements will come from discussion the individual issues, which we're about to do anyhow.
-
lehnberg: In terms of scope freeze, how about we say that we close on scope by end of next dev meeting? And that we don't plan to add any work beyond what's in the list after that point?
- yeastplume: Yep, I think that makes sense. and I think we should refrain from adding too much else to what's already there unless there's very good reason.
- lehnberg: Cool - so all here, note that you can make scope addition proposals in the ticket, #248, until next dev meeting. And you might need to show up at next dev meeting to defend your item, depending on what it is and what support there is for it
- 👍: yeastplume, seddd, antiochp
-
joltz: I compiled a short analysis looking at viability for a default tor-based transaction method (and deprecated http(s) method) for grin users where tor is actively censored: https://github.com/j01tz/network-protocol-obfuscation/blob/master/grin_obfuscation.md
Tl;dr due to the nature of network obfuscation, the need to stay ahead of the latest dpi techniques and the benefits/complexity tradeoff of native integrations that could be done in grin today, it probably makes the most sense to provide strong documentation and community provided "bridges" to ensure that users where tor is actively censored can continue to connect. this should be tested thoroughly with affected users before http(s) is deprecated. it is also important to have a robust and secure file-based transfer method as a backup before completely deprecating http(s) to ensure that in cases where users are unwilling/unable to use tor, they can still easily transact.
If this sounds good, I'll begin working with @xiaojay to build and test documentation to support this process including standing up bridges for testing that support multiple transport protocols. In particular we hope to determine the viability of this method for users in china before fully supporting deprecating http(s). In parallel, if possible, we should look at the file-based transfer method and determine what changes, if any, are required to support file-based transactions as a solid backup to tor (sounds like we are already going this direction by looking at slate changes).
-
lehnberg: But so, in practice, how would this work? Chinese exchange x comes and wants to integrate grin. What is the best advice to them? run a tor hidden service? I think this will be a cultural/political no go for them.
- joltz: I suspect in practice most chinese exchanges would use file-based exchange method.
-
seddd: I like the general approach, especially providing unlisted tor bridges. big win for both communities.
-
yeastplume: How is running a bridge different from a new tor node to the network? can it not just end up blocked then end up in a continual cat and mouse game? Or are we talking about something like @dburkett's current transaction relaying service?
- joltz: Correct @yeastplume the advantage of the bridge is that when those packets are inspected they look differently than tor packets so require more effort to block. So if I'm a nationstate blocking all tor packets these would still get through until I actively seek out the bridge ips or can also dpi to stop all available pts.
- seddd: Bridges aren't listed in directory authority. And Tor team is constantly working on improving bridge ecosystem and breaking dpi.
-
yeastplume: Right, I'd just wonder if people running bridges would also be exposing themselves politically or legally in some cases
- joltz: Fortunately the tor project maintains many bridges. I suggest grin community run bridges as an addition to those, not substitute
- 🤩: seddd
- joltz: Fortunately the tor project maintains many bridges. I suggest grin community run bridges as an addition to those, not substitute
-
joltz: We don't want to leech tor resources without making a contribution back. in practice, our own bridge distribution channel probably just looks like community members providing obfs4/meek bridges and sharing them in keybase if someone asks.
- 👍: seddd, antiochp
-
seddd: Has anyone brought up decoy bgp routing? Having a pluggable overlay network api could also be helpful. For backup networks when one is blocked.
-
joltz: It requires a nontrivial amount of effort on the user part to do all of this. Which is why a solid backup is so important.
-
yeastplume: In any case, even if nothing else changes I think file exchange is much preferable to expecting users to run http services to recieve their grin off of exchanges
- 👎: mcmmike, johndavies24
- joltz: Agreed, it is much more secure, private etc.
- seddd: File transfer could also be automated to go over tor.
-
yeastplume: Have to admit, I was actually surprised that exchanges even implemented http withdrawals.
- lehnberg: Path of least resistance.
- johndavies24: Unencrypted files? that can be signed and returned by an unintended 3rd party?
-
yeastplume: So, @joltz once again, thanks for a really insightful and professional proposal. I think we still need a bit of time to read it over and think about the details
- 👍: joltz, seddd, antiochp
-
joltz: I think it is a really important issue that could have a lasting impact for grin so we should take as much time as needed for a thoughtful action
- 👍: johndavies24
-
seddd: Will discussion continue on the linked doc?
-
yeastplume: Do we want to rfc it?
- 👍: seddd, mcmmike
- joltz: Probably so, I'm on it
- yeastplume: Great. there's a lot to think about there, will definitely be going over it in detail.
- joltz: I'll compile a skeleton to work from and everyone interested can contribute
- 👍: yeastplume, seddd
-
seddd: Tangential question: can dandelion++ relay txs from multiple cryptocurrencies?
- antiochp: The grin impl is grin specific, so not easily no. Its not a general purpose relay.
- seddd: How much work do you think it would take to make it general?
- antiochp: That's kind of analogous to asking if bitcoin tx relay can be used for grin txs - the question does not make that much sense.
- joltz: @seddd here is a bip for dandelion in bitcoin https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki
- 🙏: seddd
- seddd: Right, was just looking to dandelion++ as a purpose-built overlay for crypto txs. Sounds like that may be for a different project tho. Anyway, sorry for tangent
- lehnberg: @seddd yeah something like nym might be more relevant here, https://t.me/nymchan.
- 🙏: seddd
None.
Meeting adjourned.