07:13:06 From a discussion on Reddit I just now became aware that removing timelocks is not on list of scheduled things for the next hardfork: https://github.com/monero-project/meta/issues/630 07:13:44 And, as dEBRUYNE correctly explained there, we don't have any PR to remove it either 07:14:16 Probably a missed chance to not formally decide in the dev meeting yesterday what to do with it 07:14:39 My mistake as well, I should have noted the absence of this point 07:15:08 Background is a IMHO very unfortunate turn of events: It seems somebody built ETH-XMR swaps using timelocks on the Monero side 07:15:31 See: https://old.reddit.com/r/Monero/comments/r4jgrq/bounty_ethxmr_atomic_swaps_are_now_live_on/ 07:15:42 I have a patch to remove it in Townforge, I can probably port it fairly easily. 07:16:32 This does give a new version for transactions, I assume? 07:17:44 We have already something that *is* scheduled to go into the hardfork that also gives a new version, the view tags: https://github.com/monero-project/research-lab/issues/73 07:18:07 Oh, good point. Might be a bit invasive... 07:20:20 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 ... 07:21:26 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 07:22:31 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 07:22:58 elizabethereum's does not 07:23:00 And not yet fully sure with this one as my question was not answered 07:23:20 I don't think crypto bear's did either 07:23:21 It's almost tragic, the situation of this person. 07:24:27 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. 07:24:31 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 07:27:31 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 07:27:51 ^ 07:31:49 > 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. 07:31:54 This is not atomic in the slightest 07:33:22 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 07:34:27 it also looks like they think you can submit a tx to the network that spends locked outputs, which shouldn't be possible 07:35:07 unless nodes hold locked transactions in the pool until they unlock? which I don't think they do, and was double checking 07:35:53 jberman[m]: Not to mention it seems to ssuggest TX replacement. 07:36:12 It says you immediately send a TX to yourself before the other party eventually claims. 07:36:27 We don't exacftly have RBF. 07:36:39 that tx is the one locking the XMR I think 07:37:20 it looks like they think Bob can lock XMR, then give Alex details to relay a tx that spend the locked XMR 07:38:46 I think everything here is whitenoise. We need to focus on a single fact. This has 0 verification of the XMR TX. 07:39:08 It doesn't matter it's untested. It may matter if it has syntax errors in called execution paths (or required execution paths). 07:40:54 * jberman[m] sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/b55a3736827bf6e694709b0a1d7d01a773b18f18 07:41:20 I read it as in step 3, a locked XMR transaction enters the chain 07:41:41 but I guess same inputs means that's not really possible 07:42:08 jberman[m]: I think you're right on flow? But it doesn't change step 5 07:42:22 Alice can lock to H("") and Bob can screw Alice over 07:42:23 The end 07:42:56 right that's what I thought too 07:46:09 So, timelocks or no timelocks, you think that doesn't work for other, unrelated problems either? 07:46:41 > 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. 07:46:52 this isn't how XMR's timelocks work, they don't allow anyone to claim XMR before the lock expires 07:47:43 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 07:48:23 They don't. COMIT looked into it 07:48:47 Yeah ... I have a vague feeling of things going in circles :) 07:50:16 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 07:50:30 they being this piece of shit asshole 07:51:05 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 07:51:26 Timelock removal isn't a good idea IMO 07:51:57 COMIT's work did allow XMR to move first if XMR adaptor signatures were posited IIRC. That said, they still relied on timelocks 07:52:47 on XMR's timelocks? 07:55:28 So removing timelocks forbids XMR move first IIRC 07:55:30 Yeah 07:56:17 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 07:58:55 agh I did check with them, ok. checking again 08:21:00 jberman[m]: https://old.reddit.com/r/Monero/comments/r4jgrq/bounty_ethxmr_atomic_swaps_are_now_live_on/hmid8ra/ 08:21:27 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 08:21:36 rbrunner: Inge for other participants 12:36:55 My monthly report: 12:36:56 https://www.reddit.com/r/Monero/comments/r4sqhv/mjs_dev_report_nov_2021/ 12:36:56 Cheers! 13:02:52 Regarding noot's work, https://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? 13:03:08 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. 13:03:38 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)