11:16:03 <dsc_> hi
11:22:23 <dsc_> https://github.com/sanderfoobar/monero-cmake-modern/
22:41:13 <m-relay> <s​packle_xmr:matrix.org> I think this got some attention recently but I want to point it out. 
22:41:14 <m-relay> <s​packle_xmr:matrix.org> This tx has a high fee per byte but is stuck in the mempool: https://xmrchain.net/tx/12bcfcb24bafcfcb9fe28a78e36c5b4ffec6e65c61ce033ab31c87230f20f70e
22:41:54 <m-relay> <s​packle_xmr:matrix.org> It is the oldest tx by a significant margin.
22:45:42 <sech1> https://paste.debian.net/hidden/0180ff93/
22:45:50 <sech1> "1 double spends"
22:45:53 <sech1> must be this one
22:50:58 <m-relay> <s​packle_xmr:matrix.org> Interesting. Thank you for the quick response.
23:06:12 <m-relay> <r​ucknium:monero.social> sech1: Does that mean that your node was at the "boundary" of the network topology where some of the nodes you connected to sent you one of the double spend txs, and one or more of the other nodes sent you the other double spend tx? Your node would not relay both of the double spends, right?
23:10:29 <sech1> xmrchain node was too
23:11:19 <sech1> No, it's more like this tx was in mempool already, but someone mined a block with a competing tx directly included
23:11:38 <sech1> maybe someone tried to scam some merchant who accepts 0-conf
23:13:29 <m-relay> <r​ucknium:monero.social> Ok. monerod keeps the tx in the mempool in case there is a block re-org and it becomes valid, right?
23:13:29 <sech1> That's my theory
23:13:50 <sech1> yes, it keeps it because it can become valid