binaryFate, TY

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?

it's probably used in the files that include miner.h. The quickest answer would be to try removing it and then compiling.

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

would it make sense that all monero txs include a decoy script so that txs would all look "the same" ?

I don't like that phrasing

sorry

No, it's nothing against you

not that technical

I know

The reverse is possible. It wouldn't be an atomic swap unless BOTH parties received funds and both do.

The comment is that the fact BTC must always move first opens up a DoS against market makers. That's it.

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.

Whereas one doesn't need such a system to be generally free of DoSs. They both still have DoS vulnerability.

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

I see ... I guess I misunderstood the issue

*And by marketing, I mean groups saying it's infeasible/impossible to do swaps in either direction

I though the issue was technical

on monero side

due to the very limited scripting available

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.

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.

It doesn't remove said risk; key word is reduction.

I see

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.

Anyways. Rant aside. Scripts aren't private

So yes, every TX could have a scirpt, but it'd be obvious they're dummy scripts versus swap scripts.

That isn't helpful.

fair enough

Good thought though :) Great to see people taking an interest and discussing it

Sorry if I scared you off with my rant :P

I just thought of something like ringct for scripts hahhaa

nah you didn't

:)

Monero locking up first is possible if Ring Sigs have an adaptor signature defined IIRC

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.

*at least, with the time they invested

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

Not to mention the theory/impl would change next time Monero updates which is... a pain

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.

I would advocate for a signing algorithm enabling a VDF sig > a signing algorithm without one known though.

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.

But I'm not a core dev and no where near technically competent enough to do the cryptography :P So grain of salt here.

kayabaNerve, thanks a bunch for the details this helps in understanding the concerns/challenge

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 ;)

sure I also appreciate that people are looking into and working on this

most exciting feature after randomx for me

well "feature"

Definitely great with a lot of exciting dev! I've been considering throwing my hat back into the ring.

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

adaptor secret key that makes a channel state update transaction valid).

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.

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.

And the key image point decoder, which I assume is used for all points to be honest, also bans unreduced points...

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

.merges

.merge+ 7781 7782 7776 7789 7771 7772 7769 7765 7758

Added

.merge+ 7745 7744

Added