15:39:12 <br-m> <rucknium> MRL meeting in this room in 1.5 hours.
15:56:29 <tevador> Can we add this to the meeting agenda? https://github.com/jeffro256/carrot/issues/10
15:56:44 <tevador> The second fix is relatively easy to implement, but would need to be fast-tracked to meet the code freeze deadline and possibly be audited.
16:08:23 <br-m> <rucknium> Yes
17:00:22 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1435
17:00:28 <br-m> <rucknium> 1. Greetings
17:00:42 <br-m> <ack-j:matrix.org> Hi
17:00:48 <br-m> <rucknium> @jeffro256:monero.social: ping
17:00:51 <rbrunner> Hello
17:01:24 <br-m> <vtnerd> Hi
17:01:27 <tevador> Hi
17:01:44 <DataHoarder> hello
17:01:46 <br-m> <jberman> waves
17:03:04 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:04:03 <br-m> <rucknium> me: Keeping stressnet stressed. We hit 20MB blocks this week. Stressnet bugs.
17:04:16 <br-m> <syntheticbird> Hi
17:04:47 <br-m> <jpk68:matrix.org> Hello
17:05:02 <br-m> <redsh4de:matrix.org> hi
17:05:38 <br-m> <jberman> me: after combing through @rucknium:monero.social 's stressnet logs, implemented a series of fixes addressing the most significant apparent issues surrounding tx relay (some upstream, some pertaining to tx relay v2 that we'd want in for the first release of the protocol)
17:06:02 <br-m> <vtnerd> Me: looked at lws DB locking issue, updated weak ptr pr which finally appears mergable, worked a little on strand blocking issue, and have looked at another serialization issue
17:07:10 <br-m> <articmine> Hi
17:07:24 <br-m> <rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (https://github.com/jeffro256/carrot/issues/10).
17:08:26 <tevador> Is jeffro256 present?
17:09:20 <br-m> <rucknium> We can put this item later if you want, tevador
17:09:25 <tevador> Basically - when the PQ turnstile protocol is activated (in the future when we want to migrate), it will leak more info than expected. A fix is proposed.
17:09:49 <tevador> The fix needs to ne applied to Carrot before the HF.
17:10:18 <tevador> OK, we can continue with the next item.
17:11:10 <br-m> <rucknium> I will bundle the FCMP++ schedule with this one since they are related. I will go to relative locks next
17:11:22 <br-m> <rucknium> 5. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161).
17:12:20 <br-m> <rucknium> There was discussion in this room on Monday: https://libera.monerologs.net/monero-research-lab/20260803
17:13:30 <br-m> <rucknium> Seems like there is good support for the boolean relative lock.
17:13:37 <tevador> The last meeting agreed to reserve unlock_time = 1 without actually implementing the lock. I think implementing the lock is feasible for the HF.
17:15:09 <br-m> <jberman> I'd prefer to focus entirely on what's critical for the hf personally, I think stopping at reserving unlock_time = 1 is ok  
17:17:10 <rbrunner> Pessimists might argue that something will force us into a relatively early hardfork one or the other way, and there we could implement this lock ..
17:17:22 <rbrunner> *early follow-up hardfork
17:17:23 <br-m> <rucknium> I've forgotten: For actual implementation of the lock, is a soft fork needed?
17:17:39 <tevador> It could be a soft fork if unlock_time = 1 is reserved.
17:17:52 <tevador> reserved meaning not rejected by consensus
17:18:53 <tevador> Here is a rough amount of code needed to implement the consensus code: https://github.com/seraphis-migration/monero/pull/445
17:19:59 <br-m> <rucknium> Would it be a good idea to audit the implementation code?
17:20:16 <br-m> <rucknium> If it were to be deployed with the HF
17:20:34 <br-m> <jberman> This doesn't need an audit. The payment channel architecture and design perhaps ?
17:20:36 <br-m> <rucknium> It's very short
17:21:04 <rbrunner> But that can definitely come later?
17:21:20 <br-m> <jpk68:matrix.org> Considering the double-spend issue that was fixed recently, the prospect of more complexity with this HF is a bit unsettling (especially if the code isn't audited)
17:21:23 <rbrunner> And even multiple payment channel approaches implemented I guess
17:21:58 <rbrunner> jpk68: Did you have a look at that 445 code?
17:22:38 <UkoeHB> I'll put tevador's #10 issue on my todo for today
17:22:48 <br-m> <jpk68:matrix.org> I did, but FWIW the double-spend fix was even less lines of code
17:22:57 <br-m> <jpk68:matrix.org> s/less/fewer/
17:22:59 <br-m> <rucknium> I just think of the number of critical vulnerabilities patched in the BTC Lightning network code. Is it possible to bring payment channels to an audit standard? Or would it be checking if an implementation matches a paper? Anyway, that would be later on.
17:23:07 <tevador> To minimize scope, the reservation of unlock_time = 1 only needs 3 lines (1 of which is a comment and 1 is a constant definition)
17:23:13 <rbrunner> I am also often weary at more complexity, but if that code really is all on the consensus side, where would a problem hide there?
17:23:19 <br-m> <rucknium> Thanks, UkoeHB
17:24:02 <UkoeHB> On monday I posted my revised ACK for the simple relative_lock as a 'prove it or lose it' opportunity for PC proponents.
17:24:23 <rbrunner> I am sure there are myriads ways of messing up a payment channel implementation, but that's something else
17:24:26 <br-m> <rucknium> I like the phrase :)
17:25:04 <tevador> I think it's well known that payment channels can be implemented with just relative locks and adaptor signatures. The specific protocol is not important for the lock implementation.
17:25:36 <tevador> Relative locks can also simplify some atomic swaps protocols.
17:26:17 <DataHoarder> the change would allow such designs (or if just the reservation is done, allow a soft fork later to allow the designs) but what tevador is asking for does not include any payment channel design/PoC in code directly to be included into codebase, only specific consensus changes to make them viable
17:26:21 <br-m> <jberman> the code in that PR is incorrect. itwould allow a reference_block higher than chain height, because get_tree_root_at_blk_idx can return a tree root higher than chain height
17:26:46 <DataHoarder> (then there is the other suggestion that has extra fields on the tx, but afaik that's not in scope for this HF reservation)
17:26:53 <br-m> <jberman> augh, nvm, spoken too soon
17:27:15 <br-m> <jberman> the changes look ok on first pass
17:28:09 <DataHoarder> the question is whether to bring just reservation or that PR to implement relative blocks using the reservation for the HF 
17:29:02 <rbrunner> Maybe it's more complicated to find out whether somebody can do some nonsense, using those locks in malicious ways.
17:29:21 <rbrunner> And if yes, how to mitigate if necessary
17:29:37 <br-m> <rucknium> Could we view the choice this way?: Is it possible to implement actual relative locks without piling more on the plate of people who are chest-deep in the FCMP HF launch work?
17:29:41 <DataHoarder> this lock prevents including txs entirely, which is different from them being included and having weird stuff happening
17:30:30 <rbrunner> That sounds hopeful
17:30:32 <DataHoarder> (so they'd wouldn't be "mineable" until the lock passes)
17:31:45 <tevador> Has the code being touched by PR 445 already been audited?
17:31:50 <br-m> <jberman> I think it's not a big deal to get this code in in terms of manpower. Maybe would be nice to have more time to think on the failure modes / concrete payment channel design, but it's such a small change that it's not an issue of manpower 
17:31:58 <br-m> <jberman> tevador: no
17:32:38 <tevador> I think the audit scope expansion should be pretty minimal.
17:32:54 <rbrunner> Seems to me it should be no problem to wait a little with this
17:32:56 <br-m> <rucknium> @jberman:monero.social: Are you changing your mind about this, or you just don't feel very strongly about it? > <@jberman> I'd prefer to focus entirely on what's critical for the hf personally, I think stopping at reserving unlock_time = 1 is ok  
17:35:13 <br-m> <jberman> if people want it in, then manpower isn't the issue / this won't meaningfully delay FCMP++
17:36:51 <br-m> <rucknium> Did tevador once enumerate all of Monero's soft forks?
17:37:16 <rbrunner> Hmm, did we have any?
17:37:24 <br-m> <rucknium> I am just thinking of how difficult it would be to soft fork later
17:37:40 <br-m> <rucknium> IIRC, tevador had a broad definition of soft fork
17:37:53 <tevador> I don't think Monero has ever had a soft fork
17:38:10 <DataHoarder> I tend to come back to https://www.reddit.com/r/Monero/comments/1mvmg44/a_list_of_all_of_moneros_consensus_changes/ which might not be correct
17:38:13 <br-m> <jberman> I have some mild discomfort with a change that may lead to a sub-optimal design (payment channel txs have this fingerprint, fixed 720 days)
17:38:22 <DataHoarder> they call a few "soft forks"
17:38:30 <br-m> <rucknium> Wasn't the counterfeiting bug at least a soft fork?
17:38:42 <DataHoarder> but these are more like, secret updates to miners to prevent specific attacks
17:39:01 <DataHoarder> yeah, #9 on that list
17:39:26 <tevador> OK, technically the double spend fix was a soft fork
17:40:10 <br-m> <jberman> 720 blocks*
17:40:43 <tevador> jberman: Not all payment channel txs would actually use the time lock on-chain. It only appears when the channel is force closed (meaning there is a dispute).
17:41:03 <br-m> <jberman> right, *the force close txs
17:43:46 <tevador> What's the worst thing that can happen if we implement the lock? Nobody using it?
17:43:53 <br-m> <rucknium> Maybe BTC Lightning forced closed txs on-chain could be measured. Or did the Taproot update obscure them?
17:44:04 <br-m> <articmine> This does beg the question. The percentage of force closed TXs vs the increase in the annonimity set due to increased adoption as a result of payment channels. 
17:44:59 <DataHoarder> There was a larger suggestion that did not use this unlock time field, and would remove that signal, but adds a new field to txs
17:45:52 <br-m> <rucknium> I don't think the force-close txs would create much of a privacy problem. I am willing to listen to other views on that. IMHO, tx fungibility defects matter most when a user's wallet always or usually creates the defect. Then you can follow that wallet's behavior through time. In the extreme, you could even follow it with FCMP txs.
17:46:13 <br-m> <rucknium> But you would not have a user always using force-close txs.
17:46:33 <br-m> <jpk68:matrix.org> Why add part of it now, if the other half has to be added in a later fork anyways? Why not just add it all later?
17:47:20 <UkoeHB> jpk68: the point is to give PC advocates the chance to prove it's worth the extra effort/tx cost
17:47:39 <UkoeHB> or that's the point from my point of view ^.^
17:47:39 <br-m> <rucknium> Should we move on for now or continue discussing this issue at this meeting?
17:48:26 <DataHoarder> 19:46:33 <br-m> <jpk68:matrix.org> Why add part of it now, if the other half has to be added in a later fork anyways? Why not just add it all later?
17:48:26 <DataHoarder> to allow a soft fork (rule tightening) instead of hard fork
17:48:59 <UkoeHB> I think we should get a prod-oriented PR for the change and aim further discussion at that.
17:49:17 <DataHoarder> though the full set also looks very minimal, as shown in #445
17:49:43 <br-m> <jpk68:matrix.org> If it goes unused, it's just going to create more technical debt for the future with no benefit
17:50:19 <tevador> It's a chicken-egg problem. Nobody is going to design a payment channel for Monero using non-existent relative locks.
17:50:42 <rbrunner> Well, somebody even tried to implement, but then ran into serious problems ...
17:50:53 <UkoeHB> It's a small price for a large opportunity, and the field can be eliminated if it proves useless.
17:51:47 <rbrunner> This some small beside the complexity monsters that are FCMP++ and Carrot you can hardly see it :)
17:51:54 <rbrunner> *This is so small
17:52:57 <br-m> <jberman> tevador: Grease is seeking funding for their payment channel impl. Their request has seen resistance because they rely on trust in a key escrow service. I think there would be more interest in their request if it was to remove trust using this relative lock feature
17:54:08 <tevador> Yes, I think Grease might be interested in using the relative lock in their protocol if it's implemented.
17:54:41 <br-m> <rucknium> > Historical note: We based Grease on Monet/Auxchannel on the predicate that timelocks were unlikely to be added into Monero due to the heterogeneity they would introduce.
17:54:41 <br-m> <rucknium> > But if they were to be implemented in FCMP in a ZK manner, then I agree, this approach is not only much better, it's basically a no-brainer.
17:54:45 <br-m> <rucknium> https://github.com/monero-project/research-lab/issues/161#issuecomment-5107532847
17:55:02 <br-m> <jberman> It doesn't need to be implemented to spur that interest
17:55:08 <br-m> <rucknium> That's what one of the Grease developers said.
17:56:34 <tevador> "We based Grease on Monet/Auxchannel on the predicate that timelocks were unlikely to be added into Monero"
17:57:44 <br-m> <rucknium> UkoeHB: What does everyone think about koe's suggestion? "I think we should get a prod-oriented PR for the change and aim further discussion at that."
17:58:10 <rbrunner> Certainly allows a focussed long-time disucssion
17:58:28 <tevador> AFAICS the PR only needs a test to be added?
17:58:46 <tevador> Comment on the PR if anything else is missing.
17:59:55 <br-m> <jberman> tevador: ya I think that calculus changes with this brand new development
18:00:47 <br-m> <jberman> is there interest in funding Grease to develop their design with this new feature? if not, then why would we want it in?
18:02:00 <br-m> <jberman> I don't think this is a chicken-and-egg problem. If there's interest today in Grease developing a design using this feature, then it lends support for the feature
18:02:03 <tevador> IIRC their CCS was rejected mostly due to the key escrow requirement. With time-locks, I don't think anyone would oppose it.
18:02:39 <br-m> <jpk68:matrix.org> Maybe this concern is unfounded, but making consensus changes for payment channels could potentially offload some of the onus to keep the base layer inherently scalable
18:03:55 <br-m> <rucknium> This item will reappear next meeting. Let's move to the next item
18:04:14 <br-m> <rucknium> 6. Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (https://arxiv.org/abs/2607.07062)
18:05:19 <br-m> <rucknium> Does anyone now want to suggest specific code changes to mitigate the issues raised in the paper and/or volunteer to implement them? Or, especially, review them?
18:06:11 <br-m> <boog900> This PR should fix one of the issues: https://github.com/monero-project/monero/pull/11048
18:06:15 <br-m> <rucknium> I was thinking more about putting Dandeion++ inside the Tor part of the relay. Besides the implementation complexity, it would probably suffer from easy black hole attacks because Tor Monero nodes are easily Sybil attacked.
18:07:10 <br-m> <rucknium> And then if all the honest nodes get black hole attacked, you are almost back to square one. Or, you are back to BTC network privacy with the diffusion tx broadcast behavior.
18:07:19 <br-m> <rucknium> Any thoughts on black hole attacks?
18:07:55 <br-m> <vtnerd> That was my thought on d++ over tor, theres already an issue with quality relays
18:08:25 <br-m> <vtnerd> I'm going to implement the address relay issue so it doesn't include it every response 
18:08:32 <br-m> <boog900> I do think we should do multiple hops over Tor tho 
18:08:39 <br-m> <boog900> even if not full D++
18:08:53 <br-m> <vtnerd> And I'm going to look into hardening the timed sync requests to limit the timing analysis 
18:09:40 <br-m> <rucknium> By the way, a black hole attack on D++ occurs when a malicious peer decides not to relay a stem-phase D++ tx to another peer. It "swallows" the tx to prevent propagation. D++ has an embargo timer that will make the original tx originator ( and any honest nodes that got the tx during the stem phase) to initiate a fluff-phase tx broadcast behavior.
18:09:53 <br-m> <vtnerd> multiple hops over tor would be similar to d++ as we don't send to every outbound tor connection iirc
18:09:59 <br-m> <rucknium> @vtnerd: Thanks, @vtnerd:monero.social
18:11:11 <br-m> <boog900> The goal would be to make it so someone getting a tx from an incoming Tor connection does not know they created the tx
18:11:14 <br-m> <vtnerd> The way the code is written, implementing d++ over tor should be somewhat easy, but the results as you mentioned may be less desirable 
18:11:32 <br-m> <boog900> also I want to bring up this PR: https://github.com/monero-project/monero/pull/9295
18:12:38 <br-m> <boog900> Cuprate has those changes and this is making our tx-relay faster according to @gingeropolous:monero.social's monero-sim
18:12:45 <br-m> <boog900> so faster and more private (more stem hops)
18:13:20 <br-m> <rucknium> The change could be a good use case for monerosim. Try both versions.
18:16:08 <br-m> <rucknium> More discussion of this item for now?
18:17:45 <br-m> <rucknium> 7. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/).
18:18:19 <br-m> <rucknium> (We will go back to potential Carrot fix and FCMP schedule after this)
18:18:54 <br-m> <rucknium> We thought we had squashed all of the tx relay bugs, but one more appeared
18:19:58 <br-m> <jberman> Last week I had hoped to put out the next v2.1 release by this week. Ended up identifying a whole series of issues with @rucknium:monero.social 's logs, and made PR's for those. The most significant one includes some solid changes to tx relay v2: https://github.com/seraphis-migration/monero/pull/450
18:21:31 <br-m> <jberman> "but one more appeared" -> it turned out that this was apparently caused by an issue that this already-existing PR would fix https://github.com/seraphis-migration/monero/pull/419 , but while digging found a whole bunch of other things worth fixing, including issues from tx relay v2 leading to nodes banning peers
18:22:06 <br-m> <rucknium> So we finally reduced peer ban frequency? Nice.
18:22:32 <br-m> <jberman> The changes to tx relay v2 are especially important imo because it includes a change to the messaging protocol, which we'd want in for the first release of tx relay v2
18:22:42 <br-m> <rucknium> IMHO, peer bans weren't too bad, but it's nice that they will be reduced further.
18:23:11 <br-m> <jberman> I think they also didn't appear as bad because stressnet unbans peers after 2m
18:24:15 <br-m> <jberman> @rucknium: the changes would definitely reduce ban frequency (for one, because it stops banning peers and just drops connections lol), but the bulk of changes benefit most from all nodes on the network running them 
18:25:32 <br-m> <rucknium> https://mrelay.p2pool.observer/m/monero.social/jQXkPhEHVyFzDJjcBMKvxuZy.png (stressnet_blocksize_week_2026-08-05.png)
18:26:04 <br-m> <rucknium> ^ We hit 20MB blocks this week. IIRC, 20MB blocks was hit on last year's stressnet, but this is the first time on this stressnet.
18:26:30 <br-m> <rucknium> https://mrelay.p2pool.observer/m/monero.social/kZeJRfKupSfsQziIfLKiFeiN.png (stressnet_cpu_week_2026-08-05.png)
18:26:45 <br-m> <rucknium> https://mrelay.p2pool.observer/m/monero.social/KClGPhaHOWkHDrlYfOcWmxja.png (stressnet_RAM_week_2026-08-05.png)
18:26:46 <br-m> <rucknium> ^ That's CPU usage and RAM
18:28:23 <br-m> <rucknium> Anything more on stressnet?
18:29:46 <br-m> <rucknium> Those plots are from https://stressnetnode1.redteam.cash/ . The web app is blank right now because my nodes are catching up. Full storage with logs and everything. Needed to delete things.
18:30:44 <br-m> <jberman> Reiterating a comment I made over in the nwlb channel: assuming the tx relay v2 changes go through, I lean toward wanting a v3 beta stressnet where everyone on the current beta stressnet would have to update to v3, so that we can test that these changes to tx relay v2 are working smoothly. Discussed briefly with @boog900:monero.social as well
18:31:21 <br-m> <jberman> Not something that needs to be settled on right now, but just putting the thought out there
18:31:21 <br-m> <rucknium> And it would reduce storage requirements :D
18:31:50 <br-m> <jberman> well it would continue the current stressnet chain
18:31:53 <br-m> <jberman> but I guess we could start over again if people wanted to do that too?
18:33:25 <br-m> <boog900> You would want to keep the current scaling progress right?
18:33:32 <br-m> <boog900> how hard is it to build up?
18:33:35 <br-m> <rucknium> You mean a hard fork with the current chain? Or how do you get everyone to upgrade?
18:34:21 <br-m> <rucknium> Takes a couple of weeks to get where we are. Now I have too much of a good thing and my storage is filling 🥲
18:35:06 <br-m> <jberman> We could include something that just prevents new nodes from connecting to the v2 nodes, but continues with the current chain
18:35:10 <br-m> <rucknium> I am OK to try to go a few more weeks with the current chain. I will have to cut the fat to the bone, on storage.
18:36:00 <br-m> <rucknium> I think kico  stopped mining because of too much storage required
18:36:10 <br-m> <boog900> how big is it?
18:36:21 <br-m> <boog900> the DB
18:36:51 <br-m> <rucknium> 115GB pruned
18:38:26 <br-m> <jberman> if stressnet participants would prefer a fresh chain to re-spam again, then I think that would be ok
18:39:44 <kico> I can add space :D
18:39:53 <kico> sorry forgot about the node xD
18:40:35 <br-m> <jberman> thanks kico :)
18:41:01 <kico> np
18:41:03 <kico> on it :)
18:41:12 <br-m> <jberman> in any case, I think we can cross that bridge of deciding next stressnet steps once/if the tx relay v2 changes go through fine
18:41:54 <br-m> <rucknium> Sounds good. Anything else on stressnet?
18:42:22 <br-m> <jberman> nothing from me
18:42:38 <br-m> <rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (https://github.com/jeffro256/carrot/issues/10).
18:42:50 <br-m> <rucknium> tevador and @jeffro256:monero.social
18:44:06 <tevador> Anyone is welcome to comment on the issue
18:45:11 <br-m> <jberman> initial proposal seems reasonable to me
18:45:23 <br-m> <rucknium> What are the downsides to these fix options? A cheap hash calculation and more review of this part of Carrot?
18:46:27 <tevador> The fix using k_v would involve one extra elliptic curve operation when constructing a tx
18:48:40 <br-m> <jberman> Does the alternative fix proposed remove the downside risk @jeffro256:monero.social  mentioned of making K_v public leaking incoming history?
18:48:58 <tevador> Correction: one extra elliptic curve operation when accepting an enote (unless we cache K_v^j)
18:49:37 <tevador> K_v^j is not published in the PQ protocol. This might have been a misunderstanding by jeffro256.
18:50:50 <tevador> jeffro256 complained that the fix involving k_v makes scanning clunky, hence the alternative proposal
18:51:02 <br-m> <jberman> ack, I think will be best to give jeffro a chance to assess
18:52:28 <br-m> <rucknium> 4. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade  [... too long, see https://mrelay.p2pool.observer/e/oMqR5p0LREEzZjYw ]
18:55:22 <br-m> <jberman> tobtoht prepared master for Rust build changes, which sets the stage for the Rust FFI getting to master here https://github.com/monero-project/monero/pull/10359 , which is the 2nd to last PR from the Phase 1 audit
18:56:13 <br-m> <jberman> The last PR from Phase 1 is relatively small compared to the priors
18:57:44 <br-m> <jberman> Then it's on to Phase 2 PR's. I don't think an audit needs to hold up the Phase 2 PR's from merge, but arguably still worth auditing alongside Phase 3 especially taking into account the recently identified double spend vuln that would have been in Phase 3 scope
18:59:23 <UkoeHB> Link to vuln?
18:59:40 <br-m> <jberman> We're also working on getting quotes for a secondary audit of the Rust FCMP++ lib circuit and gadgets impl (in addition to the fcmp-plus-plus Rust lib), as part of the Research audit task. This covers the section of code analogous to Zcash's recent hidden inflation vuln
19:00:13 <br-m> <jberman> UkoeHB: https://github.com/seraphis-migration/monero/pull/446
19:04:16 <br-m> <rucknium> We can end the meeting here. Thanks everyone.
19:09:16 <tevador> foreshadowing comment: https://github.com/monero-project/research-lab/issues/142#issuecomment-3215321512
19:14:20 <DataHoarder> 20:38:26 <br-m> <jberman> if stressnet participants would prefer a fresh chain to re-spam again, then I think that would be ok
19:14:20 <DataHoarder> I'd prefer some space cleanup, another heavy session and might run of (fast) storage I have for stressnet. but if that sets back the size scaling, maybe not
22:04:50 <gingeropolous> gingeropolous
22:05:12 <gingeropolous> woops