Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 100 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
- d2r2
- energyburn
- joltz
- lehnberg
- mably
- paouky
- phyro
- quentinlesceller
- tromp
- yeastplume
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
- yeastplume: I've been a little bit out of it due to family issues which are curtailing a bit now, so I should be easing back into it now. Mostly been looking into small issues and fixes before the nextbigthing(tm), whatever that may be.
The proposed agenda was accepted without modifications.
- quentinlesceller: Done I just need someone to review it now, but should be good to merge.
- yeastplume: I'll take an action to review then.
-
lehnberg: So I added this to the agenda in lieu of this article by beam.
-
antiochp: I suspect we could fill 60 mins just discussing this...
- lehnberg: Yeah, was thinking maybe we just did a bit of an effort to get everyone on the same page about whether there are any risks, and what possible options are. Rather than us going deep deep into arguments for this or against that.
- 👍: antiochp, quentinlesceller
- lehnberg: Yeah, was thinking maybe we just did a bit of an effort to get everyone on the same page about whether there are any risks, and what possible options are. Rather than us going deep deep into arguments for this or against that.
-
lehnberg: So what's the tl;dr? I have a hard time cutting through the marketing speak of that article.
- tromp: Beam repeatedly suffered 51% attacks which they confirmed as defrauding exchanges. Some of which ignored their recommendation to increase requires confirmations to 60. By now they're all using at least 70 or 80 for beam. Beyond their checkpoint depth of 60. They don't allow reorgs deeper than 60. Unless the tip is more than an hour old.
- lehnberg: This is something that was added to mitigate against double spend attacks, correct.
- tromp: Yes, this is an attempt to stop 51% attacks.
-
lehnberg: From conclusions section of the document:
we implemented a rolling checkpoint mechanism that prevents automatic reorg any deeper than 60 blocks.
- in addition to stealing funds from exchanges, attacker puts the network at risk
- some dependent transactions may not be recovered after the reorg, causing inconvenience to users
- risk of network split is imposed
-
phyro: One important thing to note (imo) is that the attack was of the 'worst' type:
we analyzed the reorged blocks and noticed that they were mostly empty, but some one of them contained a single transaction. This was consistent with how an attack might be played out.
Which makes me wonder whether the transactions were replayed after of all tx graphs were stopped (something that could be compared/worse to coin maturity rule not existing).
-
tromp: They admit that their consensus rule for chain to follow (normally called longest chain rule) is unsound. Allowing for splits. Which can only be resolved manually.
-
quentinlesceller: No pow coin is immune to such account and afaik there is no quick fix apart increasing the conf time for exchanges.
-
tromp: I think that grin would rather suffer a 51% attack than adopt an unsound longest chain rule.
- 👍: antiochp, phyro, joltz, quentinlesceller, yeastplume, lehnberg
-
antiochp: One thing we are not doing today is actively monitoring for this.
-
tromp: It really is up to exchanges to properly defend against them. Which they can. And which would take away the incentive for them in the first place. Exchanges can vary the #confirmations dynamically, per-user. Depending on how much that user is able to profit from the attack.
- 👍: paouky
-
antiochp: Is it worth opening an issue or a forum thread and track thoughts/ideas on this there?
- 👍: phyro, lehnberg
-
lehnberg: So there's a dilemma there right? either: keep your longest chain rule intact, no checkpoints, makes it easier to 51% attacks, but encourage exchanges and vulnerable services to increase confirmations, and ride out the attacks as best you can
or: introduce checkpoints of some sort, unsound longest chain rule, harder to 51% attack, but much easier to force a network split, and introduce a centralization point where some group of people determine what is the "right" chain once a split occurs.
sounds about right?
- 👍: tromp
- antiochp: @lehnberg yes I think so.
- quentinlesceller: Yep.
- lehnberg: And beam went with or here.
- 👍: antiochp
-
lehnberg: Okay. Yeah we should probably document this somehow on the forum. @tromp would you like to do it? If not I can make an attempt.
- tromp: Can you make an attempt, and I'll review?
- 👍: lehnberg
- tromp: Can you make an attempt, and I'll review?
-
lehnberg: And maybe separate from that dilemma... 1/ How vulnerable is grin right now to the same type of attacks? I.e. How relevant is this to be concerned about for us; and 2/ what can we do to monitor for this, to determine whether it's happening, or someone is doing something... Fishy.
- quentinlesceller: Someone needs to do the nicehash calculation.
- antiochp: This is definitely something where community input and thoughts would be valuable - there may be strong opinions on this.
- tromp: Depends on how much grin is actively traded. Ie.how easy could attacker buy up $10k or $100k worth of grin to use in attack. Attack was easier on beam since they halved reward.
- lehnberg: Ah interesting, it's not only about the hashpower.
- joltz: I can speak To point 2: To monitor we would rely on our more devops/sre inclined members To help build a traditional c&c setup where we have geographically distributed nodes that have a communication layer to track these attacks as they propagate through the network.
-
yeastplume: Okay, so action taken. Shall we move on to 5.0.0 planning?
- 👍: quentinlesceller, phyro
-
tromp: I thought there were websites dedicated to that. Can't remember where exactly though.
-
lehnberg: Wasn't there a site for that at some point? Do they have grin?
-
joltz: Right, we could have an algo to determine risk based on market conditions like mentioned above.
-
quentinlesceller: https://www.crypto51.app.
- lehnberg: That's the one. Maybe we could work with them to add grin on it. Or set up our own.
- quentinlesceller: https://github.com/tdickman/crypto51. Pr on this repo.
- tromp: At least my friend cuckoo is there.
- joltz: We can't trust it completely though as there are plenty of private pools of compute that can be purchased as well.
- 👍: quentinlesceller
- lehnberg: True.
- quentinlesceller: Yep but that'd give a nice idea of the cost.
-
lehnberg: Okay so there's kind of three different work items available:
- forum post sharing of info (daniel/tromp).
- monitoring of p2p network for any attacks.
- calculation of attack cost or risk of attack etc. Anything else? We ought to be doing? Right this very moment?
- quentinlesceller: Sounds good to me.
- 👍: antiochp
-
joltz: One option, probably controversial, would be to have a pool of money to purchase our own hashrate if needed in event of an attack. Just throwing it out there as a possibility, likely not practical considering our project structure.
- lehnberg: Well, we have the general fund? But is that really a good use of it? Heh.
-
tromp: Have access to archive node for post attack diagnosis. Part of /2 I guess.
- 👍: lehnberg
-
phyro: It's impossible to stop 51% attacks, you can only recreate the attack to get your blocks back.
- antiochp: Worth discussing in forum.
- 👍: phyro
- antiochp: Worth discussing in forum.
-
lehnberg: Yup.
-
antiochp: Probably contentious. Would get us some pretty big pr if we blew the dev fund 51% attacking ourselves.
-
lehnberg: Okay, will track these three items (with sub-items) over at grin-pm and chase us during meetings etc until they are done.
-
paouky: I do not think it's worth discussing in forum.
-
quentinlesceller: Yeah I don't think we want to do that. Lol.
- 😂: phyro
-
joltz: Haha yeah I'm not super serious about it but it is certainly an option (that I've used successfully in the past to defend a network).
- phyro: That's interesting. Please describe one the forum post the details of how this was done 🙏.
-
antiochp: No its a serious option to at least consider.
-
paouky: I see it as extra noise, there are enough serious things to discuss, I seriously doubt this suggestion would gather up any support.
-
phyro: I think we should probably move on since it's less than 30min and we haven't touched 5.0 topics.
- 👍: antiochp
- lehnberg: How are we doing all these 5.0.0 planning items @yeastplume? Are we doing like 5 mins cap on each topic and you push forward?
- yeastplume: Well, I think we're not going to discuss each one in detail. Yeah, each topic gets 5 grin blocks.
- 🤑: lehnberg
- tromp: Ah, 5 grinutes:)
- lehnberg: @dburkett? I've not seen them so I guess still pending.
-
yeastplume: Anyone want to give the tldr and where we are?
-
lehnberg: @johndavies24 is here? He wanted it on agenda. Afaik there's been no changes since last it was discussed: https://forum.grin.mw/t/status-of-litecoin-improvement-proposal-lip-0004-for-one-sided-transactions/7259. Link to the lip: litecoin-project/lips#13
-
quentinlesceller: Ah thanks. Rendered https://github.com/davidburkett/lips/blob/master/lip-0004.mediawiki.
-
lehnberg: Last comment apr 14:
this also requires signatures on each transaction input to prove the secret key is known (ie not a rogue key). I will update the proposal shortly to include this new information. Is that required change trivial?
Can we ignore this and take it as an easy fix, or does it change the proposal significantly?
- tromp: Somewhere in between.
-
-
antiochp: My understanding is this got surfaced again because there was a perception of rules around (community) consensus not being applied equally to different proposals. These would be non-trivial consensus changes.
-
quentinlesceller: Can somebody summarize the pros and cons of such approach?
-
lehnberg: I can do pros as best as I can:
- no need for transaction building, i.e. no need for slatepacks, tor communication, text copy/paste etc;
- sending and receiving gets reduced state, sender can create and complete the transaction and fire it off in one go, there's fewer things that can go wrong, less things that can lead to a tx stuck in limbo;
- receiving is possible whilst completely offline with private key, so easier for things like cold storage etc. (Even if completely cold storage receive is possible in grin today as well, but with a lot more hoops.)
- tromp: No need for transaction building for simple payments. Still need them for multisig/atomic swap/payjoin/payment channel/etc.
- lehnberg: Correct.
- tromp: No need for transaction building for simple payments. Still need them for multisig/atomic swap/payjoin/payment channel/etc.
-
tromp: It makes grin appear more like non-mw coins.
- antiochp: Yes - one question is should grin be more like other non-mw coins or should grin "embrace" its differences (one being interactivity).
-
quentinlesceller: Wait but the proposal also requires an interaction between sender and receiver?
-
phyro: Pros:
- familiarity
- survives the receiver's connection issues
- receiver can take a nap and receive money cons:
- dusting attacks
- complexity
- can't verify the chain fully if I remember correctly (because rangeproofs get pruned and they define the additional utxo structure). That's at least my current view. I probably forgot some pros and cons.
-
lehnberg: Was cut through possible all the same?
-
quentinlesceller: Wait but this part:
the first problem is the sender still has to communicate their public key and the value to the receiver, so we need to somehow commit to that data as part of the output without affecting privacy.
Isn't solved? Or am I missing something.
- lehnberg: It's the same as in bitcoin I think quentin. Public key → your sending address. It's like the slatepack address.
- quentinlesceller: Thanks @lehnberg I'm too deep in mw now lol.
-
quentinlesceller: mimblewimble/grin#3271.
-
lehnberg: So my understanding of duplicate outputs situation:
- was proposed by antioch and tromp.
- no longer something they are actively pursuing.
- is there anyone who now is actively arguing for having duplicate outputs?
- quentinlesceller: @kurt2/3 for sure.
-
tromp: It seemed like a good idea for simplifying payment channels. But also opens a can of worms, so I still had reservations.
-
antiochp: Among other things - just makes intuitive sense to allow two outputs to be the same (in some situations at least).
-
quentinlesceller: Imo it's still unclear.
-
phyro: Duplicate outputs might (not 100% sure) solve the play attacks.
- lehnberg: Which (if I'm not mistaken) are also solved by disabling invoice support and ensuring that a sender never keeps a cancelled/unanswered transaction in limbo indefinitely, correct?
- tromp: Play attacks are best solved by making tx cancellation work properly.
- quentinlesceller: I think that wouldn't be sufficient since the sender has to monitor the network?
- tromp: No, doesn't have to.
- phyro: Yes, when you sign an output, you need to take care and reuse it the next time if it 'failed'.
- tromp: There should be 2 cancel options:
- allow alternative spending of its input (i.e. Do not keep input locked), understanding that tx might still be confirmed.
- invalidate tx by immediate double-spend of input.
- quentinlesceller: Afaiu it the play attack requires that the sender act immediatly which might not work 100% of the time?
- phyro: He needs to react before he signs a payment again.
- tromp: Option 1) should probably expire after a certain time. A simpleminded wallet would not even offer option 1.
-
tromp: And now with replay protection it looks like a bad idea.
- quentinlesceller: You mean payjoin right?
- tromp: Yes, with payjoin for replay protection.
-
antiochp: Yes the rules around spending an output become a lot murkier and harder to reason about when duplicates can exists (both in utxo and txpool). Uniqueness of utxo is one of those limitations added early that actually make a lot of sense if you are willing to live with it and work around it.
-
lehnberg: Seems at least like this is not a slam dunk yes at this stage.
-
lehnberg: It would be good if we continue building out the github issue with pros/cons/considerations. Maybe @kurt3 @kurt2 can put in some arguments there as well.
-
antiochp: Yes we would need a strong compelling reason to change behavior (to allow do).
- 👍: yeastplume, lehnberg
-
lehnberg: So for the uninitiated, nrd kernels are activated on grin's testnet, source code is in grin 4.0.0 mainnet (?) but is not activated on mainnet yet. The argument for it's inclusion in the first place is that it's needed for payment channels and some complex use cases like swap alternatives.
-
tromp: If not activated at hf4, then we very likely need an unplanned hf for later activation. So hf4 activation could be an attempt to minimize need for unplanned hf.
-
antiochp: That said there is no strong reason why we need it activated in hf4 - we have it on testnet to play with. And legit concerns that it would be too rushed if not needed immediately.
- 👍: paouky
-
tromp: If we're happy with future unplanned hfs, then not much need to activate at hf4. Which also allows more time to review.
-
yeastplume: That's another large discussion we need to have, but probably not in this meeting.
-
tromp: Would be nice to have some cryptographer's blessing.
-
antiochp: So maybe we get to full working poc of payment channels on testnet and then consider what to do with a hf on mainnet. Which takes pressure off getting it wrong on mainnet.
-
antiochp: But that assumes we can get community support around a future hf.
-
tromp: I think there is broad community consensus for need to add payment channel support eventually.
- 👍: antiochp, phyro
-
tromp: So relative kernels is not controversial in itself, only its timing and security are.
-
lehnberg: Generally I do think that we should take advantage of the opportunity we have with the hard fork. And if we need to get wiser on security before that, then we need to take active measures. It's not good enough to complain that "not enough people have seen it" and then leave it like that.
- antiochp: Issue there is the real security audit value would be in payment channel impl itself, not so much nrd kernels (only a small part of it).
- quentinlesceller: Or if we could get an audit between now and hf4.
- joltz: The risk of rushing is that if things go wrong it could require an emergency security hf as opposed to a slow rollout feature hf.
- lehnberg: I don't think talking about it for 1 year constitutes rushing it. It's not a feature that we've tried to sneak in here. And we have another six months now to improve our confidence, so let's use it.
- 👍: phyro
- joltz: Well we don't have the implementation details solidified for payment channels (afaik) so we don't really know for sure it has been reviewed in the right context.
- quentinlesceller: Yeah I'd tend to agree with @lehnberg we have some time.
-
lehnberg: So optional expiring kernels was sth @dburkett wrote he wanted. Over the weekend. Is there a forum post or something that outlines why this is great? I know the kurts wrote some.
- yeastplume: Could definitely use a tldr.
-
quentinlesceller: Is it the same as what @kurt3 proposed https://docs.google.com/document/d/1bbxhgfd3byp_gfvnterq4bmfxjtv5pjtjwi13cjszt8/edit#?
-
antiochp: This was an alternative approach to mitigating "replay attack".
- phyro: Yes. I think his solution also enabled a different way of achieving relative locks.
- quentinlesceller: Yeah this in combination with DO "can" mitigate replay attack (don't take my word on it haven't thoroughly reviewed).
- 👍: phyro
-
lehnberg: Does anyone know if this is the same feature that david was supporting?
-
tromp: I think tx monotonicity should not be sacrificed so lightly. And we have non consensus breaking ways to mitigate replay attacks.
-
antiochp: Tl;dr we can prevent tx replay by making kernels unique - this is expensive globally but we can do it within a limited window.
- lehnberg: I know this was the kurts position. But it's not clear to me that this was David's motivation, he was talking about optional expiry, which I don't know how it prevents replays. What were @dburkett's arguments for this?
- antiochp: My understanding of the argument for this was fixing replay attack at consensus level is better than adding wallet impl complexity.
- tromp: David considers tx expiry a simple solution, and wallet rules a privacy disaster.
- antiochp: It would be optional but everyone wanting to secure txs against replay would use it.
- phyro: Are you talking about kurt's idea here?
- antiochp: Kernel expiration in the context of kurt's idea yes. It's not clear this is something we want to do.
- lehnberg: I see. But... Once they are in there on consensus. What's the argument for not turning them on? Like, having some txs monotone, and others not. The argument for an end user, I mean.
- tromp: No, monotonicity is only useful if it holds for all tx.
-
lehnberg: So, if we're not ready to turn on nrd kernels because "not enough people have reviewed it and considered security", how is this different? What do we know about the implications of having expiring kernels, is that something that is obviously secure?
-
tromp: I don't think tx expiry poses particular cryptographic security risks. Except for the spamming issues.
-
lehnberg: Sure, but p2p layer / mempool security. Spamming issues: An attacker can flood the network with transactions that are about to expire. And pay no fees in penalty. As they will never be included in the blocks.
- tromp: Yes, that requires workarounds.
-
lehnberg: Does nrd kernels pose cryptographic security risks? Which tx expiry proponents unjustly trivialize, I think.
- antiochp: Potentially but maybe unlikely given their simplicity. Their use in payment channels is far more likely to have risks. Nrd is just a simple building block.
- lehnberg: Understood.
-
tromp: Yes, we're not 100% sure they're cryptographically secure for their intended use as I outlined in mailing list. Just pretty sure:(
- lehnberg: Can we bounty that up somehow?
- tromp: Yes, we could.
- lehnberg: A proof or something or is that not at all feasible?
- tromp: Could offer 1btc for attack on nrd based elder channel design.
- lehnberg: Maybe just attack on anything nrd related?
- antiochp: We'd need to devote resources to fleshing out the design.
- 👍: joltz
-
antiochp: Main idea of activating them was to allow experimentation.
-
phyro: What happens if 2nd nrd is blocked by an output?
- tromp: Nrd can be used to always have 2-of-2 outputs.
- 👍: phyro
- tromp: Nrd can be used to always have 2-of-2 outputs.
- antiochp: CO would be a nice simplification - but invasive in terms of consensus changes. And changes incentives around coinbase rewards in potentially subtle ways.
- tromp: CO probably not worth it given the time and effort invested in current coinbase rules.
- quentinlesceller: Which seems to work on ethereum though?
- antiochp: "seems to work on eth" is arguably not high enough bar for making a change like this.
- 😂: phyro
- quentinlesceller: Yeah.
- antiochp: "seems to work on eth" is arguably not high enough bar for making a change like this.
- phyro: Coinbase outputs is why I asked whether the txs on beam were eventually replayed. Since the attacker didn't bother including them in their blocks.
- antiochp: It would be really unfortunate to remove the maturity rule in hf4 to then discover a reason why we regret doing this.
- 👍: quentinlesceller, phyro, phyro, yeastplume
- quentinlesceller: Looks like a very low priority now.
- tromp: I think we would need conviction that CO is huge privacy improvement to justify scrapping current proven coinbase rules.
- 👍: antiochp, phyro, quentinlesceller
- yeastplume: Agreed there.
-
yeastplume: Does someone have a link to the info/impl? Or rather, is there an impl or is this currently theory?
-
tromp: Monero has plans to implement them.
- tromp: https://suyash67.github.io/homepage/project/2020/07/03/bulletproofs_plus_part1.html.
- quentinlesceller: https://suyash67.github.io/homepage/project/2020/07/03/bulletproofs_plus_part2.html.
- lehnberg: Scroll down to grin section in part2.
-
joltz: It seems like a decent opportunity for inclusion in a future unplanned hf but personally I don't feel comfortable with the level of review it has to include it in a hf <6 months from now.
- 💯: phyro
- yeastplume: Yes, this.
-
lehnberg: I'm in a telegram group with the bp+ authors together with kurt2 / kurt3 who are quite confident in the security of it. They were happy to answer any questions we had about it, they are in south korea time zone so couldn't make the meeting.
- yeastplume: How much review has it had though?
- joltz: The problem is I don't even trust myself to review it thoroughly enough to say "this is good enough for grin".
- lehnberg: Seems j bootle also vouched (somewhat) for bp+.
- tromp: So this is similar to nrd. Needed eventually.
-
antiochp: Might be good to get benedikt bünz view on these?
- 👍: joltz, quentinlesceller
-
lehnberg: We could prob also ask Dan Boneh about them.
-
yeastplume: There are very few people who understand bulletproofs fully, I'd be relying on a named cryptographer or two to review it.
-
tromp: But could wait for others to thoroughly review it.
-
lehnberg: I don't have a direct line to benedikt, do either of you?
- joltz: I might but probably not more useful than a cold email from any of us.
-
tromp: It saves 96 bytes per rangeproof. But we're not sure if we can stuff the same amount of rewindable data in there.
- lehnberg: Can you formulate this as a question for the bp+ authors? Later, with me, and then I can ask them and maybe they can look into that.
- yeastplume: Yeah, that's kind of crucial or wallet restore falls apart.
- tromp: I wanted to leave that for jasper to figure out.
- lehnberg: Not sure when he's ready to come back.
- tromp: I'm not familiar with the bp rewinding.
- lehnberg: Ok.
- yeastplume: I'm familiar enough with it.
- lehnberg: Great - let's work on it offline.
- yeastplume: Okay. So, that would be the list.
-
yeastplume: Good discussion on all of these, I definitely have a better sense for the general feelings on each one.
-
lehnberg: For the record, I want to add that it's frankly disappointing to have the people who complain the most about our governance and development process missing in meetings where we are trying in good faith to consider and evaluate various proposals that are important to them.
It seems like it's easier to be flippant and complaining about how pointless it is to engage, than it is to actually engage when given the chance to. I don't really see how things could possibly improve in the areas they complain about without them getting involved.
- 👍: antiochp, tromp
- 💯: joltz
- antiochp: I would be inclined to agree. These were on the agenda, some of them proposed by people on the agenda itself.
-
lehnberg: Can't make it? Wrong time zone? Just say so and we can try to move these meetings. Ignoring them and showing up for drive by comments later does not cut it in my opinion, sorry.
-
paouky: I generally agree, but to be fair there's not much discussion going on in meetings. Time is very limited.
- lehnberg: That's fair @paouky but you have a chance to voice dissent / argue counter argue / agree on an action point or two to take the matter forward.
- antiochp: This is the bi-weekly touchpoint where we can make solid (hopefully binding) decisions, particularly when there are concerns around community consensus.
- phyro: It is, but people could continue or just explain their views to have a starting point:)
-
yeastplume: This was just an overview session, I think that future meetings discussing these issues and 5.0 planning will be a bit more focused.
-
lehnberg: We have countless half baked forum threads that end up in screaming fights and repetitive arguments, not enough technical proposals and rfcs.
- yeastplume: I agree with this. We spent a lot of time putting the RFC process in place to allow anyone to propose changes in a comprehensive, reviewable, discussable manner.
-
lehnberg: "because it's pointless".
- tromp: Something about self-fulfilling prophecies....
-
paouky: You all have good points as well.
-
antiochp: We are in an interesting position where there are maybe 0 consensus related changes that are definite inclusions for hf4.
-
phyro: Just put something there so we can call it a hf.
- 🍺: paouky
-
antiochp: Well pow changes. Header version gets bumped. And we are done.
-
phyro: I think there was some good progress e.g. Kurt made a pdf for his think.
-
yeastplume: Official meeting is adjourned. Feel free to rant everyone.
-
joltz: Thanks for keeping us on track @yeastplume 👋
-
antiochp: Thanks! 👋
-
lehnberg: Thanks @yeastplume excellent stewardship.
-
antiochp: 👍 on grinutes.
- lehnberg: Yeah let's keep that format for future meetings!
-
quentinlesceller: Thanks @yeastplume and everyone who participated.
Meeting adjourned.