From a discussion on Reddit I just now became aware that removing timelocks is not on list of scheduled things for the next hardfork: monero-project/meta #630

And, as dEBRUYNE correctly explained there, we don't have any PR to remove it either

Probably a missed chance to not formally decide in the dev meeting yesterday what to do with it

My mistake as well, I should have noted the absence of this point

Background is a IMHO very unfortunate turn of events: It seems somebody built ETH-XMR swaps using timelocks on the Monero side

See: old.reddit.com/r/Monero/comments/r4…ethxmr_atomic_swaps_are_now_live_on

I have a patch to remove it in Townforge, I can probably port it fairly easily.

This does give a new version for transactions, I assume?

We have already something that *is* scheduled to go into the hardfork that also gives a new version, the view tags: monero-project/research-lab #73

Oh, good point. Might be a bit invasive...

If I look at the whole situation I would guess we are too late already to remove in *this* hardfork - if our famous "loose consensus" to remove will hold at all ...

if this is making legitimate use of timelocks, which I don't think it is at this point (I'm working my way through it/thinking on it), it would be a solid reason to keep timelocks imo

Well, hard to say, I think this is now the third proposal for ETH-XMR atomic swaps, and no idea whether the other two rely on XMR timelocks

elizabethereum's does not

And not yet fully sure with this one as my question was not answered

I don't think crypto bear's did either

It's almost tragic, the situation of this person.

maybe someone who has little experience with monero or bitcoin style development - little empathy with the NEED to understand that things are actually atomic and trustless.

It might be that further discussion will have the result that this protocol is not sound, or at least not trustless, but I don't know enough to judge myself

fuck it, I'm too pissed for a measured response. on quick read, I don't think it's an atomic swap, I think it would be fairly trivial to claim both the ETH and XMR. even if I'm wrong, this person is going way overboard being a fucking dickhead. I'm working through it to be certain

^

> How can we account for these 2 vulnerabilities? The answer, I believe, is simply to automate the process. By creating a user interface(UI) that automatically carries out the metadata-hash generation and validates the self-transaction was constructed and posted successfully, Bob has no control over the process.

This is not atomic in the slightest

Once Bob claims the ETH, it looks like it's just a race to submit a Monero tx to claim the Monero once it unlocks

it also looks like they think you can submit a tx to the network that spends locked outputs, which shouldn't be possible

unless nodes hold locked transactions in the pool until they unlock? which I don't think they do, and was double checking

jberman[m]: Not to mention it seems to ssuggest TX replacement.

It says you immediately send a TX to yourself before the other party eventually claims.

We don't exacftly have RBF.

that tx is the one locking the XMR I think

it looks like they think Bob can lock XMR, then give Alex details to relay a tx that spend the locked XMR

I think everything here is whitenoise. We need to focus on a single fact. This has 0 verification of the XMR TX.

It doesn't matter it's untested. It may matter if it has syntax errors in called execution paths (or required execution paths).

I read it as in step 3, a locked XMR transaction enters the chain

but I guess same inputs means that's not really possible

jberman[m]: I think you're right on flow? But it doesn't change step 5

Alice can lock to H("") and Bob can screw Alice over

The end

right that's what I thought too

So, timelocks or no timelocks, you think that doesn't work for other, unrelated problems either?

> F3) Bob tries to claim both types of funds: After Bob claims Alex's ETH, his timelock is still in effect, giving Alex the chance to claim Bob's XMR before he does.

this isn't how XMR's timelocks work, they don't allow anyone to claim XMR before the lock expires

so it just seems fundamentally flawed because of how it uses timelocks. I still don't see how Monero's timelocks can enable atomic swaps

They don't. COMIT looked into it

Yeah ... I have a vague feeling of things going in circles :)

someone could challenge this person to a wild west duel where they have ETH, and gunslinging hero coder has XMR and ends up with both

they being this piece of shit asshole

But anyway, the question is whether the removal of timelocks already missed the deadline for this HF, or whether we mount a concerted effort to slip them in, or whether consensus is not strong enough anyway, and we re-open discussion

Timelock removal isn't a good idea IMO

COMIT's work did allow XMR to move first if XMR adaptor signatures were posited IIRC. That said, they still relied on timelocks

on XMR's timelocks?

So removing timelocks forbids XMR move first IIRC

Yeah

Sorry, had to step away. I'm not up to date, and you'd want to check with them. There's also remaining privacy concerns ofc with them, not to mention suboptimal code forced to be included in the node

agh I did check with them, ok. checking again

jberman[m]: old.reddit.com/r/Monero/comments/r4…tomic_swaps_are_now_live_on/hmid8ra

I mean, it's not like XMR moves first is currently possible anyways. Removing XMR timelocks is just an already implemented feature and a required stepping stone

rbrunner: Inge for other participants

My monthly report:

Cheers!

Regarding noot's work, github.com/noot/atomic-swap, I have two comments. 1) It looks like they moved the DLEq proof to Ethereum as a PTLC which is... fascinating?

It's probably the quickest way to get this up and running given the network at hand but really a PoC type of thing. It should add a couple hundred K gas to any usage, further making ETH mainnet unviable. Definitely could be optimized out later though.

But with regards to the bounty, I don't believe this is currently a tested implementation as per criteria > test cases for failure cases (unit and integration tests)