04:51:34 binaryFate, TY 06:14:39 Probably trivial: but I'll ask. Why is windows.h included in src/cryptonote_basic/miner.h when it is not used later in the header file? 06:17:09 it's probably used in the files that include miner.h. The quickest answer would be to try removing it and then compiling. 11:08:34 guys I understand that for the atomic swaps btc -> monero is possible because btc scripting is enough but the reverse isn't, I also understand that having scripting on monero side would make scripted txs stand out from others and we don't want that since it could break anonymity 11:08:59 would it make sense that all monero txs include a decoy script so that txs would all look "the same" ? 11:09:01 I don't like that phrasing 11:09:06 sorry 11:09:11 No, it's nothing against you 11:09:16 not that technical 11:09:20 I know 11:09:32 The reverse is possible. It wouldn't be an atomic swap unless BOTH parties received funds and both do. 11:09:47 The comment is that the fact BTC must always move first opens up a DoS against market makers. That's it. 11:10:14 It's not that you can't have a system where you can buy XMR or can't have a system where you sell XMR. You just will perform much better if one of those systems also has a reputation system. 11:10:39 Whereas one doesn't need such a system to be generally free of DoSs. They both still have DoS vulnerability. 11:10:59 I completely respect the work of multiple parties involved with this but I hate the marketing going out about this and just wanted to throw my hat in the ring 11:11:14 I see ... I guess I misunderstood the issue 11:11:18 *And by marketing, I mean groups saying it's infeasible/impossible to do swaps in either direction 11:11:44 I though the issue was technical 11:11:48 on monero side 11:11:59 due to the very limited scripting available 11:12:07 Because I know of one group who's said it's not possible (not part of the XMR community; just one I very much dislike who has looked into it) and one group who said it's difficult to the point we have people thinking it's not possible. 11:12:30 That said, the rest of your commentary is valid to a degree. Monero would need scripts, or a different signature system, for Monero to lock up first which reduces the risk of a DoS. 11:12:38 It doesn't remove said risk; key word is reduction. 11:12:54 I see 11:13:16 I think it'd be great to remove that risk and I fully acknowledge it's difficult/annoying. I just hate the way people discuss it to the point it's perceived impossible. Even without a bond/rep system, it's still possible and can even be practical. 11:13:29 Anyways. Rant aside. Scripts aren't private 11:13:42 So yes, every TX could have a scirpt, but it'd be obvious they're dummy scripts versus swap scripts. 11:13:45 That isn't helpful. 11:13:55 fair enough 11:14:10 Good thought though :) Great to see people taking an interest and discussing it 11:14:17 Sorry if I scared you off with my rant :P 11:14:22 I just thought of something like ringct for scripts hahhaa 11:14:27 nah you didn't 11:14:37 :) 11:14:40 Monero locking up first is possible if Ring Sigs have an adaptor signature defined IIRC 11:15:26 They just don't have one as of right now. I honestly don't remember the cryptography/protocol well enough to comment fully. I'd assume it's possible to do such an adaptor signature, just a lot of research where the existing people who tried couldn't crack it. 11:15:54 *at least, with the time they invested 11:16:40 And then it'd need a modified signing algorithm and honestly, that's annoying as hell given the scope and scale of RingCTs. I would NOT want to be the persona ssigned to that :P 11:16:53 Not to mention the theory/impl would change next time Monero updates which is... a pain 11:17:31 So yes, the easy way out is scripts, yet that has privacy concerns to some degree. I personally just don't think XMR should have scripts in general. It's a decent attack surface and not needed in a currency IMO. 11:17:50 I would advocate for a signing algorithm enabling a VDF sig > a signing algorithm without one known though. 11:18:29 So if it's not possible under X, yet with Y modification it's made possible... I'd consider that a very appealing trade off depending on what it gave. If Monero does go out of its way to support swaps, that's as far as I think it should go. 11:18:44 But I'm not a core dev and no where near technically competent enough to do the cryptography :P So grain of salt here. 11:24:06 kayabaNerve, thanks a bunch for the details this helps in understanding the concerns/challenge 11:27:14 Happy to do so. Again, I am a bit out of date, and I do respect COMIT for their work. Just have a differing opinion on this matter and its presentation ;) 11:28:08 sure I also appreciate that people are looking into and working on this 11:28:26 most exciting feature after randomx for me 11:28:34 well "feature" 11:32:48 Definitely great with a lot of exciting dev! I've been considering throwing my hat back into the ring. 12:35:47 Just to push on the other direction, of what muhkey suggests. The path for `contracts` running on monero: 1 introduce tx chaining + other primitives needed for payment channels, 2 create functional payment channel, 3 (other possibilities here) use payment channel state update with specially crafted adaptor keys (e.g., make the witness data of a finalized contract state update the 12:35:49 adaptor secret key that makes a channel state update transaction valid). 14:35:43 The fact PayMo exists shows workarounds exist, and I believe ZCash has its own investigation into a LN under similar circumstances. To be clear, PayMo isn't feasible (at all, unfortunately), yet I want to provide a counterbalance to calls for those features. Not to mention, TX chaining isn't possible even with contracts. 14:36:48 Actually, I'd need to double check the Ed25519 rules. All subgroups that aren't the primary should be banned from RingCTs. I also believe -0 is banned; I know it is for key images. 14:37:38 And the key image point decoder, which I assume is used for all points to be honest, also bans unreduced points... 14:38:16 But it also isn't Ristretto so I wouldn't say without further consideration it's possible to chain. Maybe you've done all the needed double checks though :P 19:11:18 .merges 19:11:18 -xmr-pr- 7692 7693 7698 7718 7740 19:19:21 .merge+ 7781 7782 7776 7789 7771 7772 7769 7765 7758 19:19:22 Added 19:27:59 .merge+ 7745 7744 19:27:59 Added