00:13:25 <waywardson> Aha.
00:14:32 <m-relay> <s​yntheticbird:monero.social> I think i've seen this subnet in the blocklist
00:14:42 <waywardson> The IP is connecting to my node, sending a ping command to stay alive. Then whenever I get a new transaction come in, it sends request 1007
00:15:06 <waywardson> this log level 1
00:15:33 <m-relay> <g​ooglemozilla:matrix.org> What does request 1007 do?
00:15:49 <waywardson> RECEIVED_NEW_TRANSACTIONS, like 50ms laters send 1007
00:15:59 <waywardson> chatgpt says NOTIFY_NEW_TRANSACTIONS
00:16:15 <waywardson> hmm
00:20:26 <waywardson> https://github.com/monero-project/monero/issues/9496
00:21:13 <as2333> chatgtp?
00:22:13 <waywardson> im just asking chatgpt what the hell command-100X means in the level 1 logs
00:22:37 <waywardson> there this weird node connecting to peoples node and doing funky stuff with transactions
00:22:43 <waywardson> I think its trying to break dandelion++
00:23:15 <m-relay> <b​oog900:monero.social> it's known: https://github.com/monero-project/research-lab/issues/126
00:25:55 <m-relay> <g​ooglemozilla:matrix.org> Smells like Chainalysis.
00:27:13 <waywardson> yea
00:28:07 <m-relay> <g​ooglemozilla:matrix.org> Banning IPs won't be an effective solution, as that would only address a temporary symptom rather than the underlying problem. However, if we encourage users to use TOR or I2P when sending transactions, it could render eavesdropping attempts futile. What are your thoughts on this approach?
00:30:25 <waywardson> some of my nodes are both clearnet and tor
00:34:03 <waywardson> I should probably add enable-dns-blocklist
00:35:05 <m-relay> <b​oog900:monero.social> it would be a good solution, however our Tor impl is not perfect: https://dl.acm.org/doi/abs/10.1145/3589335.3651487 (going to fixed). Plus with the amount of nodes they run it's a network security risk as well
00:35:14 <m-relay> <b​oog900:monero.social> it would be a good solution, however our Tor impl is not perfect: https://dl.acm.org/doi/abs/10.1145/3589335.3651487 (going to be fixed). Plus with the amount of nodes they run it's a network security risk as well
00:43:08 <m-relay> <g​ooglemozilla:matrix.org> How will this be fixed?
00:43:42 <m-relay> <e​longated:matrix.org> tx-proxy
00:44:46 <m-relay> <g​ooglemozilla:matrix.org> Isn't this already supported?
00:45:05 <m-relay> <e​longated:matrix.org> Use it ?
00:45:24 <waywardson> boog900
00:45:38 <waywardson> should i stop having my nodes priority-node connect to each other
00:45:38 <m-relay> <e​longated:matrix.org> Oh nvm this is a different issue
00:45:59 <m-relay> <g​ooglemozilla:matrix.org> I don't understand.
00:46:14 <waywardson> If a public client sends a transaction through one of my public nodes
00:46:34 <waywardson> and my public nodes choose my other public nodes as that anonymity stage for dandelion
00:46:54 <m-relay> <b​oog900:monero.social> by not inserting the nodes incoming onion address to the end of the peer list message + by randomly re-routing txs over, currently they only do 1 Tor hop
00:46:56 <waywardson> these trackers can connect to all my public nodes to try and pick up the fluff stage
00:47:09 <waywardson> but this is is probably unlikely
00:47:46 <waywardson> my nodes are unlikely to choose my priority nodes as the initial anonymity stage dandelion all time. 
00:47:56 <waywardson> its I assume 1/the number of nodes you are currently connected to
00:48:22 <m-relay> <g​ooglemozilla:matrix.org> I don't think Tor is a good solution for the long term, though. Considering that most nodes are suspiciously located in Germany, which may be run by Interpol, is it possible to migrate to I2P instead?
00:48:23 <m-relay> <b​oog900:monero.social> only outbound connections are used to stem, I would just ban the nodes: https://github.com/Boog900/monero-ban-list/tree/main
00:48:57 <waywardson> is priority node in bound our outbound connection? what if two nodes have priority-node for each other
00:49:28 <waywardson> that means they are always connected
00:49:38 <m-relay> <b​oog900:monero.social> you can use I2p with monero now, it gets priority for routing your txs if you set Tor as well.
00:50:07 <waywardson> says you have 50 outbound connections
00:50:25 <waywardson> then every 1/50 transactions you get, you'll send it to your other node your are priority connected to
00:50:49 <waywardson> we should probably disable sending txs to priority nodes imo
00:51:10 <m-relay> <b​oog900:monero.social> > is priority node in bound our outbound connection? 
00:51:11 <m-relay> <b​oog900:monero.social> outbound 
00:51:13 <m-relay> <b​oog900:monero.social> > what if two nodes have priority-node for each other
00:51:15 <m-relay> <b​oog900:monero.social> No clue, probably which eve connects first has the peer as outbound
00:51:17 <m-relay> <b​oog900:monero.social> ever*
00:51:59 <m-relay> <b​oog900:monero.social> > we should probably disable sending txs to priority nodes imo
00:51:59 <m-relay> <b​oog900:monero.social> why?
00:52:06 <waywardson> yea, so the stem phase may be sent to your priority nodes
00:52:15 <waywardson> and an advesary knows what your public nodes are
00:52:24 <waywardson> they can connect to your public nodes and listen for transactions
00:52:50 <waywardson> obviously its unlikely that all your stem transmits will go to another priority node you have
00:52:55 <waywardson> buts its possible
00:54:53 <m-relay> <b​oog900:monero.social> I don't see how that's a problem, they would still need your node to connect to a spy and for that spy to be chosen as a stem
01:37:36 <m-relay> <s​ethforprivacy:monero.social> Done:
01:37:37 <m-relay> <s​ethforprivacy:monero.social> https://github.com/sethforprivacy/simple-monerod-docker/commit/cea9d8c83738f8164f8d8e09648c916c571c1571
01:37:39 <m-relay> <s​ethforprivacy:monero.social> Note that anyone running the image WITHOUT setting any custom flags/configs will get the ban list automatically applied, but anyone customizing the config at all (most people) will need to add this line to their command or config:
01:37:41 <m-relay> <s​ethforprivacy:monero.social> `--ban-list=/home/monero/ban_list.txt`
01:37:43 <m-relay> <s​ethforprivacy:monero.social> OR
01:37:45 <m-relay> <s​ethforprivacy:monero.social> `ban-list=/home/monero/ban_list.txt`
01:37:47 <m-relay> <s​ethforprivacy:monero.social> The ban list itself is the latest from boog900 but is locally pinned as I didn't want to pull in an external repo I have no control over at build time. If there are major updates to the list please let me know.
01:38:34 <m-relay> <s​ethforprivacy:monero.social> I've subscribed to changes to the repo so will do my best to keep up with it.
01:40:45 <m-relay> <r​ucknium:monero.social> Seth For Privacy: Thank you!
01:48:46 <waywardson> hmm
01:48:53 <waywardson> If I use a vps with an ipv6 range
01:49:33 <waywardson> I can host at my house a proxmox node. On there I can put tiny stupidly underpowered (half fractional cpu, 1gb ram, lots of swap) vms on them. I can route the traffic from the vms to each ipv6 address on my vps
01:49:49 <waywardson> this can like fight the war against these fake proxy nodes
01:50:14 <waywardson> the nodes don't have to be fast enough for public rpc access, just used for p2p
01:51:44 <m-relay> <g​ooglemozilla:matrix.org> As more and more legitimate nodes emerge, I assume that this threat will have fewer impacts, since the probability of a spy node being selected as one of the D++ nodes becomes much smaller?
01:52:03 <waywardson> or dandelion++ gets replaced
01:52:05 <m-relay> <g​ooglemozilla:matrix.org> As more and more legitimate nodes emerge, I assume that this threat will have fewer impacts, since the probability of a spy node being selected as one of the D++ leaves becomes much smaller?
01:52:33 <m-relay> <g​ooglemozilla:matrix.org> What alternatives are there? I'm not aware of any.
01:56:49 <m-relay> <o​frnxmr:xmr.mx> Tor / i2p
01:57:26 <m-relay> <g​ooglemozilla:matrix.org> Forcing only Tor and I2P usage?
01:57:54 <waywardson> honestly I agree, tor is just much better solution overall. A fully synced node doesn't use that much bandwidth anyway.
01:58:26 <waywardson> We need more nodes on tor. It's also a lot easier to host tor entry nodes than exit nodes
01:58:53 <waywardson> Basically anyone can host a tor entry node, so, hopefully it wouldn't be too much of a strain on the tor network.
02:35:22 <m-relay> <o​frnxmr:xmr.mx> --tx-proxy
02:36:38 <m-relay> <e​longated:matrix.org> Tor/i2p should be bundled, run out of the box
02:37:10 <m-relay> <e​longated:matrix.org> Or maybe that monerod gui can do it ?
03:43:23 <m-relay> <s​yntheticbird:monero.social> dear elongated.
03:43:30 <m-relay> <s​yntheticbird:monero.social> we appreciate your suggestion
03:43:35 <m-relay> <s​yntheticbird:monero.social> you have no idea.
03:43:36 <m-relay> <s​yntheticbird:monero.social> NO IDEA
03:43:51 <m-relay> <s​yntheticbird:monero.social> of how it was a challenging TO TRY to get i2p bundled in monero
03:44:06 <m-relay> <s​yntheticbird:monero.social> There were DRAMA
03:44:10 <m-relay> <s​yntheticbird:monero.social> cross-community drama
03:44:52 <m-relay> <e​longated:matrix.org> GUI route then
03:56:21 <m-relay> <r​ottenwheel:unredacted.org> Leave that to the wallet developers to implement. Can't make the GUI and CLI be Tor-only, or Tor by default. That's just a pipe dream...
04:05:54 <m-relay> <o​frnxmr:monero.social> Kovri*
04:33:42 <m-relay> <3​21bob321:monero.social> Use feather if you want tor
04:36:18 <m-relay> <o​frnxmr:xmr.mx> Pipe dream
04:41:27 <m-relay> <3​21bob321:monero.social> If i hit you with the pipe you will dream it
04:44:55 <m-relay> <o​frnxmr:xmr.mx> Pipe wallet
05:14:55 <m-relay> <r​ottenwheel:unredacted.org> Hit me with your pipe, daddy! 🍆
06:22:09 <m-relay> <e​longated:matrix.org> Which wallet has gui for monerod?  Monero-gui is almost dead; feather has daemon gui on roadmap for months/yrs 
06:22:09 <m-relay> <e​longated:matrix.org> Plug n play tor/i2p for monerod would be very good
06:40:59 <m-relay> <o​we_addams:matrix.org> How do you think if Monero goes above $200? I don't know whether I should hold it or not
06:42:16 <m-relay> <e​longated:matrix.org> Sell and sleep
06:46:46 <m-relay> <r​ottenwheel:unredacted.org> Wut u mean wallet GUI for monerod? Maybe monerod gui stuff by eve... plowsof! You know this one!
06:47:17 <m-relay> <r​ottenwheel:unredacted.org> Yes, by @everoddandeven:monero.social.
06:47:19 <m-relay> <e​longated:matrix.org> Yah
06:47:32 <m-relay> <r​ottenwheel:unredacted.org> Just read Revuo. 💅
06:47:58 <m-relay> <r​ottenwheel:unredacted.org> Here. https://www.revuo-xmr.com/weekly/issue-218/
06:48:10 <m-relay> <e​longated:matrix.org> Yah, I hope it does tor/i2p by default
06:48:17 <m-relay> <r​ottenwheel:unredacted.org> https://github.com/everoddandeven/monerod-gui
06:49:46 <m-relay> <e​longated:matrix.org> Does it already have tor/i2p or wip ?
06:50:33 <m-relay> <r​ottenwheel:unredacted.org> I don't know and I frankly don't care. That nym is in the community matrix room or in Revuo, ask them directly.
06:51:49 <m-relay> <e​longated:matrix.org> You don’t care if it’s easy to deploy tor/i2p for monerod ? Anyways thanks
06:54:54 <m-relay> <r​ottenwheel:unredacted.org> Yes, I do not care.
06:55:01 <m-relay> <r​ottenwheel:unredacted.org> Also.
06:55:57 <m-relay> <e​longated:matrix.org> Wallet developers don’t want to deal with monerod
06:56:10 <plowsof> https://docs.getmonero.org/running-node/monerod-tori2p/
06:57:07 <m-relay> <r​ottenwheel:unredacted.org> Right... They make wallets that connect telepathically to thankful_for_today excel spreadsheet and that is how most XMR wallets work. How could I miss that...
06:57:59 <m-relay> <e​longated:matrix.org> They don’t want to manage monerod 😅 you are so dense
06:58:18 <m-relay> <r​ottenwheel:unredacted.org> Pour dissolvent solution over my head!
06:58:57 <m-relay> <r​ottenwheel:unredacted.org> Anyways, Feather has a built-in Tor daemon, Mysu has a built-in Tor daemon.
06:59:09 <m-relay> <e​longated:matrix.org> GUI and feather haven’t done anything on daemon management front for years, which other wallet is left ?
06:59:25 <m-relay> <r​ottenwheel:unredacted.org> I still don't get what you mean by this, at all.
06:59:36 <m-relay> <e​longated:matrix.org> Dude those are just connecting to remote node , not managing daemon
06:59:39 <m-relay> <r​ottenwheel:unredacted.org> Feather can be Tor-only if user chooses to.
06:59:56 <m-relay> <r​ottenwheel:unredacted.org> You can connect to your own local node through Tor too, you dumb nuts.
07:00:22 <plowsof> This is the monerod-gui https://github.com/everoddandeven/monerod-gui , most likely a feature requestbas these where not part of the original bounty thatbfunded itn, i can confirm  soon
07:00:40 <m-relay> <e​longated:matrix.org> lol 😂 seriously go and read the come again tomorrow morning
07:00:47 <m-relay> <r​ottenwheel:unredacted.org> Ok retard.
07:00:50 <m-relay> <e​longated:matrix.org> lol 😂 seriously go and read the conv again tomorrow morning
07:01:03 <m-relay> <e​longated:matrix.org> Check the mirror
07:01:31 <m-relay> <r​ottenwheel:unredacted.org> It says ur qt. Let's go on a date where you try to explain with apples and a whiteboard wtf you mean by monerod and wallets...
07:01:39 <m-relay> <r​ottenwheel:unredacted.org> Because you are still making zero sense.
07:02:03 <m-relay> <r​ottenwheel:unredacted.org> Want a remote note? Use a remote node.
07:02:05 <m-relay> <r​ottenwheel:unredacted.org> Have a local node? Use local node.
07:02:07 <m-relay> <r​ottenwheel:unredacted.org> Clearnet? Clearnet.
07:02:09 <m-relay> <r​ottenwheel:unredacted.org> Tor? Tor.
07:02:18 <m-relay> <e​longated:matrix.org> And you can’t make sense of words
07:02:25 <m-relay> <r​ottenwheel:unredacted.org> What the fuck do you keep mumbling about a monerod and tor and daemons and wallet daemons bs?
07:02:32 <m-relay> <r​ottenwheel:unredacted.org> Lol.
07:02:38 <plowsof> Take the bickering to another room 
07:02:55 <m-relay> <e​longated:matrix.org> Don’t reply if you don’t understand
07:03:03 <m-relay> <r​ottenwheel:unredacted.org> I am asking so you explain to me.
07:03:06 <m-relay> <r​ottenwheel:unredacted.org> But you haven't?
07:03:30 <m-relay> <r​ottenwheel:unredacted.org> Unless you are the one who doesn't know what he's saying?
07:03:34 <m-relay> <r​ottenwheel:unredacted.org> 🤔
07:04:31 <m-relay> <e​longated:matrix.org> If there a plug and play daemon management gui app which has tor/i2p for monerod ?
07:07:16 <m-relay> <r​ottenwheel:unredacted.org> This is the only monerod GUI stuff to date. Like I said 30 messages above, ask that nym or open an issue in the repository...
07:08:07 <m-relay> <e​longated:matrix.org> And I was discussing about it but you wanted to argue for no reason
07:08:48 <m-relay> <e​longated:matrix.org> Anyways hope you mature at some point in your life
07:10:45 <m-relay> <r​ottenwheel:unredacted.org> Only fruits mature!
07:10:50 <m-relay> <r​ottenwheel:unredacted.org> They get ripe!
07:11:12 <m-relay> <r​ottenwheel:unredacted.org> But what can we discuss about when you can go straight to the source!
07:11:43 <m-relay> <r​ottenwheel:unredacted.org> Indeed, I'll go wrap my head in newspaper and sit still for 3 days to see if I 'mature' enough for your standards. Have a wonderful Thursday!
07:21:38 <plowsof> Oh this isn't the workgroup channel, i should have known as there wasn't 1000 messages running in circles 
07:26:34 <m-relay> <r​ottenwheel:unredacted.org> Happy international volunteer day, everyone! 🥳 The prestigious XMR workgroups celebrate all together in this beautiful day! https://nationaltoday.com/international-volunteer-day/
08:19:40 <m-relay> <m​arioob:matrix.org> hello. Is this the official monero app? It says is not verified. https://flathub.org/apps/org.getmonero.Monero
08:46:41 <m-relay> <m​onerobull:matrix.org> check getmonero.org
10:13:58 <moneromooo> Be careful, the "Monero" app is a squatter, as as monero.com. It is owned by cake wallet, and is NOT the monero project.
10:14:49 <moneromooo> (they're believed to not be scammers though)
10:22:58 <m-relay> <o​frnxmr:xmr.mx> moneromooo, you should see haveno.com
10:24:05 <m-relay> <o​frnxmr:xmr.mx> Monero.com doesnt pretend to be anything official, (and the links on getmonero are to cakewallet.com)
10:25:08 <plowsof> there is no official anything, even the monero-projects github wallet is the "reference" wallet. you probably mean trusted / safe .. good question 
10:26:04 <m-relay> <o​frnxmr:xmr.mx> haveno.com states that they host the official source code repository
10:27:25 <m-relay> <o​frnxmr:xmr.mx> Monero.com makes no such claims and doesn't try to misrepresent as being an "official" or even a community project
10:29:05 <m-relay> <o​frnxmr:xmr.mx> The only possible confusion for monero.com is the url. Haveno.com tries to portray itself as _the_ "official" haveno and repo
10:33:02 <moneromooo> I have no idea about haveno, sorry. I only vaguely follow.
10:33:33 <m-relay> <o​frnxmr:monero.social> Just take one look at that website :)
10:33:36 <moneromooo> Monero.com doesn't pretend is disingenuous.
10:33:49 <moneromooo> It's *monero.com*. That's canonical pretending.
10:34:14 <moneromooo> Adding "we're not monero" once they got lots of people incoming ensures some will not notice
10:34:25 <moneromooo> It's a giant dick move and it's fucking obvious.
10:34:37 <m-relay> <o​frnxmr:xmr.mx> It says "monero.com by cake wallet" in the header
10:36:04 <m-relay> <m​arioob:matrix.org> indeed the flatpak version is advertised here https://github.com/monero-project/monero-gui
10:38:09 <m-relay> <m​arioob:matrix.org> however, it feels a bit untrustworthy for not being a verified app.
10:57:44 <m-relay> <o​frnxmr:monero.social> The road to verification has been bumpy
10:58:36 <m-relay> <m​arioob:matrix.org> flathub giving headaches?
11:00:20 <m-relay> <o​frnxmr:monero.social> the process is annoying and doesnt really provide any security
11:08:21 <m-relay> <m​arioob:matrix.org> not security but a layer of trust. I remember a while ago some wallet got uploaded on flathub and people remained without their money upon using it.
11:16:04 <m-relay> <o​frnxmr:xmr.mx> Nothing monero is official
11:16:24 <m-relay> <o​frnxmr:xmr.mx> The monero-gui in flathub is maintained by a community member
13:00:05 <revuoxmr> Revuo Monero Issue 220: November 28 - December 5, 2024. https://www.revuo-xmr.com/weekly/issue-220/
14:02:12 <m-relay> <b​asses:matrix.org> it is official wallet by The Monero Project
14:03:49 <m-relay> <b​asses:matrix.org> everything maintained by monero-project is official
14:05:28 <m-relay> <o​frnxmr:xmr.mx> Lmfao
14:05:59 <m-relay> <o​frnxmr:xmr.mx> plowsof and ofrn are the coo and ceo, i think we'd know what is and isnt official
14:06:21 <m-relay> <o​frnxmr:xmr.mx> The software is owned by nobody and is maintained by individuals
14:06:33 <m-relay> <o​frnxmr:xmr.mx> Nothing is official
14:07:54 <m-relay> <o​frnxmr:xmr.mx> Miners, exchanges, node runners choose what is official. Devs choose what they want to work on (cuprare etc). Absolutely nothing is official. 
14:07:55 <m-relay> <o​frnxmr:xmr.mx> reference software? Sure. Official? No.
14:09:21 <m-relay> <o​frnxmr:xmr.mx> choose what is official to them*. The consensus of the network (ring size, ?bulletproof, randomx) might also be considered official. monerod? No.
14:10:42 <m-relay> <b​asses:matrix.org> lmao
14:10:50 <m-relay> <b​asses:matrix.org> would you cool Tor not official?
14:10:54 <m-relay> <b​asses:matrix.org> would you call Tor not official?
14:11:40 <m-relay> <b​asses:matrix.org> nice fantasy
14:12:27 <m-relay> <o​frnxmr:xmr.mx> Are you cooked?
14:12:34 <m-relay> <o​frnxmr:xmr.mx> Would you call bitcoin core official?
14:12:55 <m-relay> <o​frnxmr:xmr.mx> Or bitcoin cash node official?
14:13:21 <m-relay> <b​asses:matrix.org> yes
14:13:30 <m-relay> <b​asses:matrix.org> search what the word "official" means
14:13:35 <m-relay> <o​frnxmr:xmr.mx> Then youre an idiot, sorry
14:13:49 <m-relay> <b​asses:matrix.org> skibidi toilet
14:13:58 <m-relay> <o​frnxmr:xmr.mx> Bitcoin core is not the official bitcoin implementation
14:14:10 <m-relay> <o​frnxmr:xmr.mx> Its just one of them
14:14:33 <m-relay> <b​asses:matrix.org> .
14:14:36 <m-relay> <b​asses:matrix.org> .
14:14:49 <m-relay> <o​frnxmr:xmr.mx> Cuprate is just as official as monerod
14:15:22 <m-relay> <s​yntheticbird:monero.social> hell yeah we're going to conquest you all
14:15:24 <m-relay> <o​frnxmr:xmr.mx> Funded by community, worked on by community, open source, follows consenaus, shares no code with monerod
14:15:30 <m-relay> <b​asses:matrix.org> keep dodging
14:15:44 <m-relay> <b​asses:matrix.org> this is not what I'm asking
14:15:49 <m-relay> <o​frnxmr:xmr.mx> Youre asking about tor
14:16:24 <m-relay> <o​frnxmr:xmr.mx> i answer your irrelevant nonsense with an equally absurd response
14:17:08 <m-relay> <s​yntheticbird:monero.social> rando, the correct word is *reference implementation*
14:17:33 <m-relay> <s​yntheticbird:monero.social> Cuprate and Monerod are both official. monerod is the *reference implementation*, cuprate is not
14:17:37 <m-relay> <o​frnxmr:xmr.mx> Syntheticbird ^, i said that too
14:18:12 <m-relay> <o​frnxmr:xmr.mx> yet*
14:19:02 <m-relay> <o​frnxmr:xmr.mx> Monerod is only _the_ reference because its the _only_ reference
14:20:19 <m-relay> <s​yntheticbird:monero.social> no, because it is endorsed by the core team and most importantly is actually the one dictating the direction of the network/cryptocurrency. We could be 100 time better than monerod, if monerod devs take the decision we would not be the *reference*.
14:20:42 <m-relay> <o​frnxmr:xmr.mx> Core is 1.5 people and a niocat
14:21:04 <m-relay> <o​frnxmr:xmr.mx> Nobody cares what they endorse, if im being perfectly honest
14:21:11 <m-relay> <o​frnxmr:xmr.mx> They dont even care
14:21:24 <m-relay> <o​frnxmr:xmr.mx> 70% of the core team just fucked off without saying goodbye
14:21:42 <m-relay> <o​frnxmr:xmr.mx> The other 30% pops their head up when someone complains about money
14:21:54 <m-relay> <o​frnxmr:xmr.mx> 20/30%**
14:22:42 <m-relay> <o​frnxmr:xmr.mx> The remains 10% is articmine, who doesnt get involved in anything but scaling and research
14:23:15 <m-relay> <o​frnxmr:xmr.mx> Or ducks their head and dodges the transparency report
14:23:33 <m-relay> <o​frnxmr:xmr.mx> Has anyone bothered to sync the old view wallets for xmr? Donations have been coming to that wallet for years
14:26:55 <nioCat> I have several days of scrollback for this channel  0_o
14:27:12 <m-relay> <o​frnxmr:xmr.mx> dont bother
14:27:34 <m-relay> <o​frnxmr:xmr.mx> Wait for kewbits blog post
14:27:53 <nioCat> in this channel as well?  lol
14:28:35 <nioCat> might have time in a bit
14:31:06 <m-relay> <s​yntheticbird:monero.social> Wait for mine too
14:31:19 <m-relay> <s​yntheticbird:monero.social> It will be *substantially* more documented
14:32:57 <m-relay> <o​frnxmr:xmr.mx> will you write yours with ai tho?
14:38:24 <m-relay> <b​asses:matrix.org> thx, when someone comes and ask if X software is official, they usually mean whether it is developed and maintained by The Monero Project.
14:38:47 <m-relay> <s​yntheticbird:monero.social> yes. SyntheticLllama
14:39:05 <m-relay> <s​yntheticbird:monero.social> yes we both have the same understanding of official
14:39:21 <m-relay> <s​yntheticbird:monero.social> but I also understand ofrnxmr point. Cuprate is not amateur
14:40:36 <m-relay> <o​frnxmr:xmr.mx> The Monero Project = core
14:40:47 <m-relay> <o​frnxmr:xmr.mx> They honestly dont do anytthing.
14:41:15 <m-relay> <b​asses:matrix.org> If someone were to backdoor monero core, everyone is going to be affected, right? Unless I'm understanding something wrong?
14:42:28 <m-relay> <b​asses:matrix.org> monero software by core devs
14:42:40 <m-relay> <o​frnxmr:xmr.mx> Luigi (core)only merges code that was sent via pr by community, reviewed by community, and put on a merge list by community
14:43:06 <m-relay> <o​frnxmr:xmr.mx> The software is signed reproducibly by community, and the sigs repo is maintained by community
14:43:13 <m-relay> <o​frnxmr:xmr.mx> Are you cooked?
14:43:31 <m-relay> <b​asses:matrix.org> are you rotten?
14:43:40 <m-relay> <o​frnxmr:xmr.mx> When is the last pr you know of by a core?
14:43:49 <m-relay> <o​frnxmr:xmr.mx> By core*?
14:44:05 <m-relay> <o​frnxmr:xmr.mx> Every dev working on monero, is a community dev
14:44:06 <m-relay> <o​frnxmr:xmr.mx> All of them
14:44:21 <m-relay> <o​frnxmr:xmr.mx> core doesnt even review code
14:44:30 <m-relay> <b​asses:matrix.org> u didn't understand and don't want to understand
14:44:52 <m-relay> <b​asses:matrix.org> if someone were to backdoor https://github.com/monero-project/monero
14:45:03 <m-relay> <o​frnxmr:xmr.mx> theyd have to open a pr
14:45:07 <m-relay> <o​frnxmr:xmr.mx> And have community approve it
14:45:24 <m-relay> <o​frnxmr:xmr.mx> And it would have to go through selsta, who is also not core
14:46:27 <m-relay> <b​asses:matrix.org> what we were even discussing about?
14:47:35 <m-relay> <s​yntheticbird:monero.social> skibidi toilet
14:47:37 <m-relay> <o​frnxmr:xmr.mx> youre making false claims about who controls monero. The correct answer is "nobody, and everybody". Core does not control monero
14:48:09 <m-relay> <s​yntheticbird:monero.social> rando you won't change ofrnxmr mind, keep your opinion for yourself
14:48:10 <m-relay> <b​asses:matrix.org> it is me
14:48:53 <m-relay> <o​frnxmr:xmr.mx> Yes, if you know how to write, review or test code
14:49:24 <m-relay> <b​asses:matrix.org> ofrnxmr how about you reply with: Yes, monero GUI is developed by The Monero Project, then proceed with your official copypasta about what official means rather than confusing people?
14:49:33 <m-relay> <o​frnxmr:xmr.mx> It ISNT
14:49:47 <m-relay> <b​asses:matrix.org> LOL
14:49:47 <m-relay> <b​asses:matrix.org> u didn't even read
14:49:51 <m-relay> <b​asses:matrix.org> 0.1 sec reply
14:49:51 <m-relay> <o​frnxmr:xmr.mx> Name the monero-gui devs
14:50:12 <m-relay> <b​asses:matrix.org> selsta
14:50:23 <m-relay> <o​frnxmr:xmr.mx> The monero project aka core is not on the list
14:50:28 <m-relay> <o​frnxmr:xmr.mx> Is selsta core? No
14:50:52 <m-relay> <o​frnxmr:xmr.mx> Selsta is a community funded community dev
14:51:12 <m-relay> <b​asses:matrix.org> core or person is irrelavant, any project under The Monero Project org is considered official by them
14:51:29 <m-relay> <b​asses:matrix.org> core or not is irrelavant, any project under The Monero Project org is considered official by them
14:51:46 <m-relay> <o​frnxmr:xmr.mx> Diego is the only monero-project employee ever
14:52:12 <m-relay> <b​asses:matrix.org> ^ true
14:52:26 <m-relay> <o​frnxmr:xmr.mx> Who is them?
14:52:59 <m-relay> <b​asses:matrix.org> this is the correct way to respond anyone asking this question
14:53:17 <m-relay> <o​frnxmr:xmr.mx> youre an idiot, im done talking tonyou
15:02:06 <m-relay> <b​asses:matrix.org> Anyway, if someone is following the them is meant for monero-project, is People that are in The Monero Project org, ofrxmr is not part of it so he can't tell for sure who is still there and only sees luigi1111 as he's the most active The Monero Project member/person that approves pull requests.
15:02:37 <m-relay> <s​yntheticbird:monero.social> fwiw they could all be friends and be at the beach right now
15:02:40 <m-relay> <b​asses:matrix.org> Anyway, if someone is following this topic, the "them" is meant for monero-project, it is the "People" that are in The Monero Project org, ofrxmr is not part of it so he can't tell for sure who is still there and only sees luigi1111 as he's the most active The Monero Project member/person that approves pull requests.
15:02:43 <m-relay> <s​yntheticbird:monero.social> core members i mean
15:02:54 <m-relay> <s​yntheticbird:monero.social> Articmine looks like a beach guy
15:05:30 <m-relay> <o​frnxmr:xmr.mx> luig bf artic
15:05:53 <m-relay> <o​frnxmr:xmr.mx> Its like rocket science
15:06:33 <m-relay> <o​frnxmr:xmr.mx> The rest dont have duties at all
15:07:08 <m-relay> <o​frnxmr:xmr.mx> You can tell how green you are because you don't have any idea how the governance structure used to work
15:07:34 <m-relay> <b​asses:matrix.org> for sure 👍
15:07:39 <m-relay> <r​avfx:xmr.mx> One be one nice way to be able to grab them all with one scoop
15:07:48 <m-relay> <o​frnxmr:xmr.mx> Core didn't used to just sit around and do nothing in the shadows. They used to be active and used to make all the decisions.
15:08:51 <m-relay> <s​yntheticbird:monero.social> to get full bullied just after, no shit they decided to not talk anymore
15:08:54 <m-relay> <b​asses:matrix.org> free non-CIA lemonade drink 🍋🏖️
15:09:34 <m-relay> <b​asses:matrix.org> very true
15:10:03 <m-relay> <o​frnxmr:xmr.mx> You probably don't have to read any further than Fluffy's post about creating work groups to replace the old core duties. core left and nobody filled those holes and a lot of those things have not been getting done for years.
15:11:07 <m-relay> <o​frnxmr:xmr.mx> Luigi, binary, and Arctic Mine are the only ones left.
15:11:29 <m-relay> <b​asses:matrix.org> moneromooo-monero ???
15:11:36 <m-relay> <o​frnxmr:xmr.mx> No
15:11:42 <m-relay> <o​frnxmr:xmr.mx> Not core
15:12:21 <m-relay> <b​asses:matrix.org> PRs from 2014
15:12:22 <m-relay> <o​frnxmr:xmr.mx> and was never core
15:12:36 <m-relay> <o​frnxmr:xmr.mx> Still isnt
15:12:52 <m-relay> <b​asses:matrix.org> he is considered core to me
15:14:22 <m-relay> <b​asses:matrix.org> not talking about who is core, just early contributors
15:14:54 <m-relay> <o​frnxmr:xmr.mx> HES NOT CORE
15:14:59 <m-relay> <b​asses:matrix.org> these are core, unless you got access to org anything you say is just speculation
15:15:15 <m-relay> <b​asses:matrix.org> .
15:15:18 <m-relay> <b​asses:matrix.org> .
15:15:24 <m-relay> <b​asses:matrix.org> 🤦
15:15:45 <m-relay> <o​frnxmr:xmr.mx> luigi bf are only ones with repo ownership afaik. articmine doesn have
15:15:55 <m-relay> <o​frnxmr:xmr.mx> ^ rofl
15:16:11 <m-relay> <b​asses:matrix.org> yes, in my eyes lool
15:16:13 <m-relay> <o​frnxmr:xmr.mx> Mooo doesnt consider themself to he core
15:16:31 <m-relay> <o​frnxmr:xmr.mx> Core doesnt consider mooo to he core
15:16:57 <m-relay> <o​frnxmr:xmr.mx> Fanboyism doesnt change the fact that the core team is an material thing
15:17:14 <m-relay> <o​frnxmr:xmr.mx> Its not up for interpretation
15:17:15 <m-relay> <b​asses:matrix.org> idc what core thinks 🕶️
15:17:58 <m-relay> <o​frnxmr:xmr.mx> You dont care what mooo thinks eitherb
15:19:56 <m-relay> <b​asses:matrix.org> community driven projects shouldn't idolize core members & contrib, anyone that contributors to The Monero Project for so long is considered a trusted contributor and can be a core member in org if they want to
15:20:58 <m-relay> <o​frnxmr:xmr.mx> rofl
15:21:02 <m-relay> <o​frnxmr:xmr.mx> You clearly dont understand the role of core
15:21:13 <m-relay> <o​frnxmr:xmr.mx> And youre just slapping definitions on things that "feel good"
15:23:00 <m-relay> <o​frnxmr:xmr.mx> Moneromooo was essential to monero's success and was one of the most active contributors and developers for many, many years. Can you say the same for any core member? Core's duties are/were an entirely different realm - logistics
15:25:43 <m-relay> <b​asses:matrix.org> why attacking core's role is any relevant?
15:26:31 <m-relay> <b​asses:matrix.org> you win what ever arguement you thing is happening rn, gg
15:26:36 <m-relay> <b​asses:matrix.org> you win what ever arguement you think is happening rn, gg
15:27:52 <m-relay> <b​eneficialsource:matrix.org> Alright now everyone hug and kiss
15:34:10 <m-relay> <f​:monero.social> Now that this is settled ...
15:34:31 <m-relay> <f​:monero.social> Based on the concept posted in https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/495#note_27007 I've been trying some RPC commands to see if I could not get payments with an unsynced/offline wallet to work.
15:35:05 <m-relay> <f​:monero.social> Technically, what I have in mind seems to be possible. I did notice that only the first transaction from the offline instance is accepted by the network. Any follow-ups get rejected or cannot be built by the offline RPC - but I guess/hope this to be merely a question of correctly handling outputs.
15:36:21 <m-relay> <f​:monero.social> Essentially, I am looking to create a setup that allows in-person payments, where the merchant runs a simple interface to a live endpoint, so that the customer's device merely needs to sign without having to keep up with the network.
15:40:39 <m-relay> <f​:monero.social> Creating a CCS in to cover development of a working implementation that takes the user by the hand and automates as much as possible. What do you think?
15:43:41 <rbrunner> With "offline" you mean that the wallet is not connected to a daemon at the time it constructs a tx?
15:43:57 <m-relay> <f​:monero.social> Yes.
15:45:07 <rbrunner> Does that even work in principle? Where would the wallet get the necessary decoys from in such a situation?
15:45:21 <m-relay> <f​:monero.social> Sorry, no. *Construction* is done by a live (viewonly) wallet. *Signing* is done by the offline wallet.
15:46:49 <m-relay> <f​:monero.social> There's a diagram in the linked comment, where **pkd** (to the right) constructs the transaction and **skd** (to the left), the device in the hand of the payer, signs it.
15:47:31 <rbrunner> I am afraid I don't get the idea yet. I guess the aim is to build something that achieves some kind of simplification compared with solutions available today?
15:49:12 <m-relay> <d​iego:cypherstack.com> This actually isn't true. When the noethers were first brought onto the project (back when they were still grad students) and fp found them (on a math site i believe?) They were paid directly from the general fund to do work for a while.
15:49:59 <m-relay> <d​iego:cypherstack.com> Though that may have been a sort of bounty system. I'd have to ask fp again.
15:50:18 <m-relay> <o​frnxmr:xmr.mx> Yeah, i forgot
15:50:27 <m-relay> <o​frnxmr:xmr.mx> I remember when sarang went to ffs for the first time
15:50:35 <m-relay> <d​iego:cypherstack.com> At some point they took a break from it and then when they came back they were urged to do the CCS thing and they did.
15:51:03 <plowsof> its been 10 years since this proof of concept demonstrating bitcoin offline nfc payments https://www.reddit.com/r/Bitcoin/comments/2nuq5u/offline_wallet_completing_a_bitcoin_payment_via/ 
15:51:44 <plowsof> "Not a viable product though unless it's integrated into some of the major POS manufacturers. When this type of functionality is integrated into the POS, there will be no need for the hardware on the video." we're getting ahead of ourselves here - how about we first get normal Monero / NFC payment integrated into a POS device first? 
15:52:08 <plowsof> for example https://bounties.monero.social/posts/159/10-734m-foss-monero-point-of-sale-android-app
15:53:53 <m-relay> <f​:monero.social> rbrunner: That would be the goal, yes. Technically, a user would deploy the view-only live RPC on the internet and keep it synced with current key images (from a secure location). Then this RPC can be asked to prepare an unsigned transaction, that will then be signed by the offline device.
15:55:50 <m-relay> <f​:monero.social> rbrunner: As a direct effect, the user's doesn't end up delaying the queue at the cash register by waiting for the device to sync.
15:56:19 <rbrunner> Ah, I see, thanks. Interesting idea, but a lot of moving parts. And so far we can't even get many people to run a bog-standard Monero daemon ...
15:59:48 <plowsof> a few mobile wallets have background syncing enabled by default now... "pocketchange".... possibility of "skip sync" can be implemented to wallets https://bounties.monero.social/posts/79/0-211m-add-a-skip-sync-feature-to-a-monero-wallet 
16:00:52 <m-relay> <f​:monero.social> plowsof: The design actually takes such a device into account. It can be done "first" or it can be done later. In any case it's a bit of a circular thing: If today a merchant wanted a simple solution, they would find there is none. If today we created a simple solution, we would find there is no merchant wanting one (in this very moment).
16:01:33 <plowsof> so i would ask you to show me how effective this has been for bitcoin, now that the technology / working concept is 10 years old 
16:01:46 <m-relay> <f​:monero.social> In any case, we cannot reasonably create demand before having the supply.
16:01:48 <rbrunner> From that bounty: "Waterdrought· 7 months ago ill give it a shot" Or maybe not :)
16:03:01 <rbrunner> It's a bit unfair to ask for Bitcoin solutions because for years that's not viable to make small POS payments any. Coffee 1 USD, fee 5 USD. Yeah, right.
16:03:07 <plowsof> there are solutions on the table that can be  implemented today to address the problem of opening a wallet and needing to pay and oh its not synced!, no concepts required 
16:03:56 <plowsof> the idea of offline payments is an interesting research topic though and has been discussed in MRL-lounge, have you shared your concept there or had feedback on it?
16:04:16 <m-relay> <f​:monero.social> plowsof: Background sync is opposed to a privacy-aware mindset, but moreover it cannot be expected to be understood by an older generation - or anybody who just want's to get a payment done without caring for the details, for what it's worth.
16:06:22 <m-relay> <o​frnxmr:xmr.mx> Wait til they find out about 8 input limits
16:06:33 <m-relay> <o​frnxmr:xmr.mx> sneedlewoods, pls fix :P
16:07:33 <m-relay> <f​:monero.social> I wholeheartedly disagree that anything that requires a mobile device to do work in the background while the user isn't even thinking about his next payment can be called a solution.
16:07:33 <m-relay> <f​:monero.social> rbrunner is right, that we cannot compare to Bitcoin (any more). There's steadily growing adoption on xmrbazaar. Maybe there's something similar for Bitcoin, but I'd doubt that there's much interest in a circular economy there.
16:07:45 <plowsof> rbrunner a bit unfair yes (1 usd coffee?? wow) but throughout those 10 years ther have been times where layer one bitcorn fees are low enough to make offline nfc payments viable ... 
16:08:17 <rbrunner> How will the POS system find those special RPC daemons that the customers run to construct unsigned transactions?
16:08:30 <rbrunner> I mean, technically
16:08:52 <plowsof> "anything that requires a mobile device to do work in the background while the user isn't even thinking about his next payment can be called a solution." then we move to anotherr. skip sync which has the same plus/min points of having an offline wallet not aware of the current chain state 
16:10:25 <m-relay> <f​:monero.social> The offline device provides an identification and the URI of the RPC.
16:10:25 <m-relay> <f​:monero.social> The merchant's device which does have to be online thet creates a request for to that RPC to create an unsigned transaction.
16:11:04 <m-relay> <f​:monero.social> The offline device provides an identification and the URI of the RPC.
16:11:05 <m-relay> <f​:monero.social> The merchant's device - which does have to be online - then creates a request for to that RPC to create an unsigned transaction.
16:11:14 <m-relay> <f​:monero.social> The offline device provides an identification and the URI of the RPC.
16:11:15 <m-relay> <f​:monero.social> The merchant's device - which does have to be online - then creates a request for that RPC to create an unsigned transaction.
16:11:46 <rbrunner> Won't this give endless trouble with firewalls, NAT, etc, when trying to set up those customer RPC daemons that must be reachable from the Internet at large?
16:13:47 <rbrunner> People nowadays just don't run their own servers facing the Internet, seems to me.
16:13:59 <rbrunner> For various reasons.
16:14:02 <m-relay> <f​:monero.social> The best way to run the RPC would be on I2P or Tor, for privacy, but now that you mention firewalls - that issue would also be mitigated by doing so.
16:15:24 <rbrunner> I mean we are not only talking about a solution for Monero here. I think that's quite a fundamental trend - people don't run servers, quite in general. Getting them to do so looks like a terrible uphill battle
16:16:21 <rbrunner> Look how many people run a Monero daemon at home and connect their smartphone wallet to that on the go. Count them on a single hand? :)
16:16:42 <m-relay> <f​:monero.social> Both I2P and Tor allow for certificate-type authentication, but since .onion's and .i2p's are hard to guess that shouldn't be required in short- to middle-term.
16:17:45 <rbrunner> Yeah, that will fly from a psychological point of view with merchants - connect your POS system to Tor. It won't bite, and Tor doesn't have a bad reputation, no no
16:19:02 <rbrunner> I hate to spoil this party, I love it when people are creative and think outside the box, but I really can't imagine this taking off, sorry
16:19:20 <m-relay> <f​:monero.social> Yes, people don't. It has to be made as easy as possible. I am thinking of hosters that allow you to say "there is the docker file - just run this".
16:20:58 <m-relay> <f​:monero.social> Both Tor and I2P will happily block any attempts to connect on their network layer if remote isn't authenticated.
16:24:11 <m-relay> <f​:monero.social> If you don't expect Monero to be capable of taking off as an in-person payment solution, you would be right.
16:27:12 <m-relay> <f​:monero.social> I do see it, though. Just as there's only a handful of users on xmrbazaar trying to create a circular economy, there's at least a handful of users who would appreciate simplified handling. Even if this is just adopted by certain circles "internally", let's say a group of some 50 people who do bring the required knowledge, it would be a start and get things rolling in the right direction.
16:50:20 <rbrunner> That signing device that the customer uses and that talks with the POS system, what are we talking about here? Does something suitable exist already, or would we need to design and build a custom device?
16:51:06 <rbrunner> I think you mention that a smartphone app could do here, right, at least at the start?
16:53:53 <m-relay> <b​eneficialsource:matrix.org> So did we end up hugging and kissing or no
16:54:24 <rbrunner> If yes, why don't we simply "load" the smartphone / that app with some suitable enotes before we leave house? As a Monero wallet in the truest sense of the word
16:55:20 <m-relay> <f​:monero.social> Even before a smartphone app it might be possible to use a basic script in Termux. According to their documentation there's an NFC API, even though I would yet have to evaluate it's capabilities. It does offer a monero package in their repositories.
16:57:28 <m-relay> <f​:monero.social> Then for a smartphone app, the recently funded XmrSigner may be of great help once implemented. Continuing from there, I imagine the development of specialized hardware for those users who'd be interested in using one. Those totally fine with a simple app may of course stick with that.
16:58:44 <m-relay> <f​:monero.social> Can you elaborate on the enotes idea?
16:59:53 <rbrunner> Well, if reaching to your special RPC daemon at home is not feasible, like I argued, why not carry around everything needed?
17:00:04 <rbrunner> That would be A) the secret spend key, for signing
17:00:31 <rbrunner> B) some enotes that you chose at home to copy to the smartphone, that the app can later hand to the POS system to construct a tx
17:00:55 <m-relay> <o​frnxmr:xmr.mx> Plowsof, does this overlap with gift cards? Sorry, i havent read like.. any of this
17:01:18 <rbrunner> So this would be very much like carry around coins and notes in a wallet
17:01:48 <rbrunner> With the same limitations of course: Can't spend what you don't bring with you. But people live with that for hundreds of years :)
17:02:34 <m-relay> <o​frnxmr:xmr.mx> Use gift card, enter pin, gift card is swept w difference returned to the card and reencrypted with the pin
17:02:59 <rbrunner> afk 30 minutes
17:03:14 <m-relay> <f​:monero.social> The idea is to simplify the payment process. Your suggestion seems to be a complication over "having to sync the smartphone" :)
17:03:58 <m-relay> <o​frnxmr:xmr.mx> Merchant would generate a tx that spends the full balance in 2 outputs, one one to merchant, one to change
17:04:08 <m-relay> <f​:monero.social> Does this exist already?
17:04:27 <m-relay> <o​frnxmr:xmr.mx> sort of
17:05:11 <m-relay> <o​frnxmr:xmr.mx> https://github.com/nahuhh/redeem_gift_poc/tree/generate_test
17:05:18 <m-relay> <o​frnxmr:xmr.mx> Plowsof's poc
17:07:31 <m-relay> <o​frnxmr:xmr.mx> Its incomplete but would essentially store the wallet seed on a card, encrypted by password/pin (generste_gift_test), and would be sweepable using redeem_gift.sh
17:11:14 <m-relay> <f​:monero.social> That's an interesting concept that could be added to the merchant code as a secondary payment option.
17:11:19 <m-relay> <o​frnxmr:xmr.mx> A card in this case was just an nfc app
17:11:46 <m-relay> <o​frnxmr:xmr.mx> But considerong you can buy nfc cards on amazon, it should work with a physical card
17:15:05 <plowsof> this concept is different, where the spend key is on the nfc card and it's able to sign transactions given to it
17:16:13 <m-relay> <o​frnxmr:xmr.mx> For yours, the seed is in the nfc, but it trusts the merchant to use it
18:26:45 <m-relay> <p​reland:monero.social> I’ve been trying to wrap my head around in person transactions, and this is always where I have a problem:
18:26:47 <m-relay> <p​reland:monero.social> Let’s say that Person X wants to transact at Merchant Y. Y presents a transaction to X, and X uses their key to sign the transaction. All is well….but how does Y know that the transaction is accurate? The only safe way would be with some form of a UI on Y’s side, which would make the system more expensive. This wouldn’t necessarily be an issue if we can just assume that ev<clipped message>
18:26:49 <m-relay> <p​reland:monero.social> eryone can use a mobile device (which we can’t), but there are still other issues that come with this system (you’d either need to always have a strong network connection to a node, or use a node locally ran by the merchant, which itself has issues)
18:28:44 <m-relay> <o​frnxmr:xmr.mx> Y would run have to have a wallet/node
18:29:39 <m-relay> <o​frnxmr:xmr.mx> Merchants should always use their own nodes, or if not feasible, multiple merchants can share a node
18:29:55 <m-relay> <o​frnxmr:xmr.mx> Like.. at a mall, every store shares the malls internet
18:35:14 <m-relay> <p​reland:monero.social> Yes, but would X use said node in any way?
23:27:21 <m-relay> <s​nowman:tetaneutral.net> Not necessary
23:28:11 <m-relay> <s​nowman:tetaneutral.net> You can do a vending machine with no internet that accepts Monero so long as customer has internet
23:29:34 <m-relay> <o​frnxmr:xmr.mx> The vending machine needs to confirm the tx
23:31:05 <m-relay> <o​frnxmr:xmr.mx> Vending machine cant just be knowledgeless about spent key images