06:58:42 <jeffro256[m]> Hey was the ci build for windows changed recently ? It's erroring out right now 
07:18:48 <jeffro256[m]> I submitted a PR that I think will fix that error but I don't compile on Windows so maybe someone can double check it works after I run it thru CI (assuming it works)
07:23:56 <sech1> definitely DWORD there
07:25:31 <jeffro256[m]> sech1 thanks for looking at it
07:25:54 <jeffro256[m]> Using CI as my windows compiler rn hehe oops 
07:47:13 <jeffro256[m]> phew it passed, was really hoping patching it wouldn't expose 30 more identical instances of the error 
10:44:41 <hmd2v[m]> Hello everyone, I'm HMD2V. I'm working on making a bridge from Algorand to Monero, inspired by the talk on BTC<->XMR bridge by h4sh3d, the paper and what the Comit team has done and written.
10:44:41 <hmd2v[m]> I'm still quite new to Monero development but I've been playing around with it after work the last couple of weeks. Still I'm wondering if there is anyone here who'd be up for answering some questions of mine? Specifically related to the python-monero wrappers (doing everything in Python is more convenient) and how to do certain things with the wallet cli tool over rpc.
10:44:41 <hmd2v[m]> Thanks everyone.
10:45:57 <hmd2v[m]>  * Hello everyone, I'm HMD2V. I'm working on making a bridge from Algorand to Monero, inspired by the talk on BTC\<->XMR bridge by h4sh3d, the paper and what the Comit team has done and written.
10:45:57 <hmd2v[m]> I'm still quite new to Monero development but I've been playing around with it after work the last couple of weeks. Still I'm wondering if there is anyone here who'd be up for answering some questions of mine? Specifically related to the python-monero wrappers (doing everything in Python is more convenient as you can write Algorand smart contracts in Python) and how to do certain things with the wallet cli tool over rpc.
10:45:57 <hmd2v[m]> Cheers
10:47:09 <sech1> if you have specific questions about monero-wallet-rpc, just ask. You use monero-wallet-rpc, not -cli, right?
10:48:37 <hmd2v[m]> Indeed.
10:49:02 <merope> hmd2v: (fyi this channel is bridged to irc, so avoid making too many edits to your messages, otherwise it creates a lot of noise on the irc side)
10:59:43 <ooo123ooo1234[m]> > <@hmd2v:matrix.org> Hello everyone, I'm HMD2V. I'm working on making a bridge from Algorand to Monero, inspired by the talk on BTC\<->XMR bridge by h4sh3d, the paper and what the Comit team has done and written.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0fa53cb9cd20a811e6548b8f7d66ba41c62a6257)
11:01:31 <hmd2v[m]> Basically I want to be able to generate a wallet from keys. In the protocol, Alice and Bob exchange monero keys (public spend, secret and public view) and add the pub spend keys (ed25519 points) together to get a new pub spend key. Bob then seeds the new pub key with his monero, which Alice can gain access to if... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a1fa3816e6a5db377ec45021c43de6f2cb2c5f4f)
11:02:21 <hmd2v[m]> ooo123ooo1234[m]: https://www.youtube.com/watch?v=G-v6hDnzpds
11:02:21 <hmd2v[m]> https://github.com/comit-network/xmr-btc-swap
11:02:21 <hmd2v[m]> https://www.youtube.com/watch?v=Jj8rd4WOEy0
11:02:21 <hmd2v[m]> https://comit.network/blog/2020/10/06/monero-bitcoin/
11:02:28 <moneromooo> FYI, long messages are elided, and replaced by a URL.
11:08:15 <ooo123ooo1234[m]> hmd2v: bridge != atomic swap
11:08:40 <ooo123ooo1234[m]> > <@hmd2v:matrix.org> Basically I want to be able to generate a wallet from keys. In the protocol, Alice and Bob exchange monero keys (public spend, secret and public view) and add the pub spend keys (ed25519 points) together to get a new pub spend key. Bob then seeds the new pub key with his monero, which... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2c1103759e2fd12c98ca22ec4580a81b9f8527d5)
11:09:29 <kayabanerve[m]> > <@hmd2v:matrix.org> Basically I want to be able to generate a wallet from keys. In the protocol, Alice and Bob exchange monero keys (public spend, secret and public view) and add the pub spend keys (ed25519 points) together to get a new pub spend key. Bob then seeds the new pub key with his monero, which Alice... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/76db666014ecd757b0f2493eca36d2ebaf19ef43)
11:10:17 <hmd2v[m]> ooo123ooo1234: fair enough
11:10:42 <kayabanerve[m]> If you want to try something potentially simpler, and know rust, there's a largely modular proof of concept available (doesn't save to disk and so on, preventing recommendation for real world usage) btw
11:10:58 <ooo123ooo1234[m]> bridge is just network app that can be written by any one and it implies trust to bridge operator; but atomic swap is complex protocol suitable for p2p since it can be used by untrusted parties
11:11:22 <kayabanerve[m]> You don't have to do it in entirely from scratch in python just to move past btc bias
11:12:37 <kayabanerve[m]> Anyways. That should be the rpc route. It should create a new file itself for the name you specify. There should be publicly available address encoders for Python. It's also easy enough to test this with curl :p
11:17:09 <hmd2v[m]> Thing is I dont know Rust and, while I am not averse to learning new languages, I really dont think it is needed in this case. The only thing I'm doing is calling on LibSodium bindings to add two private spend keys.
11:17:44 <hmd2v[m]> Then it'll be a matter of creating a swap daemon, cli tool, server functionality so it can connect to other swappers.
11:18:37 <hmd2v[m]> Finally, the Algorand Virtual Machine is partially built on top of LibSodium. It'll just be a matter of exposing _crypto_scalarmult_ed25519_base as an operation available to smart contracts.
11:28:04 <HenryHollingwort> what does it mean to generate a wallet from keys? if it is get the wallet's address then that can be done rather simply following the method outlined in the mastering moneo book. From there you know the address which Bob needs to transfer the monero to
11:28:19 <HenryHollingwort> i am a noob so I could be missing something or a lot
11:28:39 <HenryHollingwort> *getting the wallet address using the keys
11:31:00 <HenryHollingwort> i mean there is no problem spawning the wallet rpc client w/ a fake wallet and then calling the the method is a little bit awkard but hey just wrap it - the only downside i can think of is you introduce reliance on spawning process, filesystem etc.. which could reduce reliability of code
11:31:55 <kayabanerve[m]> <hmd2v[m]> "Thing is I dont know Rust and..." <- I really think you're underestimating this. You also need a DLEq proof 
11:32:03 <kayabanerve[m]> That's not a light piece of cryptography
11:32:45 <kayabanerve[m]> HenryHollingwort: It's creating a wallet file for the daemon to work with with a specific set of private keys. It's kinda like restoring from a seed, except... Numbers instead of words turned into numbers.
11:33:25 <kayabanerve[m]> kayabanerve[m]: You also need adaptor signatures hmd2v: 
11:34:23 <kayabanerve[m]> So it's two cryptographic constructions beyond addition, which is trivial, and then as you say, you need the actual service + interface for it
11:35:44 <HenryHollingwort> kayabanerve[m]: i meant more what is he then trying to achieve - if it just creating it to compute the address for the transfer you can do it without needing to make a wallet file for the rpc client (ditto for verifying - just need daemon connection and scan the blocks)... though at that stage it way be worth actually creating the wallets and using the rpc lol
11:36:07 <kayabanerve[m]> Also, if you do refer to the MRL paper for a dleq proof, please note it has an error and needs to be supplemented with a proof of knowledge
11:36:26 <hmd2v[m]> Why do you need a DLEq proof? That's to bridge the ed25519 Secp256k1 gap right?
11:36:51 <kayabanerve[m]> HenryHollingwort: Atomic swaps create a naive 2-2 multisig, so you create a private key and then end up spending from another
11:36:57 <kayabanerve[m]> hmd2v[m]: ... Is algorand ed25519?
11:37:24 <kayabanerve[m]> hmd2v[m]: Because you wouldn't if so. You would still need adaptor signatures though those are easier to implement
11:37:46 <hmd2v[m]> Yes Algorand is ed25519
11:38:39 <kayabanerve[m]> Got it. Didn't realize that, sorry.
11:39:15 <kayabanerve[m]> In that case, it's adaptor signatures and key addition and signatures working as proof of knowledges.
11:39:40 <hmd2v[m]> No worries 👍🏾 I also had to confirm t with Noot who is making the eth<->XMR swap because it seemed too easy lol
11:40:19 <kayabanerve[m]> *A PoK can be constructed by any signature for a public key which signs itself.
11:41:18 <kayabanerve[m]> And Ed25519 signatures naturally include themselves so technically ed25519.Sign("PoK") would be sufficient, yet it'd probably be good form to include the key again just to be explicit about it and mindful of other schemes which may not
11:41:36 <kayabanerve[m]> hmd2v[m]: Yeah, we actually had a really interesting discussion about that lol
11:42:10 <kayabanerve[m]> They didn't have ed25519 available natively but they did replace the DLEq proof with an on chain SC which...
11:42:33 <ooo123ooo1234[m]> https://github.com/HashMapsData2Value/gjallarbru
11:42:39 <kayabanerve[m]> Which has the irony of not relying on the XMR atomic swap protocol as we know it and having been possible for years
11:43:05 <ooo123ooo1234[m]> https://github.com/algorandfoundation/ARCs/issues/92, proposed protocol for atomic swap
11:43:14 <ooo123ooo1234[m]> for a more focused discussion
11:43:22 <ooo123ooo1234[m]> s/a//
11:43:41 <ooo123ooo1234[m]> hmd2v: you would better start from link to your repo, instead of asking how to use monero python lib
11:43:42 <ooo123ooo1234[m]> hahahaha
11:44:00 <kayabanerve[m]> ooo123ooo1234[m]: Wow do I not like this
11:44:11 <kayabanerve[m]> Why would you introduce a new op code?
11:44:38 <kayabanerve[m]> > cryptography exists
11:44:38 <kayabanerve[m]> > Is this a reason to hard fork a protocol and bloat a chain with unnecessary data?
11:44:52 <ooo123ooo1234[m]> kayabanerve[m]: Am i doing bad or good thing with posting that link ? Can't understand you
11:45:07 <kayabanerve[m]> I don't like what it details
11:45:26 <kayabanerve[m]> The link itself is helpful, though it did make me wonder how off topic we're getting
11:45:48 <kayabanerve[m]> hmd2v: if you're proposing a hard fork, when algorand has scs, you're doing it wrong. End of story
11:45:49 <ooo123ooo1234[m]> kayabanerve[m]: As long as it's related to atomic swap with monero it is not off-topic
11:46:12 <kayabanerve[m]> Tbf now I'm criticizing an algorand protocol design proposal
11:46:19 <ooo123ooo1234[m]> If it's already clear why this protocol doesn't work then explain and this discussion can be stopped
11:46:58 <kayabanerve[m]> > The company Comit took that paper and turned it into an MVP, which is described in this blog post and this video presentation. Joël, aka H4sh3d, also made this presentation.
11:47:05 <kayabanerve[m]> This isn't even a good explanation of the history :(
11:47:27 <kayabanerve[m]> ooo123ooo1234[m]: His readme advocates for a hard fork to algorand. I'm commenting that's a horrible decision
11:48:37 <kayabanerve[m]> Not to mention, you may be able to use ed25519 verify AS x*G == R?
11:48:54 <kayabanerve[m]> You shouldn't need a hard fork. This op should already exist. They just don't know if
11:49:02 <kayabanerve[m]> s/if/it/
11:50:04 <kayabanerve[m]> hmd2v: Verifying a signature crafted so the public key is X, the R is 0, and the s is the private key (or its negative) will be a sk -> pk verification 
11:50:42 <kayabanerve[m]> All you'd have to do is verify they used a 0 R, or if those are banned, a known R. Can you do a byte comparison of the signature before calling ed25519 verify?
11:51:52 <kayabanerve[m]> Because if so, not only is this still a bad protocol beyond a proof of concept because you're placing this on chain instead of implementing the cryptographic protocol established, but you should never have proposed a hard fork for this
11:52:37 <kayabanerve[m]> You even note how n00t moved to the cryptographic solution .-.
11:53:11 <kayabanerve[m]> It's fine for a proof of concept. The issue is when you make a RFC suggesting a hard fork despite the solutions being in front of you .-.
11:54:08 <ooo123ooo1234[m]> +1000 for critical thinking
12:04:12 <ofrnxmr[m]> <ooo123ooo1234[m]> "As long as it's related to..." <- For -Dev? I think it is off topic.. 🙃
12:04:49 <hmd2v[m]> kayabanerve: Ah Cunningham's Law - post the wrong solution and get the right answer back 😃
12:04:49 <hmd2v[m]> I agree that this is off-topic but I'd love to continue talking to you. 
12:06:11 <ofrnxmr[m]> #monero-research-lounge:monero.social  is more open
12:11:46 <monerobull[m]> Stagenet forks next 16th, right?
12:12:01 <GuruJi[m]> Anyone here aware of any plan or project where one can hedge XMR directly in a DEX way? 
12:16:01 <GuruJi[m]> It is possible now to do that only with BTC, but I am not comfortable with giving up the XMR for the Voyeur peep show coin, undermining the value of XMR
12:17:06 <kayabanerve[m]> s/n00t/noot/
12:20:30 <bubble101[m]> your symbol order is wrong, it should show btc/xmr
12:20:30 <bubble101[m]>  1xmr * 0.00649 xmr / btc =  0.00649 btc
12:21:12 <bubble101[m]> on https://unstoppableswap.net/
12:24:25 <w[m]> <GuruJi[m]> "Anyone here aware of any plan or..." <- Wrong channel
12:24:26 <w[m]> Jeez 
12:24:53 <w[m]> #monero:monero.social 
12:28:27 <bubble101[m]> > Web UI has been disabled
12:28:27 <bubble101[m]> The functionality of this website has been deprecated and will be removed entirely in the future. It will soon be replaced by a desktop app that is currently in active development. The GitHub repository is public, so feel free to inspect the code or provide feedback as development progresses.
12:28:56 <bubble101[m]> which dev though it is good idea to disable web BEFore the desktop app is ready ..
12:29:02 <w[m]> <moneromooo> "If it's about monero development..." <- .
13:08:34 <ooo123ooo1234[m]> <ofrnxmr[m]> "For -Dev? I think it is off..." <- atomic swap -> compatibility with monero -> what can be changed in monero in order to make more compatible ? Is it already compatible ?
13:11:27 <ooo123ooo1234[m]> <ofrnxmr[m]> "For -Dev? I think it is off..." <- a
13:11:40 <ofrnxmr[m]> #monero-research-lounge:monero.social or
13:11:40 <ofrnxmr[m]> #monero:monero.social 
13:11:40 <ofrnxmr[m]> Dev is for hacking on monero.. not for brainstorming algorand 
13:14:59 <hmd2v[m]> Dont worry we are taking it privately, sorry for cluttering this up.
13:15:15 <hmd2v[m]> Happy days, people.
13:33:23 <ooo123ooo1234[m]> > <@ofrnxmr:monero.social> #monero-research-lounge:monero.social or... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/cc1fd62dceac863edc2c4bd9e66867c72f6f7089)
13:34:45 <ooo123ooo1234[m]>  * it's about atomic swap protocol between monero and something else; the name of something else isn't important here;
13:35:16 <ofrnxmr[m]> Yes it is. Atomic swaps arent monero. They are 3rd party
13:36:32 <ofrnxmr[m]> Imagine the comit team using monero-Dev as their home base for their development chats 🥴
13:37:33 <kayabanerve[m]> ... I mean, I did say it was getting off topic because it became a rant about another project on my end, so I moved it to their threads and then explained to the developer privately how to properly integrate with monero, which is regardless of what they're integrating with
13:38:03 <kayabanerve[m]> At this point, the only off topic discussion, besides mine which I ended almost an hour ago, and am sorry for, is this meta discussion on a dead conversation
13:38:57 <ooo123ooo1234[m]> ofrnxmr[m]: atomic swap is shared part between monero and something else, it can be discussed by both sides; but isolated development of monero will be done here, and comit isolated development will be done somewhere else
13:38:57 <ofrnxmr[m]> I was just typing
13:38:57 <ofrnxmr[m]> "Im not replying on this subject fuether as arguing about it is even more off topic."
13:38:58 <ooo123ooo1234[m]> clear enough ?
17:01:44 <dangerousfreedom> Hey guys, I would like to get your thoughts on this issue here:
17:01:49 <dangerousfreedom> https://github.com/monero-project/monero/issues/8351
17:03:59 <moneromooo> What do you call stealth addresses ? Output pubkeys ?
17:09:56 <dangerousfreedom> Yes
17:32:40 <jeffro256[m]> Is this in any way related to the 2017 cryptonote inflation bug?
17:32:41 <jeffro256[m]> https://www.getmonero.org/ru/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html
17:32:56 <jeffro256[m]> Will look at it more in depth in a little bit 
18:03:51 <UkoeHB> uh any idea why this suddenly failed (CI issue?)? https://github.com/monero-project/monero/runs/6560013044
18:04:36 <jeffro256[m]> My PR here fixes it: 
18:04:38 <jeffro256[m]> https://github.com/monero-project/monero/pull/8349
18:05:27 <jeffro256[m]> Looks like someone updated the compiler for Windows CI build and didn't test it against current codebase (just a guess)
18:07:36 <UkoeHB> jeffro256[m]: cool thanks
18:23:12 <sech1> UkoeHB github updates compiler versions all the time
18:28:51 <dangerousfreedom> <jeffro256[m]> "Is this in any way related to..." <- Could be if I had found a key_image outside the prime group. Which I didnt up to now. The thing is that Monero verifies only key_images. But anyone can modify the last bit of the transaction and relay to the network. The nodes would take the transaction and another point outside the prime group would be in the blockchain. Which lately could be used as a ring member in some
18:28:51 <dangerousfreedom> transaction.
18:29:35 <dangerousfreedom> By last bit I mean the stealth_address (resp_json["vout"]["target"]["key"])
18:38:04 <gingeropolous> on immediate read, "NOTICE THAT I DID NOT FIND ANY KEY_IMAGE POINT THAT IS OUTSIDE THE MONERO PRIME SUBGROUP. WHICH WOULD MEAN THAT SOMEONE COULD HAVE DONE A DOUBLE-SPENDING." this doesn't communicate what i think the rest of the post communicates
18:39:31 <gingeropolous> or at least it does so but the language requires more logic parsing 
18:42:04 <dangerousfreedom> I dont know what you think that the post communicates :p
18:42:04 <dangerousfreedom> If it is not clear, let me know ;)
18:42:48 <moneromooo> The quote above means "the check from vN worked" AFAICT.
18:43:04 <moneromooo> (plus the blockchain check up to vN)
18:46:34 <gingeropolous> it could be read as : "I did not find any key image point that is outside the monero prime subgroup, which means that someone could have done a double spending" .. or "i did not find any key image point that is outside the monero prime subgroup. If i had found that, it would mean ... "
18:47:11 <gingeropolous> bah nvm. i think i got it. 
18:50:40 <dangerousfreedom> Oh yeah, sorry my language. I had an implicit statement there. I should have made like: WHICH WOULD MEAN (IF I HAD FOUND) THAT...
18:50:49 <gingeropolous> yeah, there we go
18:54:28 <jeffro256[m]> Oh okay, finally reading this now. There were no key images outside the subgroup, just some points
18:54:41 <jeffro256[m]> If nothing else, it would be good to not allow that so the transactions remain uniform
18:58:08 <dangerousfreedom> jeffro256[m]: Yeah, thats the point. Play safe in the prime group.
18:58:33 <jeffro256[m]> Good find 
19:01:19 <jeffro256[m]> Since the public keys are outside the correct subgroup, won't the key images also be outside the group and thus not spendable?
19:02:53 <dangerousfreedom> jeffro256[m]: No. It is a ring signature. You can have members outside the prime group. 
19:03:47 <dangerousfreedom> If you are the one trying to spend it then you can only spend the image that is in the prime subgroup
19:04:33 <jeffro256[m]> Yeah but if they were to try to actually *spend* from that public key. the Key image is derived by multiplying against the public key so its corresponding key image would land outside the group correct?
19:04:57 <jeffro256[m]> > If you are the one trying to spend it then you can only spend the image that is in the prime subgroup
19:04:57 <jeffro256[m]> Okay yeah that's what I meant 
19:05:31 <dangerousfreedom> Yeah, you would have to multiply by 8 at some point
19:07:08 <selsta> luigi1111: could you please merge 8349 to fix CI?
19:07:12 <selsta> .merge+ 8349
19:07:12 <xmr-pr> Added
19:13:08 <luigi1111> Sure
19:34:36 <selsta> .merges
19:34:36 -xmr-pr- 8318 8324 8325 8326 8328 8330 8331 8349
19:53:40 <jeffro256[m]> UkoeHB your CI build should work now 
19:53:50 <jeffro256[m]> thanks luigi1111 !
20:17:19 <jeffro256[m]> *as long you you rebase 
20:18:45 <selsta> force push is usually enough, at least for the CI run on the PR page
20:54:47 <selsta> moneromooo: could you take a look at https://github.com/monero-project/monero/issues/8347 ?
22:19:32 <aog> do you guys know how can I get some XMR on a testnet wallet?
22:43:29 <NicholasHallahan> Hi Monero Devs! What are you guys working on?
22:44:34 <plowsof[m]> aog https://community.rino.io/faucet/testnet/
22:47:58 <aog> thank you plowsof[m] 
22:49:36 <plowsof[m]> Nicholas Hallahan https://www.monero.observer/monero-dev-activity-report-week-20-2022/ you can follow the dev meetings @ https://github.com/monero-project/meta/issues
23:12:45 <NicholasHallahan> Awesome
23:49:18 <jeffro256[m]> mine it with your daemon, the hashrate is only 4 KH/s