00:50:42 <jeffro256[m]> <Rucknium[m]> "tobtoht: Could the blackballing..." <- Do you p2pool in mind when asking this? Decoy selection needs adjustment for p2pool IMO
00:52:32 <tobtoht[m]1> jeffro256: See https://github.com/monero-project/research-lab/issues/109
01:03:26 <Rucknium[m]> jeffro256: Yes. I wonder if it could be accomplished without waiting for the next hard fork.
02:00:43 <Alex|LocalMonero> <UkoeHB> "Also Alex | LocalMonero | AgoraD..." <- https://github.com/monero-project/monero/issues/8757 🫡
03:00:51 <monerodtxproxy[m> paying 10 XMR to the first core developer who can solve a dispute between myself and ofrnxmr
03:00:59 <monerodtxproxy[m> will be a good learning experience for all
03:01:15 <monerodtxproxy[m> ofrnxmr: 
03:01:18 <ofrnxmr[m]> #monero-offtopic:monero.social 
03:01:30 <monerodtxproxy[m> this is about development
03:01:41 <monerodtxproxy[m> because if things arent as i think they are i will develop the solution
03:03:09 <ofrnxmr[m]> Pay a dev to do your homework. To prove me wrong? You cant even read. Im dont talking to you and id appreciate it if you stopped annoying me with your lack of understanding
03:03:56 <monerodtxproxy[m> if i am using --tx-proxy, do i have any guarantees that a tx will not get sent out on same circuit twice? if i am not using --tx-proxy am i relying on dandelion to prevent multiple txs from being linked?
07:26:43 <jeffro256[m]> hyc will a normal call to mdb_cursor_put with no flags return MDB_KEYEXIST if the key already exists?
08:48:42 <jeffro256[m]> hmmm also the lines ```check_open();
08:48:42 <jeffro256[m]> mdb_txn_cursors *m_cursors = &m_wcursors;
08:48:42 <jeffro256[m]> CURSOR(properties);``` causes a segfault 
08:49:01 <jeffro256[m]> in db_lmdb.cpp
08:50:14 <jeffro256[m]> *When adding code not as-is
09:22:07 <jeffro256[m]> rbrunner: Would you like to check out https://github.com/rbrunner7/monero/pull/5 ?
09:22:57 <jeffro256[m]> The blockchainDB stuff looks scary but it's just a bunch of boilerplate to load/save the m_cookie value 
09:23:57 <jeffro256[m]> This should alleviate some node privacy concerns as well as system time inconsistency problems while keeping the interface simple 
09:30:55 <moneromooo> This seems to leave an inconsistent state if the process crashes, machine loses power, etc. m_cookie grows in memory without writing to the db.
10:02:37 <rbrunner> Will have a look, maybe later today. I would like to invite jberman[m] also to comment whether this is improvement enough to be worth pushing this through another round of review, testing, and make the PR more complicated still.
10:05:00 <rbrunner> I am not devaluing your contribution, just suffering from fatigue regarding this PR :)
12:48:41 <hyc> jeffro256[m]: no, only if you specify MDB_NOOVERWRITE
12:51:16 <hyc> the cursor_put flags are already explicitly documented. http://www.lmdb.tech/doc/group__mdb.html#ga1f83ccb40011837ff37cc32be01ad91e
17:36:50 <Alex|LocalMonero> Anyone know of an online tool to decode a pasted tx hex into a human-readable format? Google doesn't turn up anything
17:40:33 <sech1> https://xmrchain.net/tx/d3f526feb643829326b38cea8608777d45db5edd7efbf55ec44cc8eecabb7d0a/1
17:40:39 <sech1> scroll down to "show json"
17:47:16 <moneromooo> I guess if you have a web server, you could run monero-utils-deserialize as a CGI, should be pretty simple.
17:49:01 <moneromooo> Though it takes its input as "--input <hex>", not on stdin, so you'd need a shell script in the middle, but it's a simple one.
17:49:54 <Alex|LocalMonero> Thanks!
18:46:14 <jeffro256[m]> <moneromooo> "This seems to leave an inconsist..." <- This is true. I was trying to make it have the least overheard possible, but I could definitely have it write to the DB when modified to fix that problem 
18:47:34 <jeffro256[m]> <rbrunner> "I am not devaluing your contribu..." <- I know, I know. It’s been open for over a year , I totally feel you. I’m sorry I didn’t review it earlier but I think this change will really be worth it because it will make wallet users/devs lives much easier 
19:18:02 <jeffro256[m]> <hyc> "the cursor_put flags are already..." <- Yes, I did take a look at the documentation, thanks. The documentation does a god job documenting the flags, but IMO doesn't clearly specify what the flagless behavior is 
19:18:58 <moneromooo> A "and" of the negations of all the flags, presumably.