<s​olar:monero.social> Network layer metadata?

<0​x1zxq7896lp2zero:monero.social> monero only have dandelion++ and that too for full node

<0​x1zxq7896lp2zero:monero.social> sure tor i2p overlay network can help

<0​x1zxq7896lp2zero:monero.social> but monero need more network layer privacy

<0​x1zxq7896lp2zero:monero.social> monero only have dandelion++ and that works for full node privacy

<j​effro256:monero.social> end-to-end node encryption plus dandelion++ plus dummy stem payloads would basically hide almost all network level activity, even from ISPs theoretically

<0​x1zxq7896lp2zero:monero.social> better then some other coin that's true 👍️

<j​effro256:monero.social> Go review monero-project/monero #8996 if you want to see node E2E encryption happen

<0​x1zxq7896lp2zero:monero.social> yep it's a good direction anyway

<s​yntheticbird:monero.social> maybe from ISP but traffic pattern analysis is still something very effective in monerod case

<s​yntheticbird:monero.social> there are no packet timing obfuscation

<s​yntheticbird:monero.social> there are no packet timing paddings at the moment

<j​effro256:monero.social> Yes not currently: I should have clarified that better

<r​brunner7:monero.social> Seeking feedback for the following PR from people that may not following closely what we are up to over in the "No Wallet Left Behind" channel / Seraphis wallet workgroup:

<r​brunner7:monero.social> monero-project/monero #9368

<r​brunner7:monero.social> Valuable would be comments directly at the PR about the PR proper (Does it make sense to move code around that way?) and the general direction of basing the API of the new "post wallet2" wallet on the Wallet API

<r​brunner7:monero.social> As we see it, a statement from tobtoht would be quite interesting

<r​brunner7:monero.social> Thanks!

<h​ardhatter:monero.social> monero.stackexchange.com/questions/…ide-a-proof-of-burn-in-monero#10783

<h​ardhatter:monero.social> Is this still a valid method^ for proof of burn?

moneromooo: can you sanity check this? google/oss-fuzz #12009

<v​tnerd:monero.social> There is randomized padding but no dummy packets (yet) in that SSL patch

<h​ardenedsteel:monero.social> I don't see reason to not

<v​tnerd:monero.social> Block notifications are not padded for efficiency reasons - one message is serialized then ref counted to each connection queue

<h​ardhatter:monero.social> And it will still work after fcmp?

<h​ardenedsteel:monero.social> it should work until the address system gets change for example Seraphis

<h​ardhatter:monero.social> Do you think it would be trivial to come up with a similar method for proof of burn after Seraphis?

<j​effro256:monero.social> Yes, the same principle would apply: create an address deterministically bound to a message such that the discrete log from spendkey to any fixed generator used in consensus is unknown. Then create a spend proof to that address

<h​ardenedsteel:monero.social> no i dont think so, Seraphis would have optional privacy

<j​effro256:monero.social> Wdym by "optional privacy"? All officially supported addressing schemes have been "optionally private"

<h​ardenedsteel:monero.social> i mean you can share your private view or transaction key with anyone if you want

<j​effro256:monero.social> How does that affect burn proofs?

<h​ardenedsteel:monero.social> Burn proof is just sharing an OutProof or Tx Secret

<j​effro256:monero.social> Same principle applies in Jamtis

<h​ardhatter:monero.social> Thanks guys I appreciate it

binaryFate: I had no idea we were using a specific version in the first place. Looking at what commit did this, it's the same account reverting it, and the original patch touched many projects. So it seems very non malicious to me.

<j​effro256:monero.social> Specific version of what?