04:50:33 <m-relay> <t​rasherdk:monero.social> images.png
04:50:36 <m-relay> <t​rasherdk:monero.social> If you need some graphics to go with the announcement, here's one:
08:28:15 <m-relay> <b​asses:matrix.org> bruh this is MRL room
12:55:13 <m-relay> <m​onerobull:matrix.org> https://vigorswap.io/downloads/MoneroNonCustodialVigorswap.pdf
12:55:35 <m-relay> <m​onerobull:matrix.org> is this of any value?
14:34:45 <m-relay> <k​ayabanerve:matrix.org> monerobull: They seem to be generating a new wallet per swap and promising to only make/publish one of two transactions.
14:35:34 <m-relay> <s​yntheticbird:monero.social> trustless they said...
14:36:49 <m-relay> <m​onerobull:matrix.org> thats kind of how i understood it as well
14:37:06 <m-relay> <m​onerobull:matrix.org> i was so confused and thought i might be missing something
14:54:05 <m-relay> <k​ayabanerve:matrix.org> SyntheticBird: "non-custodial" is the one I saw, but it's not that either.
14:55:27 <m-relay> <s​yntheticbird:monero.social> kayabanerve: mamma mia, he is either a scammer or clueless then.
15:45:20 <m-relay> <r​ucknium:monero.social> Maybe I'm missing something, but isn't it unnecessary to try to predict the block height of the unlock_time ignore date? https://github.com/monero-project/research-lab/issues/125#issuecomment-2448077632
15:45:21 <m-relay> <r​ucknium:monero.social> The hardcoded height would be introduced into the monerod codebase after the ignore date has already passed, so the appropriate height would be known exactly by that time.
15:46:02 <m-relay> <r​ucknium:monero.social> Step 2 of "Timeline of proposed solution" is "Wait for that block `J` to be mined on mainnet/stagenet/testnet"
15:50:24 <m-relay> <r​ucknium:monero.social> Interesting discussion about the code logic and prediction error due to difficulty adjustments, of course.
19:36:10 <m-relay> <k​ayabanerve:matrix.org> Rucknium: It's do we want to warn people with a date or with a block number?
19:36:16 <m-relay> <k​ayabanerve:matrix.org> My advocacy is a date
19:42:20 <m-relay> <s​yntheticbird:monero.social> a date make more sense indeed
19:46:42 <m-relay> <r​ucknium:monero.social> Date also sounds like a good choice to me.
19:48:08 <m-relay> <r​ucknium:monero.social> New MRL issue: "Discussion: preventing P2P proxy nodes" https://github.com/monero-project/research-lab/issues/126
19:48:09 <m-relay> <r​ucknium:monero.social> > This means from the data I [Boog900] have it looks like ~40% of the IPs running Monero nodes are not real nodes
19:48:29 <m-relay> <r​ucknium:monero.social> I'll put this on the next meetings's agenda
21:03:56 <m-relay> <j​effro256:monero.social> On the wallet side it would entail a bit more RPC logic of parsing block timestamps and calculating medians, but I think this could be done during refresh
21:04:30 <m-relay> <j​effro256:monero.social> The logic isn't too bad, its just slightly more complicated than a hardcoded height
21:04:48 <m-relay> <j​effro256:monero.social> I'm not against using a median time though
21:07:28 <m-relay> <j​effro256:monero.social> I'm not really all that worried about the height transferring over to testnet and stagenet on account of them being testnets and stagenets and heights and activation dates being all of out wack anyways
21:27:17 <m-relay> <k​ayabanerve:matrix.org> Are we not already yielding headers in get_blocks.bin?