Aha.

<s​yntheticbird:monero.social> I think i've seen this subnet in the blocklist

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

this log level 1

<g​ooglemozilla:matrix.org> What does request 1007 do?

RECEIVED_NEW_TRANSACTIONS, like 50ms laters send 1007

chatgpt says NOTIFY_NEW_TRANSACTIONS

hmm

chatgtp?

im just asking chatgpt what the hell command-100X means in the level 1 logs

there this weird node connecting to peoples node and doing funky stuff with transactions

I think its trying to break dandelion++

<b​oog900:monero.social> it's known: monero-project/research-lab #126

<g​ooglemozilla:matrix.org> Smells like Chainalysis.

yea

<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?

some of my nodes are both clearnet and tor

I should probably add enable-dns-blocklist

<b​oog900:monero.social> it would be a good solution, however our Tor impl is not perfect: 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

<b​oog900:monero.social> it would be a good solution, however our Tor impl is not perfect: 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

<g​ooglemozilla:matrix.org> How will this be fixed?

<e​longated:matrix.org> tx-proxy

<g​ooglemozilla:matrix.org> Isn't this already supported?

<e​longated:matrix.org> Use it ?

boog900

should i stop having my nodes priority-node connect to each other

<e​longated:matrix.org> Oh nvm this is a different issue

<g​ooglemozilla:matrix.org> I don't understand.

If a public client sends a transaction through one of my public nodes

and my public nodes choose my other public nodes as that anonymity stage for dandelion

<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

these trackers can connect to all my public nodes to try and pick up the fluff stage

but this is is probably unlikely

my nodes are unlikely to choose my priority nodes as the initial anonymity stage dandelion all time.

its I assume 1/the number of nodes you are currently connected to

<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?

<b​oog900:monero.social> only outbound connections are used to stem, I would just ban the nodes: github.com/Boog900/monero-ban-list/tree/main

is priority node in bound our outbound connection? what if two nodes have priority-node for each other

that means they are always connected

<b​oog900:monero.social> you can use I2p with monero now, it gets priority for routing your txs if you set Tor as well.

says you have 50 outbound connections

then every 1/50 transactions you get, you'll send it to your other node your are priority connected to

we should probably disable sending txs to priority nodes imo

<b​oog900:monero.social> > is priority node in bound our outbound connection?

<b​oog900:monero.social> outbound

<b​oog900:monero.social> > what if two nodes have priority-node for each other

<b​oog900:monero.social> No clue, probably which eve connects first has the peer as outbound

<b​oog900:monero.social> ever*

<b​oog900:monero.social> > we should probably disable sending txs to priority nodes imo

<b​oog900:monero.social> why?

yea, so the stem phase may be sent to your priority nodes

and an advesary knows what your public nodes are

they can connect to your public nodes and listen for transactions

obviously its unlikely that all your stem transmits will go to another priority node you have

buts its possible

<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

<s​ethforprivacy:monero.social> Done:

<s​ethforprivacy:monero.social> sethforprivacy/simple-monerod-docker cea9d8c

<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:

<s​ethforprivacy:monero.social> `--ban-list=/home/monero/ban_list.txt`

<s​ethforprivacy:monero.social> OR

<s​ethforprivacy:monero.social> `ban-list=/home/monero/ban_list.txt`

<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.

<s​ethforprivacy:monero.social> I've subscribed to changes to the repo so will do my best to keep up with it.

<r​ucknium:monero.social> Seth For Privacy: Thank you!

hmm

If I use a vps with an ipv6 range

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

this can like fight the war against these fake proxy nodes

the nodes don't have to be fast enough for public rpc access, just used for p2p

<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?

or dandelion++ gets replaced

<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?

<g​ooglemozilla:matrix.org> What alternatives are there? I'm not aware of any.

<o​frnxmr:xmr.mx> Tor / i2p

<g​ooglemozilla:matrix.org> Forcing only Tor and I2P usage?

honestly I agree, tor is just much better solution overall. A fully synced node doesn't use that much bandwidth anyway.

We need more nodes on tor. It's also a lot easier to host tor entry nodes than exit nodes

Basically anyone can host a tor entry node, so, hopefully it wouldn't be too much of a strain on the tor network.

<o​frnxmr:xmr.mx> --tx-proxy

<e​longated:matrix.org> Tor/i2p should be bundled, run out of the box

<e​longated:matrix.org> Or maybe that monerod gui can do it ?

<s​yntheticbird:monero.social> dear elongated.

<s​yntheticbird:monero.social> we appreciate your suggestion

<s​yntheticbird:monero.social> you have no idea.

<s​yntheticbird:monero.social> NO IDEA

<s​yntheticbird:monero.social> of how it was a challenging TO TRY to get i2p bundled in monero

<s​yntheticbird:monero.social> There were DRAMA

<s​yntheticbird:monero.social> cross-community drama

<e​longated:matrix.org> GUI route then

<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...

<o​frnxmr:monero.social> Kovri*

<3​21bob321:monero.social> Use feather if you want tor

<o​frnxmr:xmr.mx> Pipe dream

<3​21bob321:monero.social> If i hit you with the pipe you will dream it

<o​frnxmr:xmr.mx> Pipe wallet

<r​ottenwheel:unredacted.org> Hit me with your pipe, daddy! 🍆

<e​longated:matrix.org> Which wallet has gui for monerod? Monero-gui is almost dead; feather has daemon gui on roadmap for months/yrs

<e​longated:matrix.org> Plug n play tor/i2p for monerod would be very good

<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

<e​longated:matrix.org> Sell and sleep

<r​ottenwheel:unredacted.org> Wut u mean wallet GUI for monerod? Maybe monerod gui stuff by eve... plowsof! You know this one!

<r​ottenwheel:unredacted.org> Yes, by @everoddandeven:monero.social.

<e​longated:matrix.org> Yah

<r​ottenwheel:unredacted.org> Just read Revuo. 💅

<r​ottenwheel:unredacted.org> Here. revuo-xmr.com/weekly/issue-218

<e​longated:matrix.org> Yah, I hope it does tor/i2p by default

<r​ottenwheel:unredacted.org> github.com/everoddandeven/monerod-gui

<e​longated:matrix.org> Does it already have tor/i2p or wip ?

<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.

<e​longated:matrix.org> You don’t care if it’s easy to deploy tor/i2p for monerod ? Anyways thanks

<r​ottenwheel:unredacted.org> Yes, I do not care.

<r​ottenwheel:unredacted.org> Also.

<e​longated:matrix.org> Wallet developers don’t want to deal with monerod

<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...

<e​longated:matrix.org> They don’t want to manage monerod 😅 you are so dense

<r​ottenwheel:unredacted.org> Pour dissolvent solution over my head!

<r​ottenwheel:unredacted.org> Anyways, Feather has a built-in Tor daemon, Mysu has a built-in Tor daemon.

<e​longated:matrix.org> GUI and feather haven’t done anything on daemon management front for years, which other wallet is left ?

<r​ottenwheel:unredacted.org> I still don't get what you mean by this, at all.

<e​longated:matrix.org> Dude those are just connecting to remote node , not managing daemon

<r​ottenwheel:unredacted.org> Feather can be Tor-only if user chooses to.

<r​ottenwheel:unredacted.org> You can connect to your own local node through Tor too, you dumb nuts.

This is the monerod-gui github.com/everoddandeven/monerod-gui , most likely a feature requestbas these where not part of the original bounty thatbfunded itn, i can confirm soon

<e​longated:matrix.org> lol 😂 seriously go and read the come again tomorrow morning

<r​ottenwheel:unredacted.org> Ok retard.

<e​longated:matrix.org> lol 😂 seriously go and read the conv again tomorrow morning

<e​longated:matrix.org> Check the mirror

<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...

<r​ottenwheel:unredacted.org> Because you are still making zero sense.

<r​ottenwheel:unredacted.org> Want a remote note? Use a remote node.

<r​ottenwheel:unredacted.org> Have a local node? Use local node.

<r​ottenwheel:unredacted.org> Clearnet? Clearnet.

<r​ottenwheel:unredacted.org> Tor? Tor.

<e​longated:matrix.org> And you can’t make sense of words

<r​ottenwheel:unredacted.org> What the fuck do you keep mumbling about a monerod and tor and daemons and wallet daemons bs?

<r​ottenwheel:unredacted.org> Lol.

Take the bickering to another room

<e​longated:matrix.org> Don’t reply if you don’t understand

<r​ottenwheel:unredacted.org> I am asking so you explain to me.

<r​ottenwheel:unredacted.org> But you haven't?

<r​ottenwheel:unredacted.org> Unless you are the one who doesn't know what he's saying?

<r​ottenwheel:unredacted.org> 🤔

<e​longated:matrix.org> If there a plug and play daemon management gui app which has tor/i2p for monerod ?

<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...

<e​longated:matrix.org> And I was discussing about it but you wanted to argue for no reason

<e​longated:matrix.org> Anyways hope you mature at some point in your life

<r​ottenwheel:unredacted.org> Only fruits mature!

<r​ottenwheel:unredacted.org> They get ripe!

<r​ottenwheel:unredacted.org> But what can we discuss about when you can go straight to the source!

<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!

Oh this isn't the workgroup channel, i should have known as there wasn't 1000 messages running in circles

<r​ottenwheel:unredacted.org> Happy international volunteer day, everyone! 🥳 The prestigious XMR workgroups celebrate all together in this beautiful day! nationaltoday.com/international-volunteer-day

<m​arioob:matrix.org> hello. Is this the official monero app? It says is not verified. flathub.org/apps/org.getmonero.Monero

<m​onerobull:matrix.org> check getmonero.org

Be careful, the "Monero" app is a squatter, as as monero.com. It is owned by cake wallet, and is NOT the monero project.

(they're believed to not be scammers though)

<o​frnxmr:xmr.mx> moneromooo, you should see haveno.com

<o​frnxmr:xmr.mx> Monero.com doesnt pretend to be anything official, (and the links on getmonero are to cakewallet.com)

there is no official anything, even the monero-projects github wallet is the "reference" wallet. you probably mean trusted / safe .. good question

<o​frnxmr:xmr.mx> haveno.com states that they host the official source code repository

<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

<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

I have no idea about haveno, sorry. I only vaguely follow.

<o​frnxmr:monero.social> Just take one look at that website :)

Monero.com doesn't pretend is disingenuous.

It's *monero.com*. That's canonical pretending.

Adding "we're not monero" once they got lots of people incoming ensures some will not notice

It's a giant dick move and it's fucking obvious.

<o​frnxmr:xmr.mx> It says "monero.com by cake wallet" in the header

<m​arioob:matrix.org> indeed the flatpak version is advertised here github.com/monero-project/monero-gui

<m​arioob:matrix.org> however, it feels a bit untrustworthy for not being a verified app.

<o​frnxmr:monero.social> The road to verification has been bumpy

<m​arioob:matrix.org> flathub giving headaches?

<o​frnxmr:monero.social> the process is annoying and doesnt really provide any security

<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.

<o​frnxmr:xmr.mx> Nothing monero is official

<o​frnxmr:xmr.mx> The monero-gui in flathub is maintained by a community member

Revuo Monero Issue 220: November 28 - December 5, 2024. revuo-xmr.com/weekly/issue-220

<b​asses:matrix.org> it is official wallet by The Monero Project

<b​asses:matrix.org> everything maintained by monero-project is official

<o​frnxmr:xmr.mx> Lmfao

<o​frnxmr:xmr.mx> plowsof and ofrn are the coo and ceo, i think we'd know what is and isnt official

<o​frnxmr:xmr.mx> The software is owned by nobody and is maintained by individuals

<o​frnxmr:xmr.mx> Nothing is official

<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.

<o​frnxmr:xmr.mx> reference software? Sure. Official? No.

<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.

<b​asses:matrix.org> lmao

<b​asses:matrix.org> would you cool Tor not official?

<b​asses:matrix.org> would you call Tor not official?

<b​asses:matrix.org> nice fantasy

<o​frnxmr:xmr.mx> Are you cooked?

<o​frnxmr:xmr.mx> Would you call bitcoin core official?

<o​frnxmr:xmr.mx> Or bitcoin cash node official?

<b​asses:matrix.org> yes

<b​asses:matrix.org> search what the word "official" means

<o​frnxmr:xmr.mx> Then youre an idiot, sorry

<b​asses:matrix.org> skibidi toilet

<o​frnxmr:xmr.mx> Bitcoin core is not the official bitcoin implementation

<o​frnxmr:xmr.mx> Its just one of them

<b​asses:matrix.org> .

<b​asses:matrix.org> .

<o​frnxmr:xmr.mx> Cuprate is just as official as monerod

<s​yntheticbird:monero.social> hell yeah we're going to conquest you all

<o​frnxmr:xmr.mx> Funded by community, worked on by community, open source, follows consenaus, shares no code with monerod

<b​asses:matrix.org> keep dodging

<b​asses:matrix.org> this is not what I'm asking

<o​frnxmr:xmr.mx> Youre asking about tor

<o​frnxmr:xmr.mx> i answer your irrelevant nonsense with an equally absurd response

<s​yntheticbird:monero.social> rando, the correct word is *reference implementation*

<s​yntheticbird:monero.social> Cuprate and Monerod are both official. monerod is the *reference implementation*, cuprate is not

<o​frnxmr:xmr.mx> Syntheticbird ^, i said that too

<o​frnxmr:xmr.mx> yet*

<o​frnxmr:xmr.mx> Monerod is only _the_ reference because its the _only_ reference

<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*.

<o​frnxmr:xmr.mx> Core is 1.5 people and a niocat

<o​frnxmr:xmr.mx> Nobody cares what they endorse, if im being perfectly honest

<o​frnxmr:xmr.mx> They dont even care

<o​frnxmr:xmr.mx> 70% of the core team just fucked off without saying goodbye

<o​frnxmr:xmr.mx> The other 30% pops their head up when someone complains about money

<o​frnxmr:xmr.mx> 20/30%**

<o​frnxmr:xmr.mx> The remains 10% is articmine, who doesnt get involved in anything but scaling and research

<o​frnxmr:xmr.mx> Or ducks their head and dodges the transparency report

<o​frnxmr:xmr.mx> Has anyone bothered to sync the old view wallets for xmr? Donations have been coming to that wallet for years

I have several days of scrollback for this channel 0_o

<o​frnxmr:xmr.mx> dont bother

<o​frnxmr:xmr.mx> Wait for kewbits blog post

in this channel as well? lol

might have time in a bit

<s​yntheticbird:monero.social> Wait for mine too

<s​yntheticbird:monero.social> It will be *substantially* more documented

<o​frnxmr:xmr.mx> will you write yours with ai tho?

<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.

<s​yntheticbird:monero.social> yes. SyntheticLllama

<s​yntheticbird:monero.social> yes we both have the same understanding of official

<s​yntheticbird:monero.social> but I also understand ofrnxmr point. Cuprate is not amateur

<o​frnxmr:xmr.mx> The Monero Project = core

<o​frnxmr:xmr.mx> They honestly dont do anytthing.

<b​asses:matrix.org> If someone were to backdoor monero core, everyone is going to be affected, right? Unless I'm understanding something wrong?

<b​asses:matrix.org> monero software by core devs

<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

<o​frnxmr:xmr.mx> The software is signed reproducibly by community, and the sigs repo is maintained by community

<o​frnxmr:xmr.mx> Are you cooked?

<b​asses:matrix.org> are you rotten?

<o​frnxmr:xmr.mx> When is the last pr you know of by a core?

<o​frnxmr:xmr.mx> By core*?

<o​frnxmr:xmr.mx> Every dev working on monero, is a community dev

<o​frnxmr:xmr.mx> All of them

<o​frnxmr:xmr.mx> core doesnt even review code

<b​asses:matrix.org> u didn't understand and don't want to understand

<b​asses:matrix.org> if someone were to backdoor github.com/monero-project/monero

<o​frnxmr:xmr.mx> theyd have to open a pr

<o​frnxmr:xmr.mx> And have community approve it

<o​frnxmr:xmr.mx> And it would have to go through selsta, who is also not core

<b​asses:matrix.org> what we were even discussing about?

<s​yntheticbird:monero.social> skibidi toilet

<o​frnxmr:xmr.mx> youre making false claims about who controls monero. The correct answer is "nobody, and everybody". Core does not control monero

<s​yntheticbird:monero.social> rando you won't change ofrnxmr mind, keep your opinion for yourself

<b​asses:matrix.org> it is me

<o​frnxmr:xmr.mx> Yes, if you know how to write, review or test code

<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?

<o​frnxmr:xmr.mx> It ISNT

<b​asses:matrix.org> LOL

<b​asses:matrix.org> u didn't even read

<b​asses:matrix.org> 0.1 sec reply

<o​frnxmr:xmr.mx> Name the monero-gui devs

<b​asses:matrix.org> selsta

<o​frnxmr:xmr.mx> The monero project aka core is not on the list

<o​frnxmr:xmr.mx> Is selsta core? No

<o​frnxmr:xmr.mx> Selsta is a community funded community dev

<b​asses:matrix.org> core or person is irrelavant, any project under The Monero Project org is considered official by them

<b​asses:matrix.org> core or not is irrelavant, any project under The Monero Project org is considered official by them

<o​frnxmr:xmr.mx> Diego is the only monero-project employee ever

<b​asses:matrix.org> ^ true

<o​frnxmr:xmr.mx> Who is them?

<b​asses:matrix.org> this is the correct way to respond anyone asking this question

<o​frnxmr:xmr.mx> youre an idiot, im done talking tonyou

<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.

<s​yntheticbird:monero.social> fwiw they could all be friends and be at the beach right now

<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.

<s​yntheticbird:monero.social> core members i mean

<s​yntheticbird:monero.social> Articmine looks like a beach guy

<o​frnxmr:xmr.mx> luig bf artic

<o​frnxmr:xmr.mx> Its like rocket science

<o​frnxmr:xmr.mx> The rest dont have duties at all

<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

<b​asses:matrix.org> for sure 👍

<r​avfx:xmr.mx> One be one nice way to be able to grab them all with one scoop

<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.

<s​yntheticbird:monero.social> to get full bullied just after, no shit they decided to not talk anymore

<b​asses:matrix.org> free non-CIA lemonade drink 🍋🏖️

<b​asses:matrix.org> very true

<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.

<o​frnxmr:xmr.mx> Luigi, binary, and Arctic Mine are the only ones left.

<b​asses:matrix.org> moneromooo-monero ???

<o​frnxmr:xmr.mx> No

<o​frnxmr:xmr.mx> Not core

<b​asses:matrix.org> PRs from 2014

<o​frnxmr:xmr.mx> and was never core

<o​frnxmr:xmr.mx> Still isnt

<b​asses:matrix.org> he is considered core to me

<b​asses:matrix.org> not talking about who is core, just early contributors

<o​frnxmr:xmr.mx> HES NOT CORE

<b​asses:matrix.org> these are core, unless you got access to org anything you say is just speculation

<b​asses:matrix.org> .

<b​asses:matrix.org> .

<b​asses:matrix.org> 🤦

<o​frnxmr:xmr.mx> luigi bf are only ones with repo ownership afaik. articmine doesn have

<o​frnxmr:xmr.mx> ^ rofl

<b​asses:matrix.org> yes, in my eyes lool

<o​frnxmr:xmr.mx> Mooo doesnt consider themself to he core

<o​frnxmr:xmr.mx> Core doesnt consider mooo to he core

<o​frnxmr:xmr.mx> Fanboyism doesnt change the fact that the core team is an material thing

<o​frnxmr:xmr.mx> Its not up for interpretation

<b​asses:matrix.org> idc what core thinks 🕶️

<o​frnxmr:xmr.mx> You dont care what mooo thinks eitherb

<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

<o​frnxmr:xmr.mx> rofl

<o​frnxmr:xmr.mx> You clearly dont understand the role of core

<o​frnxmr:xmr.mx> And youre just slapping definitions on things that "feel good"

<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

<b​asses:matrix.org> why attacking core's role is any relevant?

<b​asses:matrix.org> you win what ever arguement you thing is happening rn, gg

<b​asses:matrix.org> you win what ever arguement you think is happening rn, gg

<b​eneficialsource:matrix.org> Alright now everyone hug and kiss

<f​:monero.social> Now that this is settled ...

<f​:monero.social> Based on the concept posted in repo.getmonero.org/monero-project/c…als/-/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.

<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.

<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.

<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?

With "offline" you mean that the wallet is not connected to a daemon at the time it constructs a tx?

<f​:monero.social> Yes.

Does that even work in principle? Where would the wallet get the necessary decoys from in such a situation?

<f​:monero.social> Sorry, no. *Construction* is done by a live (viewonly) wallet. *Signing* is done by the offline wallet.

<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.

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?

<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.

<d​iego:cypherstack.com> Though that may have been a sort of bounty system. I'd have to ask fp again.

<o​frnxmr:xmr.mx> Yeah, i forgot

<o​frnxmr:xmr.mx> I remember when sarang went to ffs for the first time

<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.

its been 10 years since this proof of concept demonstrating bitcoin offline nfc payments reddit.com/r/Bitcoin/comments/2nuq5…et_completing_a_bitcoin_payment_via

"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?

for example bounties.monero.social/posts/159/10…ss-monero-point-of-sale-android-app

<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.

<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.

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 ...

a few mobile wallets have background syncing enabled by default now... "pocketchange".... possibility of "skip sync" can be implemented to wallets bounties.monero.social/posts/79/0-2…kip-sync-feature-to-a-monero-wallet

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

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

<f​:monero.social> In any case, we cannot reasonably create demand before having the supply.

From that bounty: "Waterdrought· 7 months ago ill give it a shot" Or maybe not :)

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.

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

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?

<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.

<o​frnxmr:xmr.mx> Wait til they find out about 8 input limits

<o​frnxmr:xmr.mx> sneedlewoods, pls fix :P

<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.

<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.

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 ...

How will the POS system find those special RPC daemons that the customers run to construct unsigned transactions?

I mean, technically

"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

<f​:monero.social> The offline device provides an identification and the URI of the RPC.

<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.

<f​:monero.social> The offline device provides an identification and the URI of the RPC.

<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.

<f​:monero.social> The offline device provides an identification and the URI of the RPC.

<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.

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?

People nowadays just don't run their own servers facing the Internet, seems to me.

For various reasons.

<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.

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

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? :)

<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.

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

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

<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".

<f​:monero.social> Both Tor and I2P will happily block any attempts to connect on their network layer if remote isn't authenticated.

<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.

<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.

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?

I think you mention that a smartphone app could do here, right, at least at the start?

<b​eneficialsource:matrix.org> So did we end up hugging and kissing or no

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

<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.

<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.

<f​:monero.social> Can you elaborate on the enotes idea?

Well, if reaching to your special RPC daemon at home is not feasible, like I argued, why not carry around everything needed?

That would be A) the secret spend key, for signing

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

<o​frnxmr:xmr.mx> Plowsof, does this overlap with gift cards? Sorry, i havent read like.. any of this

So this would be very much like carry around coins and notes in a wallet

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

<o​frnxmr:xmr.mx> Use gift card, enter pin, gift card is swept w difference returned to the card and reencrypted with the pin

afk 30 minutes

<f​:monero.social> The idea is to simplify the payment process. Your suggestion seems to be a complication over "having to sync the smartphone" :)

<o​frnxmr:xmr.mx> Merchant would generate a tx that spends the full balance in 2 outputs, one one to merchant, one to change

<f​:monero.social> Does this exist already?

<o​frnxmr:xmr.mx> sort of

<o​frnxmr:xmr.mx> github.com/nahuhh/redeem_gift_poc/tree/generate_test

<o​frnxmr:xmr.mx> Plowsof's poc

<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

<f​:monero.social> That's an interesting concept that could be added to the merchant code as a secondary payment option.

<o​frnxmr:xmr.mx> A card in this case was just an nfc app

<o​frnxmr:xmr.mx> But considerong you can buy nfc cards on amazon, it should work with a physical card

this concept is different, where the spend key is on the nfc card and it's able to sign transactions given to it

<o​frnxmr:xmr.mx> For yours, the seed is in the nfc, but it trusts the merchant to use it

<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:

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

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

<o​frnxmr:xmr.mx> Y would run have to have a wallet/node

<o​frnxmr:xmr.mx> Merchants should always use their own nodes, or if not feasible, multiple merchants can share a node

<o​frnxmr:xmr.mx> Like.. at a mall, every store shares the malls internet

<p​reland:monero.social> Yes, but would X use said node in any way?

<s​nowman:tetaneutral.net> Not necessary

<s​nowman:tetaneutral.net> You can do a vending machine with no internet that accepts Monero so long as customer has internet

<o​frnxmr:xmr.mx> The vending machine needs to confirm the tx

<o​frnxmr:xmr.mx> Vending machine cant just be knowledgeless about spent key images