Hey guys, just wondering, if I am mining monero using my own node and not a pool, do I need to have incoming connections in order to mine anything?

<k​ewbit:matrix.org> No

<k​ewbit:matrix.org> You don’t need internet to do math

<k​ewbit:matrix.org> Technically you could mine coins in your head

ok just wanting to be sure

I think the 6502 in my brain isn't capable :P

<k​ewbit:matrix.org> You can always store them in the brain after anyway with brainwallet.io

lmao

would be interesting to see that done in BASIC on a C64. Then, try assembly

<k​ewbit:matrix.org> well if you start from genesis you could mine some on a gameboy colour

My Amiga has GCC on it as well as python (2.4 I think)

<k​ewbit:matrix.org> the only thing i can do in assembly is write a sha265 hash step

<k​ewbit:matrix.org> oh and I can also hack pokemon red and blue

I would have to dig out my C64 assembly books. All I can remember is lda

lda, sta, cmp, bne, jmp, jsr

<k​ewbit:matrix.org> did you know the C compiler is written in C

basic math

hi. Sneedlewoods overfunding is being allocated in full

<r​ottenwheel:kernal.eu> luigi1111 what do you mean by allocated in full? Like he's receiving the goal + the extra XMR?

<r​ottenwheel:kernal.eu> ...as a one-time thing, or as a change for proposals moving forward? 🤔

one time

<r​ottenwheel:kernal.eu> 👍

<r​brunner7:monero.social> Thanks, luigi1111 !

that makes sense to me.

sneedlewoods removed from the overfunded list, please come back soon :( github.com/plowsof/scrape_ccs_fr/compare/main...refunded

<3​21bob321:monero.social> precedent has been set

<k​ewbit:matrix.org> What does this mean for sneedlewood

<3​21bob321:monero.social> Gets all the moneros

<k​ewbit:matrix.org> Good

<3​21bob321:monero.social> Ima just gonna wait for all the others to put there hands up

<3​21bob321:monero.social> Like fcmp created a dev price hike

<k​ewbit:matrix.org> I think it was his modesty that earned him that

<k​ewbit:matrix.org> Or her

<p​lowsof:matrix.org> so kewbits update was 4 days ago , for milestone 2, the api repo.getmonero.org/monero-project/c…als/-/merge_requests/489#note_26721

<p​lowsof:matrix.org> there was a situation* where a front end app was released but the source code was not shared publicly (milestone 1, which is not being claimed)

<p​lowsof:matrix.org> monerobull raised the first question about source of the test app

<k​ewbit:matrix.org> It’s shared

<k​ewbit:matrix.org> WTF

<p​lowsof:matrix.org> whats shared and whats not shared for milestone 1 (please clarify)

<k​ewbit:matrix.org> Oh semantics

<k​ewbit:matrix.org> Is it?

<k​ewbit:matrix.org> No it’s not milestone 1 because I didn’t number the milestones

<p​lowsof:matrix.org> ok ignore the order (milestones have been claimed out of order before)

<k​ewbit:matrix.org> It ended up completely fishing the protocol first basically yeah

<k​ewbit:matrix.org> Finishing*

<k​ewbit:matrix.org> github.com/KewbitXMR/flutter_haveno

<k​ewbit:matrix.org> and its published in full with docuemtnation and AGPLv3 licencing

<k​ewbit:matrix.org> I did want to go for a monorepo,but that would be less benfit to the community

<k​ewbit:matrix.org> Seperation of concerns makes more sense, this is a ususable component tht other dexs can choose to integrate

<k​ewbit:matrix.org> Seperation of concerns makes more sense, this is a reususable component tht other dexs can choose to integrate

<k​ewbit:matrix.org> Seperation of concerns makes more sense, this is a reususable component that other dexs/apps can choose to integrate

<p​lowsof:matrix.org> i need to be sure as a coordinator that no rules are being broken here / people are aware what happened after an app was released, then removed after someone asked where the source was. for context, the payout request for the api has had positive sentiment from woodser the lead dev on this

<3​21bob321:monero.social> Ccs compliance manager too

<k​ewbit:matrix.org> maybe i'm just not following the concern her

<k​ewbit:matrix.org> maybe i'm just not following the concern here

<k​ewbit:matrix.org> can someone explain in simple terms please

<p​lowsof:matrix.org> some may not know the details and have only seen you release app, be asked where the source is and then delete every post where you announced it, so im throwing it out there for you to clarify

<p​lowsof:matrix.org> seems that you have clarified it

<k​ewbit:matrix.org> I've offered builds so many times then monerobull shouts at me

<k​ewbit:matrix.org> it's not fully working

<k​ewbit:matrix.org> it's on my machine im not push my entire project to github I dont eveno know if this is legit yet

<k​ewbit:matrix.org> I've pushed a milstone which is basiclly the keystone of the project anyway

<3​21bob321:monero.social> Legit means works?

<k​ewbit:matrix.org> even with that interface people can start making apps really easily for haveno

<3​21bob321:monero.social> Too legit to quit

<k​ewbit:matrix.org> i have builds that mostly work yeah but I slowed down on the work for the last 2 weeks

<k​ewbit:matrix.org> woodser: you've done the most amount of testing

<k​ewbit:matrix.org> probalbly

<k​ewbit:matrix.org> i think on every OS

<k​ewbit:matrix.org> apart from ios

<k​ewbit:matrix.org> to be frank

<k​ewbit:matrix.org> the moment I see at least 5 conformations, all of the UI is going up so I can request the next milestone immediately lol

<k​ewbit:matrix.org> i guess the first leap of faith is hard?, imagine taking a four month leap of faith :D

<k​ewbit:matrix.org> near abouts, lost track

<s​needlewoods:monero.social> Thank you so much luigi1111, everyone who voiced their opinion in favor of me, and the very generous donors of course.

<s​needlewoods:monero.social> It's stunning to see all the support ❤️

<c​t:xmr.mx> congrats, you deserve it 🚀

<k​ewbit:matrix.org> Can I just ask why you're wording this as if it was something suspicious, this was in a public chat room remember? Monerobull was there and so was you. He has something against it, he doesn't like me releasing the app for testing for whatever reason, i'm not sure, maybe he is thinking it could be backdoored but it's clear he is going to be one of the decision makers when I receive<clipped message>

<k​ewbit:matrix.org> the bounty, so I'm not just going to ignore what he says so I removed it, and I I encourage you to just look back at the logs too because these are all clear public information. I'm actually quite annoyed, it just seems like every attempt I make, even completing a milestone is not enough. So please can you just tell me now if its enough?

<s​yntheticbird:monero.social> > \> "monerobull against"

<s​yntheticbird:monero.social> > \> \* checks sgp vs ofrnxmr war map \*

<s​yntheticbird:monero.social> > \> checks out

<k​ewbit:matrix.org> nice, ignored :)

<3​21bob321:monero.social> Against you doing the ccs?

<p​lowsof:matrix.org> kewbit: do you realise monerobull is was one of the main people pushing for you to be awarded both bounties + the ccs funds?

<k​ewbit:matrix.org> i dont know where this bloody contention i coming from then

<k​ewbit:matrix.org> like what's going on here

<k​ewbit:matrix.org> is there like an actual concern?

<k​ewbit:matrix.org> im confused why you brought up the convo like that suddenly

<k​ewbit:matrix.org> i feel like i've done what I can up until no so I'm just going to leave with you guys to talk about internally or whatever needs to be done, it sounds like there is some concerns if there is then tell me perhaps we can alleviate them?

<k​ewbit:matrix.org> just imagine your me for a sec, you come out with some builds, it should be exciting moment for everyone, and then you hit a milestone thats good too right?

<s​yntheticbird:monero.social> Yup

<s​yntheticbird:monero.social> Im excited

<p​lowsof:matrix.org> if it gets brought up i can point to your clarifications here. not much else to say on the matter

<k​ewbit:matrix.org> its open source thats great too

<k​ewbit:matrix.org> licence exactly how you wanted which is another plus

<k​ewbit:matrix.org> i even said that ill probably post the next milestone right after this one is finalised, so overall we should be in a happy place lol

<k​ewbit:matrix.org> so im sure now you can understand why i am so confused with this

<s​yntheticbird:monero.social> Kewbit in my limited experience in this community you must wait at least an entire day to start seeing reactions

<s​yntheticbird:monero.social> Im excited

<s​yntheticbird:monero.social> Im sure others are. But will express themselves in 12 hours or 24 hours

<k​ewbit:matrix.org> ok lol i will keep that in mind

<h​avenouser:monero.social> kewde.gitbooks.io/protocol/content/data-storage-network/smsg.html

<h​avenouser:monero.social> particl.wiki/learn/marketplace/smsg

<k​ewbit:matrix.org> easy

<k​ewbit:matrix.org> there might have to be a token for it not to fail though

<k​ewbit:matrix.org> it has to cost something to spam

<k​ewbit:matrix.org> maybe each message you send the block gets harder within a certain peroid

<k​ewbit:matrix.org> decentralized market

<k​ewbit:matrix.org> now you're looking for trouble

<k​ewbit:matrix.org> hehe

<k​ewbit:matrix.org> openbaazzar didnt last long

<o​frnxmr:monero.social> That is basicswapdex (smsg)

<k​ewbit:matrix.org> Yeah market is a bit risky for u though

<o​frnxmr:monero.social> Howso

<k​ewbit:matrix.org> Deathwish

<o​frnxmr:monero.social> Elaborate

<k​ewbit:matrix.org> You think you’ll be that one guy who gets away with it? They all do 😂

<o​frnxmr:monero.social> ?

<o​frnxmr:monero.social> In english

<k​ewbit:matrix.org> Everyone who’s tried making any kind of market place has ended up dead or in prison

<o​frnxmr:monero.social> 💀

<k​ewbit:matrix.org> You’ve specifically documented a marketplace

<k​ewbit:matrix.org> To buy and sell goods in a decentralised fashion

<k​ewbit:matrix.org> lol

<o​frnxmr:monero.social> In that case, yes i think i'll get away with it

<o​frnxmr:monero.social> More accurately, idgaf what feds think

<h​ardenedsteel:monero.social> @hinto:monero.social hey, what do you think about using (or moving) [your guide](github.com/hinto-janai/malvarma) on docs.getmonero.org?

<k​ewbit:matrix.org> 🤟🏿

<k​ewbit:matrix.org> Nice

<o​frnxmr:monero.social> i'm not a part of particl marketplace, but basicswap is intentionally intended to have no centralization. You can't stop me from swapping my xmr. Can't force me to delist etc.

would this work?

<s​yntheticbird:monero.social> `"Imgur is temporarily over capacity. Please try again later."`

<s​yntheticbird:monero.social> ig it would work

try this twitter.com/Monero_TV/status/1847281176513245403

I think there is a better way to do it, essentially you can assume that the seller is connected to monerod while you can not assume this for the customer. So I thought of a wallet (I would call gatling) whish would essentially ever when needed restructure the outputs to fraction them aligned with the planed/learned spending behaviour to minimize tx fees and have enough reserve. When offline in the store seller would provide

current fee estimate, receiving address and amount and gatling would then create a signed transaction and transfer this one via UR/NFC/Bluetooth/Sound t the POS wallet, with the return addresses, to a change address (for reorginizing later (when online). How there would be a lot of fractioned outputs gatling would keep track of it that it comes never to a double spend without knowin what is going on the chain while paying.

The seller will get the signed transaction and submit the tx himself and with 0conf now you can make one purchase after another as much fractioned amounts are available. Btw. this CCS will bring gatlin also closer to ever exist - because I would use it in gatling, too: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/495 So who would be interested that gatling will ever exist could help to get me in

first place this PR merged (which will make XmrSigner actual usable for serious use cases) and give also the base for other offline signing solutions and a partial base for something like gatling.

I try later to update the CCS (I procastinated a lot on that, how I'm always between not focused and overwhelmed and hyperfocused.

💪

:D thank you plowsof, you are always there to cheer one up! :)

could something be done in Carrot to simplify this? cold signing via NFC would be the ideal point of sale solution

got my upvote btw

Thank you very much for you support geonic :) About Carrot I have still no idea what it is about, I have download a paper when I remember it correctly and still open in one of the 300 open tabs to process in my brain. About NFC (what I would also like) it is probabably not widely enough adopted to realy on it, I think UR needs to be always the fall back, seller and customer able to support, and all other transmission means

should be optional and somehow autodiscover. I got a nice XmrSigner from XmrStreet, if he would add a bit a space for a lipo you could do this part even with the XmrSigner, so you would be able to go to various stores to make your groceries/shopping with that device without the need to take a (smart)phone with you. Also There was a (smart) watch where you could run AOSP on it, or even building one from scratch (once a cool

use case for it) - but both would have no nfc, but still could transact via UR code, and the watch probably through sound...

I will today first make update my proposal, normally I prefer always charging for deliverables instead of time, only because I needed so much time for the last CCS (i took over as is actually) and burned myself with time/energy invested and burned out I wanted to take out the stress and get that CCS paid by hour instead deliverabled how there could also pop up a lot of unforseen challenges (which allways take up more time

then straight coding). But I can also see that on the receiving end it is better to pay for deliverables then for time. So I have some question, I wanted to charge 1xmr per every 2h promodoro session, but then xmr/usd rate got up and I see all the time what drama it is with rates, how I can't take too much drama at the moment I lowered the rate, not the exchange rate went down again :D (how ironic). But anyway, should I lt

it like it is, or I calculate how much time I estimate it takes me and multiply by 3 (what it almost always comes out except it is something really simple), and set milestone payouts for deliverables?

what about doing this as a plugin for BTCpay/Moneropay ? I imagine the merchant will only want to run one piece of software that keeps track of everything.. unless you plan for gatling to replace BTCpay/MoneroPay? then all that’s left is to publish the specification for mobile wallets to follow so they know how to build such transactions

Gatling itself would only be the mobile wallet (part, can think in capsule that also in a ready to use lib for other wallets), on the receiving side it could in my opinion already be used with minor changes on Feather, ANONERO and when my PR's are merged also on monero-gui. Of course not in a pleasant way, so on the POS side there would be still more work to be done for the payment process to be simply smooth, at least like

a card terminal payment, in best case even easier. BTCpay/MoneroPay I have not looked in yet, but when I will be on the point to write gatling, or better even before writing the lib yet I will look into it - but I think that is meant mostly for only payments (or?).

<1​0934dfasl:matrix.org> im trying to learn to code, im planning to make a simple web app but i want to make it xmr related? can anyone give me any ideas. i dont want to do stuff thats already been done like a get to know xmr website etc. or it doesnt have to be a webapp necessarily but anything relatively simple for a beginner project that relates to xmr? like something perhaps that interacts with the pr<clipped message>

<1​0934dfasl:matrix.org> e-existing codebase but in a really simple way?

<1​0934dfasl:matrix.org> im trying to learn to code, im planning to make a simple web app but i want to make it xmr related? can anyone give me any ideas. i dont want to do stuff thats already been done like a get to know xmr website etc. or it doesnt have to be a webapp necessarily but anything relatively simple for a beginner project that relates to xmr? like something perhaps that interacts with the pr<clipped message>

<1​0934dfasl:matrix.org> e-existing codebase but in a really simple way? Ideally I would be able to accomplish it in Python. Or maybe I was thinking of doing somethign ML related that would help me predict future XMR prices using a certain algorithm or would that be a waste of time?

<l​ordx3nu:matrix.org> Episode 5 of attack of the poisoned outputs has been uploaded. in this one, I talk about a hypothetical cospend attack that could occur to somebody accepting donations in Monero and then using a KYC exchange. to highlight this, I talk about the Canadian Trucker protest in 2022.

<l​ordx3nu:matrix.org> links: youtube.com/watch?v=Cu2dk78165Y

<l​ordx3nu:matrix.org> odysee.com/@anti_moonboy:7/AotPO5:7

<l​ordx3nu:matrix.org> rumble.com/v5j6cod-aotpo-episode-5-…get-an-individual-collecting-d.html

<r​ottenwheel:kernal.eu> xenu ya cállate, baboso.

vthor: most merchants use BTCPay/MoneroPay to keep track of sales, generate invoices etc. it’s used for online stores and in-person. safe to assume that the merchant will be using something like that instead of a desktop wallet

on the user side, I think you’d find more willing donors for a library that existing mobile wallets can integrate rather than a completely separate/brand new mobile app

most merchants use BTCPay/MoneroPay to keep track of sales, generate invoices etc. it’s used for online stores and in-person. safe to assume that the merchant will be using something like that instead of a desktop wallet" <- *thumbsup* and when I think longer about it it would maybe improve acceptence if there are "easy" solutions like the CC terminals.

<o​frnxmr:monero.social> Moneronodo is to include moneropay

"on the user side, I think you’d find more willing donors for a library that existing mobile wallets can integrate rather than a completely separate/brand new mobile app" <- well gatling is only in my mind because I want in future use exclusively xmr to make all purchases (or at least as much as possible). When I tried with Monerujo 2 years ago I have seen that it was not the UX needed to do so. Because you want to

purchase quick and often frequent. You stop somewhere, get something to drink there, some gas here, some snack there and a meal here. And then - you have no internet where you want to pay. So gatling spooks only in my head because I want to have it work IRL and promote to abolish fiat - but can't sell that if you need to wait 10minutes between purchases. Well it was mostly my error because I was not thinking about how it was

working under the hood, with more small transactions I could have avoided that issue somehow, but you can also not expect the use to prepere the outputs in a certain way that this would be possible (if you are all the time online). So my first desire is to get this working and I think a combination of libs and wallet to archive exactly that with a pleasant UX and hope that othr come up with even better integrations/wallets of

it. But at the moment I need to close first all the open tasks - which also like this CCS will be a stepping stone I can leverage later to archive that vision.

yeah if it helps you as a proof of concept. just saying that mobile wallets generally don’t receive community support whereas libraries do.

jeffro256: do u think Carrot can simplify building these types of offline transactions to be broadcast by the merchant?

<j​effro256:monero.social> Not Carrot itself, but FCMP++ will allow for offline signing

<a​nhdres:matrix.org> Sounds like monerujo's pocketchange

<j​effro256:monero.social> With FCMP++, you could have a mobile wallet that signs a transaction offline, then sends the partial tx over NFC to the merchant, then send it to a watchtower server who completes the membership proofs and broadcasts

<j​effro256:monero.social> With RingCT currently, the CLSAG needs to bind to the ring member indices, which means you can't sign offline or if you do sign offline, you'll have stale decoys

<r​ucknium:monero.social> IMHO, this user story is not the low hanging fruit for adoption right now. And it's becoming a less likely scenario each passing day.

<r​ottenwheel:kernal.eu> ICYMI weekly workgroup meetings will be featured in `Revuo` tab on Feather Wallet from v2.7.0 onwards. Kudos to \tobtoht for that; hopefully we'll drag a bit more of community engagement as result.

<r​ottenwheel:kernal.eu> matrix.monero.social/_matrix/media/…/kernal.eu/uTLvNpVHubVJMbwlHrWxIqYB

<j​effro256:monero.social> I don't know. At least where I'm at, internet and those little PoS systems go out a lot. Having some agreed upon NFC protocol that lets one be a broadcast crutch for the other would definitely increase reliability. Also an offline NFC PoS protocol would let people effectively broadcast transactions directly from hardware wallets. All this stuff is a while off tho

"Sounds like monerujo's pocketchange" <- interesting. will look into.

"which means you can't sign offline or if you do sign offline, you'll have stale decoys" <- can you please elaborate on that? It does mean that you privacy lacks, bu you want lose the change, or?

<j​effro256:monero.social> Be warned though: monerujo's pocketchange input selection algorithm is pretty terrible for privacy last time I checked

"MHO, this user story is not the low hanging fruit for adoption right now. And it's becoming a less likely scenario each passing day." <- what will be less likely each passing day?

<j​effro256:monero.social> vthor: the decoy selection algorithm in Monero needs to be updated on the current state of the chain, specifically, the distribution of outputs across blocks. The gamma statistical distribution used to select decoys from the chain heavier favors newer outputs because that mimics real-world spending patterns (at least it's supposed to, Rucknium would have a pretty good idea about h<clipped message>

<j​effro256:monero.social> ow well it does or doesn't). So if your chain data is stale, then your decoy selection is going to look wonky statistically from online people's decoy selection

<j​effro256:monero.social> Long story short, bad for privacy

"Be warned though: monerujo's pocketchange input selection algorithm is pretty terrible for privacy last time I checked" <- well, honestly I (personally) would have on that use case not the same privacy expectation, but I still guess through each reorganizing you would make only te transactions of the day linkable....

"the decoy selection algorithm in Monero needs to be updated on the current state of the chain" <- this info needs to come from the own (view only) wallet - or could be provided from the seller on purchase?

If I get it right that is even information monerod has, ad not even the wallet would be necessary, or I am wrong?

<j​effro256:monero.social> vthor: I guess it could be provided by the seller. To be fair, there's good chance that it could be faked, same as using an untrusted node

"Long story short, bad for privacy" <- how bad could be a question. How I said if you purchase a coke, 40l of gas, a burger and a toll (well this will never happen :D ) then it is not amazing but for me it would be still good enough if not linkable after the next reorg

<j​effro256:monero.social> It would be harder to fake the FCMP++ tree root, as it is contained in the block blob

<j​effro256:monero.social> next reorg?

"vthor: I guess it could be provided by the seller. To be fair, there's good chance that it could be faked, same as using an untrusted node" <- well, still, I think privacy would be much better as CC...

"next reorg?" <- sorry should have maybe used a better term. The idea is to create small enough outputs which are still high enough to uses few outputs per payment. each payment one or more outputs, and the change to a new address. That special wallet keeps track of the fractioned outputs and spends only this outputs, on the next time it is neccesarry it will collect all the changes and create new fractions (could or could

not be shuffled with the unspent fractions).

So the wallet would work in two modes, one while only (and necessary) to create a stock of fractions (like say like 5, 10, 20 and 50 notes), then the offline mode on purchase let's say you pay 3.5 (so it will send the change to a new output, $5 gone, and the bag of change get thrown in the car), next purchase $3.6, but there is no more $5 bill, so take the $10 (change $6.4 into the back ino the trunk in the car), now a meal

$56, the smallest fractions left over $20 and $50 (change $14 in a bag into the trunk). Now arrived at home I will take some bills out of the drawer (online mode) and bring the bags with coins to the bank to exchange it against bills and reload the wallet for offline mode.

Of course this wallet can never be shared, because the wallet keeps track in the own db until next time online and is for that sure it will not double spent. (So I used with reorg a bad term, because there is a term in wallet stuff for it, need to think of a better word, maybe restock, reload, shuffle, don't know - but I hope the idea is clear)

thanks jeffro256

a​nhdres: "Sounds like monerujo's pocketchange" <- still still sound similar?

yeah, thanks jeffro256 :)

anhdres: remember we spoke about an NFC PoS protocol back at MoneroKon ‘23

<r​ucknium:monero.social> vthor: I think people having Monero-capable smartphones without internet access is becoming less common globally. Making payment systems easier to use and more reliable for online merchants would get adoption more efficiently IMHO.

ruckmium: I understand thank you, and I assume you are living in a city (like probably moste peole on earth), but I see some things different, people most interested in having there peace from governments try to get out of urban areas, more people like myself don't want to use a phone (in my case I only take it with me when I really need and when I need data I would need to top up - but even then it is not sure I will have

data where I would purchase something). Well there are to issues in one wrapped I should unpack. One issue with quick and frequent payments will happen probably more in areas with good coverage (but would force me to have a data plan only to pay with monero or beg for wifi) and the other in non urban areas, frecuency and speed mostly not much that issue, but more online connectivity. While I'm not so much concerned about over

all adoption I'm more concerned about "deep" adoption (mean not going back and forth fiat or other crypto) because I think this is the only way to get rid of fiat and governement. If I can buy my groceries and and taco on the corner almost as easy with xmr but with the benefit of getting rid of gov, xmr becomes more stable in value (although it is already pretty stable) against goods (only important messure for using monero

like money). I personally don't see xmr like just another crypto or currency, but to get rid of gov an finally starve the beast. But if I would go just now go around the corner, get a coke, then some bananas and a meal (in three different POS) and I tranfered a amount from my wallet on the pc to the phone, I would not be able to return in 15-20min, while with cash and card I would. If I would go in some less urban areas (and

that can even mean still in the city) I could not be able to pay (without asking the merchant to share his wifi with me). I'm aware with preperation the first would be possible (but you can't expect this from a "normal" user. 10 minutes are not acceptable, so rapid 0conf could lead to a much "deeper" adoption.

<a​nhdres:matrix.org> Pretty much, yeah. It'll randomly decide how many outputs to create (between a set limit) of the size you decide based on your usage.

<a​nhdres:matrix.org> Back in the day where we still had NFC support in Monerujo. Nobody used it! But I guess it could be brought back.

that is cool, yeah NFC is a bit difficult, not each device has it and it is off by default. So I think while NFC is nice to have, the two main channels I see are UR code and via sound. Since when exists that feature in Monerujo? I try to check it out again the following days.

<a​nhdres:matrix.org> It was on old versions, I don't remember now why we discontinued it

<a​nhdres:matrix.org> We thought NFC was cool, but nobody complained when we took it away

<a​nhdres:matrix.org> You could both read and write NFC tags with it if I don't remember wrong

Thank you anhdres for you answers :) I will look into it again.

<a​nhdres:matrix.org> Here's a quick read: anhdres.medium.com/monerujos-pocket…it-is-and-how-it-works-8e1ea1f7489e

<o​frnxmr:monero.social> It was broken

<o​frnxmr:monero.social> probably old lib stopped working with new versions or something, but it was broken

<r​ottenwheel:kernal.eu> recanman

<o​frnxmr:monero.social> Nfc to transfer payment requests is clutch

what means "is clutch"?

<o​frnxmr:monero.social> Comes in handy

ah, cool, thank you, was scratching my head if this is something good or bad :) Yeah if it would work most of the time it would be great.

pocketchange is cool, it solves one of the issues vthor mentioned. I’ve never used NFC for P2P payments so not surprised it wasn’t used.

merchants is another story. would’ve loved to pay for my beer at Paralelni Polis via NFC. it didn’t help that reception was spotty there

the use case I think about is paying for your subway fare with Monero. or anywhere with bad reception. merchants already need connectivity to process CC transactions so this would make paying with monero no different from any other tap-to-pay tx

<a​nhdres:matrix.org> Yeah, it wasn't at first, but when it did, I wasn't worth to fix it. Did you use it?

<r​ecanman:kernal.eu> It doesn't work with traditional RingCT because of how transactions are signed, I'm sure jeffro could explain this better than I can

no I’m on iOS ):

<r​ecanman:kernal.eu> To sign transactions partially and then transmit them with a centralized server

<o​frnxmr:monero.social> I tried and failed

<r​ecanman:kernal.eu> Based on my understanding, the new model should help with that. Someone should create a CCS to create some integration/develop a protocol

<a​nhdres:matrix.org> Well of you ping m2049r: enough he may even bring it back

<p​lowsof:matrix.org> the monerokon team where looking into an off the shelf hand held point of sale device (prints receipts / nfc and camera) that would talk to a payment processor

<r​ecanman:kernal.eu> Does anything like that exist?

<r​ecanman:kernal.eu> Android app would work

<o​frnxmr:monero.social> I'm waiting for --proxy support

<p​lowsof:matrix.org> yeah, some other crypto projects put their own aps on it (it is indeed an android~ thing)

<o​frnxmr:monero.social> Yea

<p​lowsof:matrix.org> i forget the name..

<o​frnxmr:monero.social> Hotshop almost added nfc

<o​frnxmr:monero.social> Chrome on Android supports nfc

<r​ecanman:kernal.eu> There needs to be standardization of a protocol before 'adding' it?

<o​frnxmr:monero.social> Yeah there was a POS terminal or 3 for btcpay iirc

<o​frnxmr:monero.social> its built into chrome

<r​ecanman:kernal.eu> I mean the protocol for Monero and NFC

<o​frnxmr:monero.social> Its just transmitting a payment request uri

<r​ecanman:kernal.eu> reddit.com/r/teslamotors/comments/drksso/

<r​ecanman:kernal.eu> Here's an example for tesla car keycards authentication

<r​ecanman:kernal.eu> Oh

<r​ecanman:kernal.eu> Haha, right

<h​into:monero.social> HardenedSteel: feel free to take it

<r​ecanman:kernal.eu> I meant for the transmitting of partially-signed transactions

<r​ecanman:kernal.eu> As part of FCMP

<r​ecanman:kernal.eu> As part of FCMP and Seraphis

<o​frnxmr:monero.social> Is it licensed hinto @hinto:monero.social: ans is it on git?

<3​21bob321:monero.social> just give credit to hinto

<3​21bob321:monero.social> hinto grants ™️

<h​into:monero.social> github.com/hinto-janai/malvarma

<3​21bob321:monero.social> careful plowsof its rust 😁

<h​ardenedsteel:monero.social> its better to license also the content

<h​ardenedsteel:monero.social> not just MIT

<p​lowsof:matrix.org> recanman searching this will find it "Orange Portable Handheld Android POS System with Bluetooth"

<p​lowsof:matrix.org> medium of transfer is always the weak point for air-gapped systems

<p​lowsof:matrix.org> data transfer* feather has generic file transfer via qr codes now, perhaps this could be included in an update

<r​ecanman:kernal.eu> NFC can authenticate which distinguishes it

well in this use cae it is not that much about air gaped, more about to overcome some connectivity issues. And yes I think exactly this UR codes feather is using could be adapted to have decent fall back

"NFC can authenticate which distinguishes it" <- what do you mean by that?

<r​ecanman:kernal.eu> Key exchange is possible with NFC for the transfer of data vs QR codes which are in plaintext

<p​lowsof:matrix.org> merchant and you could exchange pgp pub keys :P

what would make this on QR impossible? a ed25519 pub key fits easy into a QR

or you mean that it seems more natural because communication in to directions without manual labour?

can you fit a whole signed tx in a QR code or do you imagine the backup to require connectivity?

"can you fit a whole signed tx in a QR code or do you imagine the backup to require connectivity?" <- no, will not fit, but UR (animated QR codes) are good enough that I would do it each transaction if I could life xmr only...

<o​frnxmr:monero.social> Docs content is mit

and sound is also a very intresting channel (well it will not work easy in very noise enviroments but) because it will become more natural then back and forth with QR codes, meaning the UX is different, there is also Wifi P2P and bluetooth, I would jst grab whatever channel is available and a merchant should at least support UR, and all the rest would be autodiscovery... depending on the device. While apple restricts your NFC

use, it can't restrict you to use audio as channel, and so on.

<c​t:xmr.mx> Are you guys wiretapping me? 😄 Pretty much as the same time as you I was talking about how FCMP makes offline signed NFC payments possible, and that'll only be a matter of time till somebody makes it.

<r​ecanman:kernal.eu> vthor there is a coordinated key exchange that occurs between the card itself and the receiver

<r​ecanman:kernal.eu> en.wikipedia.org/wiki/Java_Card

<c​t:xmr.mx> Of course the main benefit with this is that no data connection is required. But depending on how much computation is required, the NFC device might not even need a battery but can be powered form the NFC reader directly, enabling a classic credit card form factor

<r​ecanman:kernal.eu> vthor think challenge-response

<r​ecanman:kernal.eu> I don't know enough about NFC but this would be quite useful once FCMP is ready

<c​t:xmr.mx> unfortunately I have to agree with rucknium, there are probably lower hanging fruit we should go for first

<r​ecanman:kernal.eu> Yep. Fully agree

<r​ecanman:kernal.eu> Good to keep it in-mind though for later

<s​yntheticbird:monero.social> remember when we were all so focused on layer two solutions ?

<r​ecanman:kernal.eu> When?

<s​yntheticbird:monero.social> 2 years ago

<s​yntheticbird:monero.social> lot of papers have popped in mrl repo

<s​yntheticbird:monero.social> yes i am a bit exaggerating by saying all were focused

<s​yntheticbird:monero.social> but i remember layer two solutions being brought up regularly on r/monero

<r​ecanman:kernal.eu> Lol, most discussion there is useless

"<r​ecanman:kernal.eu> en.wikipedia.org/wiki/Java_Card" that confuses me - I thought we are speaking about transfer channels for monero tx, it would be from phone to phone or phone to terminal (yes I'm aware you can simulate cards, too - but don't see the sense in it (yet))

<s​yntheticbird:monero.social> i agree yet they are an important part of the monero community if it wasn't one of the most important.

<r​ecanman:kernal.eu> Most NFC cards use Java Card IIRC

"Of course the main benefit with this is that no data connection is required. But depending on how much computation is required, the NFC device might not even need a battery but can be powered form the NFC reader directly, enabling a classic credit card form factor" :o wait, that is another dimension :D

<r​ecanman:kernal.eu> Indeed

<r​ecanman:kernal.eu> Formulating a plan for implementation would need some time, i.e explicitly defining the roles of the card and reader, what they communicate, etc

<c​t:xmr.mx> vthor: that was what I was dreaming about in parallel to your discussion :D

<r​ecanman:kernal.eu> It isn't easy

"Most NFC cards use Java Card IIRC" <- seems I simply wrongly assumed we are talking NFC as a medium/channel to transmit data for the tx

<r​ecanman:kernal.eu> I'm talking about the set of protocols, not the RF behind it

<c​t:xmr.mx> recanman I don't think it is possible with an off the shelf smartcard, but the electronics aren't complicated, only the form factor

<c​t:xmr.mx> And of course, the software supporting all that. So yes, at best its far far out in the future

c​t: ah, well that makes sense, but I think the choice of the algo will make all that hard to impossible (except, I don't know what FCMP changes all what would make that easier, but last thing I have seen, it doesn't get simpler (in my impression)

<r​ecanman:kernal.eu> Yes, custom work is needed. I was meaning to explain what was behind the secure element

<r​ecanman:kernal.eu> wallet3 should provide those functions hopefully

<r​ecanman:kernal.eu> If there is a wallet3... maybe it is turning into something else

<w​oodser:monero.social> monero-ts