00:27:42 <suraeNoether> selsta I would like to not have any git access atm
00:27:45 <suraeNoether> ask me again in 3 months
00:27:54 <suraeNoether> sarang: please check reremain.tex on overleaf again
00:28:24 <sarang> Why no git access
00:30:31 <suraeNoether> you've seen how organized my github is
03:12:19 <sarang> It should not be only me with such github repo access selsta
04:31:02 <Isthmus> If you could pick 3 things to visualize, what would they be?
04:34:32 <UkoeHB_> monero's code base, the true structure of the universe, and the future
04:35:03 <UkoeHB_> good luck :)
04:45:17 <Isthmus> Oooh
04:45:25 <Isthmus> I think I can do two of those
04:45:32 <Isthmus> I’ll report back in a few months
04:48:36 <UkoeHB_> 🥳
09:52:17 <selsta> sarang: so should I remove you from the list?
09:53:08 <selsta> or suggest someone else to add with you :P
09:56:42 <selsta> it’s just about the possibility of keeping the repo organized, no responsibilities and risks
09:58:00 <UkoeHB_> selsta I think you have the wrong idea; sarang clearly wants MORE pressure and weight!
10:02:45 <asymptotically> does... does he want us to sit on him?
10:05:24 <midipoet> you could get him one of those gravity blankets: https://gravityblankets.com/products/gravity-blanket?variant=44868533007
11:36:42 <sarang> selsta: not sure who else would like to be added to the list
11:36:59 <sarang> I just don't think having only one person is a good idea
11:40:11 <selsta> why? :P
11:40:22 <selsta> but I don’t want to push you if you don’t want
11:40:52 <selsta> the largest risk is you closing an issue
13:15:30 <sarang> For good decentralization I mean
13:25:15 <UkoeHB_> gotta start somewhere lol
16:07:50 <derpy_bridge> [keybase] <surae>: Isthmus?
17:05:38 <sarang> surae suraeNoether: I've started adding notes to your new Overleaf document
17:47:26 <sgp_> Random thought now that dandelion++ testing is open
17:47:39 <sgp_> Are there consequences to other users if I hypothetically tested dandelion++ with an open mainnet node?
17:49:19 <gingeropolous> i may be mistaken, but the way I understand things, the transaction needs to be broadcast using the d++ protocol. If you receive transactions that need broadcasting, i don't think your d++ daemon can magically make them start stemming
17:49:29 <gingeropolous> i could be totes wrong though
17:51:10 <sgp_> I don't really know either if that's on the daemon or the wallet
17:51:33 <sgp_> vtnerd you around?
17:56:42 <sarang> There should be no stemming of non-D++ received transactions
17:56:53 <vtnerd> yes
17:58:15 <vtnerd> the protocol is backwards compatible. when I was running that branch on testnet yesterday, transactions received over testnet from nodes not running D++ were always interpreted as being in fluff mode
17:59:29 <vtnerd> when that node broadcast transactions to a node that didn't implement D++, it ignored the flag indicating it was stem mode, and that node started its usual flufff behavior (or flood, if it was running last release)
18:00:22 <vtnerd> if you started running that PR on mainnet, it might make sense to connect to people running that mode
18:01:03 <sarang> Worth noting (to avoid any confusion) that D++ nodes don't query their neighbors for D++ compatibility (and that's on purpose!)
18:01:18 <vtnerd> there is no flag to indicate that mode (i.e. the node doesn't "select" only nodes running that mode), ... which ...  I don't know tat could be changed
18:01:35 <vtnerd> yeah your right thats why I implemented it like that lol
18:02:13 <sarang> I know! But I wanted to mention it in case anyone was curious about networks with different node capabilities
18:02:24 <vtnerd> but if you connected to several people running that mode (outgoing), the chances are increased that some D++ is used
18:03:23 <vtnerd> its not a bad test either way to make sure txes don't get stuck, but the bigger stress will come when the release "rolls" out slowly
18:03:44 <sarang> Yeah
18:05:51 <vtnerd> also, if you wanted to do the verification that I did - limit a node to one outgoing connection that also has D++, then send to the first node
18:06:25 <vtnerd> with the log statements it should now be easy to see each hop either fluffing or stemming, then verify it shows up on a web explorer
18:09:55 <gingeropolous> " Note thatthe decision to diffuse does not depend on the transaction itself—in each epoch, a node is either adiffuser or a relay node forallrelayed transactions. "
18:16:44 <sarang> yes
18:24:33 <sarang> gingeropolous: was there a question about that quote?
18:25:38 <sarang> At the start of a local epoch, the node flips a weighted coin. That determines its mode
18:25:45 <vtnerd> that is reference to a received txbeing in "stem" mode
18:26:28 <sarang> A node that receives a non-stem transaction will always continue to diffuse it
18:26:55 <vtnerd> I _think_ that was gingers question, because my statements above seem to contradict that quote
18:27:28 <sarang> Well, there's the transaction's status, and the node's status
18:27:37 <sarang> (or mode, or whatever terms are used)
22:10:54 * Isthmus gets ping
22:11:01 <Isthmus> Heyo MRL
22:11:17 <Isthmus> What's goin down?
22:11:56 <Isthmus> Oh yea, I could help with the occasional repo cleanup
22:12:18 <Isthmus> " ... D++ nodes don't query their neighbors for D++ compatibility"
22:12:31 <selsta> ok sarang and Isthmus I’ll add both of you to the list
22:12:41 <selsta> no more opt out now :D
22:13:07 <Isthmus> There's a hacky way to check for D++ capabilities, right?
22:13:34 <Isthmus> Assume we have two NRLD++ node
22:13:58 <Isthmus> And we attach both to a single organic/unknown node
22:14:16 <Isthmus> NRLD++ <---> organic <---> NRLD++
22:15:31 <Isthmus> Then send a few test D++ txns to the organic node and see how it handles them with respect to peer broadcasting