00:30:40 Network layer metadata? 15:31:13 <0x1zxq7896lp2zero:monero.social> monero only have dandelion++ and that too for full node 15:31:34 <0x1zxq7896lp2zero:monero.social> sure tor i2p overlay network can help 15:31:52 <0x1zxq7896lp2zero:monero.social> but monero need more network layer privacy 15:32:54 <0x1zxq7896lp2zero:monero.social> monero only have dandelion++ and that works for full node privacy 15:35:50 end-to-end node encryption plus dandelion++ plus dummy stem payloads would basically hide almost all network level activity, even from ISPs theoretically 15:38:42 <0x1zxq7896lp2zero:monero.social> better then some other coin that's true 👍️ 16:11:48 Go review https://github.com/monero-project/monero/pull/8996 if you want to see node E2E encryption happen 16:17:53 <0x1zxq7896lp2zero:monero.social> yep it's a good direction anyway 16:42:16 maybe from ISP but traffic pattern analysis is still something very effective in monerod case 16:43:08 there are no packet timing obfuscation 16:43:18 there are no packet timing paddings at the moment 16:43:29 Yes not currently: I should have clarified that better 19:12:49 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: 19:12:51 https://github.com/monero-project/monero/pull/9368 19:13:58 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 19:14:47 As we see it, a statement from tobtoht would be quite interesting 19:14:59 Thanks! 21:09:03 https://monero.stackexchange.com/questions/10780/how-does-one-burn-and-provide-a-proof-of-burn-in-monero#10783 21:09:20 Is this still a valid method^ for proof of burn? 21:32:06 moneromooo: can you sanity check this? https://github.com/google/oss-fuzz/pull/12009 21:33:43 There is randomized padding but no dummy packets (yet) in that SSL patch 21:39:47 I don't see reason to not 21:40:12 Block notifications are not padded for efficiency reasons - one message is serialized then ref counted to each connection queue 21:41:08 And it will still work after fcmp? 21:43:03 it should work until the address system gets change for example Seraphis 21:44:31 Do you think it would be trivial to come up with a similar method for proof of burn after Seraphis? 21:46:05 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 21:46:26 no i dont think so, Seraphis would have optional privacy 21:47:14 Wdym by "optional privacy"? All officially supported addressing schemes have been "optionally private" 21:48:46 i mean you can share your private view or transaction key with anyone if you want 21:50:36 How does that affect burn proofs? 21:52:50 Burn proof is just sharing an OutProof or Tx Secret 21:53:25 Same principle applies in Jamtis 21:56:43 Thanks guys I appreciate it 23:00:09 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. 23:41:31 Specific version of what?