<t​rasherdk:monero.social> images.png

<t​rasherdk:monero.social> If you need some graphics to go with the announcement, here's one:

<b​asses:matrix.org> bruh this is MRL room

<m​onerobull:matrix.org> vigorswap.io/downloads/MoneroNonCustodialVigorswap.pdf

<m​onerobull:matrix.org> is this of any value?

<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.

<s​yntheticbird:monero.social> trustless they said...

<m​onerobull:matrix.org> thats kind of how i understood it as well

<m​onerobull:matrix.org> i was so confused and thought i might be missing something

<k​ayabanerve:matrix.org> SyntheticBird: "non-custodial" is the one I saw, but it's not that either.

<s​yntheticbird:monero.social> kayabanerve: mamma mia, he is either a scammer or clueless then.

<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? monero-project/research-lab #125#issuecomment-2448077632

<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.

<r​ucknium:monero.social> Step 2 of "Timeline of proposed solution" is "Wait for that block `J` to be mined on mainnet/stagenet/testnet"

<r​ucknium:monero.social> Interesting discussion about the code logic and prediction error due to difficulty adjustments, of course.

<k​ayabanerve:matrix.org> Rucknium: It's do we want to warn people with a date or with a block number?

<k​ayabanerve:matrix.org> My advocacy is a date

<s​yntheticbird:monero.social> a date make more sense indeed

<r​ucknium:monero.social> Date also sounds like a good choice to me.

<r​ucknium:monero.social> New MRL issue: "Discussion: preventing P2P proxy nodes" monero-project/research-lab #126

<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

<r​ucknium:monero.social> I'll put this on the next meetings's agenda

<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

<j​effro256:monero.social> The logic isn't too bad, its just slightly more complicated than a hardcoded height

<j​effro256:monero.social> I'm not against using a median time though

<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

<k​ayabanerve:matrix.org> Are we not already yielding headers in get_blocks.bin?