selsta I would like to not have any git access atm

ask me again in 3 months

sarang: please check reremain.tex on overleaf again

Why no git access

you've seen how organized my github is

It should not be only me with such github repo access selsta

If you could pick 3 things to visualize, what would they be?

monero's code base, the true structure of the universe, and the future

good luck :)

Oooh

I think I can do two of those

I’ll report back in a few months

🥳

sarang: so should I remove you from the list?

or suggest someone else to add with you :P

it’s just about the possibility of keeping the repo organized, no responsibilities and risks

selsta I think you have the wrong idea; sarang clearly wants MORE pressure and weight!

does... does he want us to sit on him?

you could get him one of those gravity blankets: gravityblankets.com/products/gravity-blanket?variant=44868533007

selsta: not sure who else would like to be added to the list

I just don't think having only one person is a good idea

why? :P

but I don’t want to push you if you don’t want

the largest risk is you closing an issue

For good decentralization I mean

gotta start somewhere lol

[keybase] <surae>: Isthmus?

surae suraeNoether: I've started adding notes to your new Overleaf document

Random thought now that dandelion++ testing is open

Are there consequences to other users if I hypothetically tested dandelion++ with an open mainnet node?

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

i could be totes wrong though

I don't really know either if that's on the daemon or the wallet

vtnerd you around?

There should be no stemming of non-D++ received transactions

yes

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

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)

if you started running that PR on mainnet, it might make sense to connect to people running that mode

Worth noting (to avoid any confusion) that D++ nodes don't query their neighbors for D++ compatibility (and that's on purpose!)

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

yeah your right thats why I implemented it like that lol

I know! But I wanted to mention it in case anyone was curious about networks with different node capabilities

but if you connected to several people running that mode (outgoing), the chances are increased that some D++ is used

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

Yeah

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

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

" 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. "

yes

gingeropolous: was there a question about that quote?

At the start of a local epoch, the node flips a weighted coin. That determines its mode

that is reference to a received txbeing in "stem" mode

A node that receives a non-stem transaction will always continue to diffuse it

I _think_ that was gingers question, because my statements above seem to contradict that quote

Well, there's the transaction's status, and the node's status

(or mode, or whatever terms are used)

Heyo MRL

What's goin down?

Oh yea, I could help with the occasional repo cleanup

" ... D++ nodes don't query their neighbors for D++ compatibility"

ok sarang and Isthmus I’ll add both of you to the list

no more opt out now :D

There's a hacky way to check for D++ capabilities, right?

Assume we have two NRLD++ node

And we attach both to a single organic/unknown node

NRLD++ <---> organic <---> NRLD++

Then send a few test D++ txns to the organic node and see how it handles them with respect to peer broadcasting