02:04:09 <TrasherDK[m]> I got a nasty surprise this morning: `MDB_CORRUPTED: Located page was wrong type`
02:04:23 <TrasherDK[m]> https://paste.debian.net/1248800/
02:36:09 <gingeropolous> what kind of system / OS / etc ...
03:06:43 <TrasherDK[m]> Slackware64 15.0 - `Linux compaq-laptop.fumlersoft.dk 5.15.19 #1 SMP PREEMPT Wed Feb 2 01:50:51 CST 2022 x86_64 Intel(R) Core(TM)2 Duo CPU     T8100  @ 2.10GHz GenuineIntel GNU/Linux`
03:12:02 <TrasherDK[m]> It could have been a nasty attack, as restarting daemon don't complain `Synced 148 blocks in 3.9 minutes (0.629 blocks per second)`
03:48:17 <TrasherDK[m]> Or it could have been leftover stuff from my system upgrade. Found `libssl.so.1.0.0` causing `kernel: curl[12003]: segfault at 0`
08:03:15 <TrasherDK[m]> Well. It appears to be back to normal, so probably leftovers from OS upgrade.
08:11:36 <moneromooo> It likely means a query wasn't made to that page again. So possibly a txpool related page, since you'd expect it to be queried again in the course of adding a block (unless there was a reorg in the meantime which changed what needs to be done to sync the next block).
08:12:16 <moneromooo> In any case, the bad data is probably still there.
11:43:10 <jozsef[m]> I use zmq, as does monero, for network comm developing a p2p monero marketplace [app](https://codeberg.org/piac/piac). Grepping the monero source, I am guessing that no encryption and/or authentication is used between clients (gui, cli) and among peers at the socket level. I wonder if this is something unnecessary for the monero code as a currency but could be useful/important for a marketplace app. Would the monero network not benefit
11:43:10 <jozsef[m]> from socket-level encryption/authentication, via e.g., http://curvezmq.org? Have there been DoS or MITM attacks that could be (or could have been) avoided? Or this is a non-issue...
11:52:36 <moneromooo> You can use SSL between wallet and node if both sides support it.
11:53:19 <moneromooo> There is no encryption on P2P links (though the SSL patch had this, but it got removed prior to merging). AFAIK vtnerd is still working on P2P link encryption, no idea how far along that is though.
11:54:28 <moneromooo> There have been DoS attacks before. Not sure encryption would fix it, unless you can blackball a cert before doing heavy work, and a cert is difficult to create.
11:55:02 <moneromooo> Not sure about MITM, but that's why the SSL patch defaults to accepting only a whitelisted cert (though it might have changed at some point).
11:55:38 <moneromooo> For RPC anyway. For p2p links, who really cares about MITM since they're both attackers anyway.
11:56:56 <moneromooo> Is that "socket-level" ?
11:58:18 <moneromooo> IIRC, the rationale for killing p2p link SSL was "too big/complicated/slow". I believe vtnerd is working on adding "noise", another encryption scheme that's lighter.
11:58:43 <moneromooo> And some other interesting attributes.
12:01:33 <ofrnxmr[m]> iirc Hyc had also brought up a potential move to anonymity networks, or at least enabling block sync for onions (?)
12:01:33 <ofrnxmr[m]> .. dont quote me 
12:03:16 <gowpjmu93[m]> I'll help 20 individuals how to earn $30,000 in just 72 hours  from the crypto market. But you will pay me 10% commission when you receive your profit.   for more details on how to get started 
12:03:16 <gowpjmu93[m]> +1( 539 577 9852
12:34:14 <jozsef[m]> Thanks moneromooo. Yes, that's what I meant by "socket-level".... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/01ef385886f6c952c24ada4085912d06131e1ab3)
13:42:24 <TrasherDK[m]> What would you gain connecting to someone else node zmq, RPC or socket, that you would not get from connecting to your own node?
13:43:25 <moneromooo> Offloading your work to someone else. Which is why many people do it :(
13:43:42 <sech1> You'd gain possible malicious intent of whoever runs the node
13:45:58 <TrasherDK[m]> Yes, but could you gain any knowledge, from a remote, that you could get from your own?
13:46:16 <TrasherDK[m]> * could not get
14:02:20 <ypavtv97lx[m]> With the announcement of minexmr pool closing down, and possibly all miners just going to the next biggest pool on the list I was thinking if integrating xmrig with p2pool (which is very small) and some default remote nodes would increase chance of lazy miners using the decentralized way of mining ?
14:08:04 <TrasherDK[m]> Botnet's operators are scrambling to reconnect with compromised hosts 🤣
16:04:03 <jwinterm[m]> ypavtv97lx: is p2pool mining using a remote node actually feasible in a way that is close to as profitable as mining on a normal pool?
16:04:10 <jwinterm[m]> remote nodes generally speaking seem flaky af
16:07:57 <al800[m]1> jwinterm[m]: Depend of the remote node.
16:07:58 <al800[m]1> I have no issue with my personal remote node
17:54:10 <gut> The coordinates x,y in G generator point of ECC are of each 32 bytes?
19:26:30 <Guest4167> Wht's the value of x coordinate of G
19:31:18 <tevador> 0x216936d3cd6e53fec0a4e231fdd6dc5c692cc7609525a7b2c9562d608f25d51a (big endian)
19:32:24 <Guest4167> Only the x coordinate you gave or whole in one 32 byte
19:34:29 <tevador> This is the the x coordinate.
19:35:38 <tevador> y = 0x6666666666666666666666666666666666666666666666666666666666666658
19:36:14 <Guest4167> Thanks alot
20:30:24 <Guest21> Wht is x,y,z in ge_p2
20:31:22 <Guest21> Why z
20:32:00 <Guest21> As it is made up of only x,y nor it is 3d so why z coordinate
21:02:49 <kayabanerve[m]> Guest21: z is a divisor
21:02:52 <kayabanerve[m]> x = x/z, y = y/z
21:03:41 <kayabanerve[m]> It's more efficient to keep `z` around during operations then constantly normalize it