02:08:54 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? 02:09:16 No 02:09:46 You don’t need internet to do math 02:10:01 Technically you could mine coins in your head 02:10:13 ok just wanting to be sure 02:10:35 I think the 6502 in my brain isn't capable :P 02:11:08 You can always store them in the brain after anyway with brainwallet.io 02:11:15 lmao 02:12:40 would be interesting to see that done in BASIC on a C64. Then, try assembly 02:14:11 well if you start from genesis you could mine some on a gameboy colour 02:14:45 My Amiga has GCC on it as well as python (2.4 I think) 02:18:10 the only thing i can do in assembly is write a sha265 hash step 02:18:55 oh and I can also hack pokemon red and blue 02:18:57 I would have to dig out my C64 assembly books. All I can remember is lda 02:19:36 lda, sta, cmp, bne, jmp, jsr 02:19:43 did you know the C compiler is written in C 02:19:46 basic math 03:27:51 hi. Sneedlewoods overfunding is being allocated in full 03:30:08 luigi1111 what do you mean by allocated in full? Like he's receiving the goal + the extra XMR? 03:30:33 ...as a one-time thing, or as a change for proposals moving forward? 🤔 03:31:04 one time 03:31:22 👍 05:20:16 Thanks, luigi1111 ! 06:24:06 that makes sense to me. 07:38:42 sneedlewoods removed from the overfunded list, please come back soon :( https://github.com/plowsof/scrape_ccs_fr/compare/main...refunded 07:43:11 <3​21bob321:monero.social> precedent has been set 07:44:14 What does this mean for sneedlewood 07:44:37 <3​21bob321:monero.social> Gets all the moneros 07:45:10 Good 07:45:11 <3​21bob321:monero.social> Ima just gonna wait for all the others to put there hands up 07:45:43 <3​21bob321:monero.social> Like fcmp created a dev price hike 07:45:46 I think it was his modesty that earned him that 07:46:13 Or her 07:59:46 so kewbits update was 4 days ago , for milestone 2, the api https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/489#note_26721 08:00:36 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) 08:01:07 monerobull raised the first question about source of the test app 08:01:23 It’s shared 08:01:25 WTF 08:01:50 whats shared and whats not shared for milestone 1 (please clarify) 08:02:20 Oh semantics 08:02:23 Is it? 08:02:50 No it’s not milestone 1 because I didn’t number the milestones 08:03:40 ok ignore the order (milestones have been claimed out of order before) 08:04:23 It ended up completely fishing the protocol first basically yeah 08:04:42 Finishing* 08:05:04 https://github.com/KewbitXMR/flutter_haveno 08:05:17 and its published in full with docuemtnation and AGPLv3 licencing 08:05:39 I did want to go for a monorepo,but that would be less benfit to the community 08:06:25 Seperation of concerns makes more sense, this is a ususable component tht other dexs can choose to integrate 08:06:27 Seperation of concerns makes more sense, this is a reususable component tht other dexs can choose to integrate 08:06:32 Seperation of concerns makes more sense, this is a reususable component that other dexs/apps can choose to integrate 08:06:36 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 08:08:17 <3​21bob321:monero.social> Ccs compliance manager too 08:08:39 maybe i'm just not following the concern her 08:08:42 maybe i'm just not following the concern here 08:10:09 can someone explain in simple terms please 08:10:31 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 08:11:04 seems that you have clarified it 08:11:31 I've offered builds so many times then monerobull shouts at me 08:11:49 it's not fully working 08:12:09 it's on my machine im not push my entire project to github I dont eveno know if this is legit yet 08:12:48 I've pushed a milstone which is basiclly the keystone of the project anyway 08:12:50 <3​21bob321:monero.social> Legit means works? 08:13:04 even with that interface people can start making apps really easily for haveno 08:13:12 <3​21bob321:monero.social> Too legit to quit 08:13:44 i have builds that mostly work yeah but I slowed down on the work for the last 2 weeks 08:15:03 woodser: you've done the most amount of testing 08:15:08 probalbly 08:15:24 i think on every OS 08:15:33 apart from ios 08:17:25 to be frank 08:18:01 the moment I see at least 5 conformations, all of the UI is going up so I can request the next milestone immediately lol 08:24:48 i guess the first leap of faith is hard?, imagine taking a four month leap of faith :D 08:25:17 near abouts, lost track 10:06:30 Thank you so much luigi1111, everyone who voiced their opinion in favor of me, and the very generous donors of course. 10:06:31 It's stunning to see all the support ❤️ 10:14:36 congrats, you deserve it 🚀 10:15:10 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 10:15:11 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? 10:21:13 > \> "monerobull against" 10:21:15 > \> \* checks sgp vs ofrnxmr war map \* 10:21:17 > \> checks out 10:50:59 nice, ignored :) 10:51:15 <3​21bob321:monero.social> Against you doing the ccs? 10:51:32 kewbit: do you realise monerobull is was one of the main people pushing for you to be awarded both bounties + the ccs funds? 10:51:57 i dont know where this bloody contention i coming from then 10:52:27 like what's going on here 10:52:34 is there like an actual concern? 10:53:05 im confused why you brought up the convo like that suddenly 10:56:44 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? 10:58:35 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? 10:59:08 Yup 10:59:13 Im excited 10:59:22 if it gets brought up i can point to your clarifications here. not much else to say on the matter 10:59:23 its open source thats great too 10:59:41 licence exactly how you wanted which is another plus 11:00:12 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 11:00:37 so im sure now you can understand why i am so confused with this 11:00:41 Kewbit in my limited experience in this community you must wait at least an entire day to start seeing reactions 11:01:12 Im excited 11:01:28 Im sure others are. But will express themselves in 12 hours or 24 hours 11:02:38 ok lol i will keep that in mind 11:44:18 https://kewde.gitbooks.io/protocol/content/data-storage-network/smsg.html 11:44:40 https://particl.wiki/learn/marketplace/smsg/ 11:45:24 easy 11:46:23 there might have to be a token for it not to fail though 11:46:52 it has to cost something to spam 11:47:22 maybe each message you send the block gets harder within a certain peroid 11:49:38 decentralized market 11:49:53 now you're looking for trouble 11:49:59 hehe 11:50:01 openbaazzar didnt last long 12:30:47 That is basicswapdex (smsg) 12:36:09 Yeah market is a bit risky for u though 12:36:40 Howso 12:36:53 Deathwish 12:37:27 Elaborate 12:37:29 You think you’ll be that one guy who gets away with it? They all do 😂 12:37:50 ? 12:38:14 In english 12:38:23 Everyone who’s tried making any kind of market place has ended up dead or in prison 12:38:45 💀 12:38:47 You’ve specifically documented a marketplace 12:39:12 To buy and sell goods in a decentralised fashion 12:39:18 lol 12:39:23 In that case, yes i think i'll get away with it 12:40:14 More accurately, idgaf what feds think 12:40:16 @hinto:monero.social hey, what do you think about using (or moving) [your guide](https://github.com/hinto-janai/malvarma) on docs.getmonero.org? 12:40:17 🤟🏿 12:40:19 Nice 12:43:22 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. 15:13:12 https://imgur.com/a/R4ytQ9b 15:13:17 would this work? 15:25:14 `"Imgur is temporarily over capacity. Please try again later."` 15:25:19 ig it would work 15:44:40 try this https://twitter.com/Monero_TV/status/1847281176513245403 15:44:57 https://xcancel.com/Monero_TV/status/1847281176513245403 15:59:47 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 15:59:48 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. 15:59:50 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: https://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 15:59:51 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. 16:00:39 I try later to update the CCS (I procastinated a lot on that, how I'm always between not focused and overwhelmed and hyperfocused. 16:00:58 💪 16:02:47 :D thank you plowsof, you are always there to cheer one up! :) 16:09:52 could something be done in Carrot to simplify this? cold signing via NFC would be the ideal point of sale solution 16:10:47 got my upvote btw 16:19:41 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 16:19:42 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 16:19:44 use case for it) - but both would have no nfc, but still could transact via UR code, and the watch probably through sound... 16:29:37 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 16:29:39 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 16:29:40 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? 16:30:41 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 16:36:19 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 16:36:21 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?). 16:40:45 <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 16:40:47 <1​0934dfasl:matrix.org> e-existing codebase but in a really simple way? 16:41:28 <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 16:41:29 <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? 16:56:04 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. 16:56:26 links: https://www.youtube.com/watch?v=Cu2dk78165Y 16:56:27 https://odysee.com/@anti_moonboy:7/AotPO5:7 16:56:29 https://rumble.com/v5j6cod-aotpo-episode-5-using-a-cospend-attack-to-target-an-individual-collecting-d.html 17:05:32 xenu ya cállate, baboso. 17:07:01 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 17:10:13 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 17:12:31 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. 17:19:04 Moneronodo is to include moneropay 17:20:55 "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 17:20:56 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 17:20:58 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 17:20:59 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. 17:29:21 yeah if it helps you as a proof of concept. just saying that mobile wallets generally don’t receive community support whereas libraries do. 17:46:15 jeffro256: do u think Carrot can simplify building these types of offline transactions to be broadcast by the merchant? 18:09:18 Not Carrot itself, but FCMP++ will allow for offline signing 18:10:44 Sounds like monerujo's pocketchange 18:10:46 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 18:12:32 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 18:12:45 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. 18:16:16 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. 18:16:26 https://matrix.monero.social/_matrix/media/v1/download/kernal.eu/uTLvNpVHubVJMbwlHrWxIqYB 18:25:57 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 18:27:55 "Sounds like monerujo's pocketchange" <- interesting. will look into. 18:29:48 "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? 18:29:55 Be warned though: monerujo's pocketchange input selection algorithm is pretty terrible for privacy last time I checked 18:30:29 "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? 18:33:23 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 18:33:25 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 18:33:31 Long story short, bad for privacy 18:34:02 "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.... 18:35:31 "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? 18:36:48 If I get it right that is even information monerod has, ad not even the wallet would be necessary, or I am wrong? 18:39:09 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 18:39:11 "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 18:39:48 It would be harder to fake the FCMP++ tree root, as it is contained in the block blob 18:40:15 next reorg? 18:40:24 "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... 18:43:44 "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 18:43:45 not be shuffled with the unspent fractions). 18:48:54 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 18:48:56 $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. 18:51:03 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) 18:51:57 thanks jeffro256 18:52:21 a​nhdres: "Sounds like monerujo's pocketchange" <- still still sound similar? 18:52:47 yeah, thanks jeffro256 :) 18:54:38 anhdres: remember we spoke about an NFC PoS protocol back at MoneroKon ‘23 19:24:17 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. 19:41:30 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 19:41:32 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 19:41:33 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 19:41:35 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 19:41:36 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. 19:41:57 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. 19:42:31 Back in the day where we still had NFC support in Monerujo. Nobody used it! But I guess it could be brought back. 19:45:34 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. 19:47:30 It was on old versions, I don't remember now why we discontinued it 19:48:00 We thought NFC was cool, but nobody complained when we took it away 19:48:41 You could both read and write NFC tags with it if I don't remember wrong 19:56:54 Thank you anhdres for you answers :) I will look into it again. 20:10:08 Here's a quick read: https://anhdres.medium.com/monerujos-pocketchange-what-it-is-and-how-it-works-8e1ea1f7489e 20:10:37 It was broken 20:11:07 probably old lib stopped working with new versions or something, but it was broken 20:11:18 recanman 20:11:31 Nfc to transfer payment requests is clutch 20:13:34 what means "is clutch"? 20:16:52 Comes in handy 20:19:40 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. 20:27:49 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. 20:28:28 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 20:31:46 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 20:32:11 Yeah, it wasn't at first, but when it did, I wasn't worth to fix it. Did you use it? 20:32:15 It doesn't work with traditional RingCT because of how transactions are signed, I'm sure jeffro could explain this better than I can 20:32:37 no I’m on iOS ): 20:32:37 To sign transactions partially and then transmit them with a centralized server 20:32:46 I tried and failed 20:33:04 Based on my understanding, the new model should help with that. Someone should create a CCS to create some integration/develop a protocol 20:33:41 Well of you ping m2049r: enough he may even bring it back 20:33:48 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 20:34:39 Does anything like that exist? 20:34:51 Android app would work 20:35:00 I'm waiting for --proxy support 20:35:06 yeah, some other crypto projects put their own aps on it (it is indeed an android~ thing) 20:35:18 Yea 20:35:21 i forget the name.. 20:35:28 Hotshop almost added nfc 20:35:40 Chrome on Android supports nfc 20:35:50 There needs to be standardization of a protocol before 'adding' it? 20:36:04 Yeah there was a POS terminal or 3 for btcpay iirc 20:36:22 its built into chrome 20:36:39 I mean the protocol for Monero and NFC 20:37:01 Its just transmitting a payment request uri 20:37:07 reddit.com/r/teslamotors/comments/drksso/ 20:37:22 Here's an example for tesla car keycards authentication 20:38:00 Oh 20:38:07 Haha, right 20:38:20 HardenedSteel: feel free to take it 20:38:31 I meant for the transmitting of partially-signed transactions 20:38:34 As part of FCMP 20:38:40 As part of FCMP and Seraphis 20:39:01 Is it licensed hinto @hinto:monero.social: ans is it on git? 20:41:56 <3​21bob321:monero.social> just give credit to hinto 20:42:15 <3​21bob321:monero.social> hinto grants ™️ 20:44:21 https://github.com/hinto-janai/malvarma 20:45:11 <3​21bob321:monero.social> careful plowsof its rust 😁 20:47:12 its better to license also the content 20:47:57 not just MIT 20:48:11 recanman searching this will find it "Orange Portable Handheld Android POS System with Bluetooth" 20:49:27 medium of transfer is always the weak point for air-gapped systems 20:50:11 data transfer* feather has generic file transfer via qr codes now, perhaps this could be included in an update 20:50:45 NFC can authenticate which distinguishes it 20:51:30 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 20:52:34 "NFC can authenticate which distinguishes it" <- what do you mean by that? 20:54:43 Key exchange is possible with NFC for the transfer of data vs QR codes which are in plaintext 20:54:58 merchant and you could exchange pgp pub keys :P 20:56:23 what would make this on QR impossible? a ed25519 pub key fits easy into a QR 20:57:12 or you mean that it seems more natural because communication in to directions without manual labour? 21:12:13 can you fit a whole signed tx in a QR code or do you imagine the backup to require connectivity? 21:17:16 "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... 21:21:33 Docs content is mit 21:21:46 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 21:21:47 use, it can't restrict you to use audio as channel, and so on. 22:00:40 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. 22:01:12 vthor there is a coordinated key exchange that occurs between the card itself and the receiver 22:01:24 https://en.wikipedia.org/wiki/Java_Card 22:02:57 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 22:03:13 vthor think challenge-response 22:03:50 I don't know enough about NFC but this would be quite useful once FCMP is ready 22:04:04 unfortunately I have to agree with rucknium, there are probably lower hanging fruit we should go for first 22:04:20 Yep. Fully agree 22:04:28 Good to keep it in-mind though for later 22:05:32 remember when we were all so focused on layer two solutions ? 22:05:51 When? 22:05:58 2 years ago 22:06:08 lot of papers have popped in mrl repo 22:06:33 yes i am a bit exaggerating by saying all were focused 22:06:55 but i remember layer two solutions being brought up regularly on r/monero 22:07:36 Lol, most discussion there is useless 22:07:44 " https://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)) 22:08:16 i agree yet they are an important part of the monero community if it wasn't one of the most important. 22:08:20 Most NFC cards use Java Card IIRC 22:08:58 "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 22:09:11 Indeed 22:10:18 Formulating a plan for implementation would need some time, i.e explicitly defining the roles of the card and reader, what they communicate, etc 22:10:40 vthor: that was what I was dreaming about in parallel to your discussion :D 22:10:41 It isn't easy 22:10:45 "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 22:11:24 I'm talking about the set of protocols, not the RF behind it 22:13:08 recanman I don't think it is possible with an off the shelf smartcard, but the electronics aren't complicated, only the form factor 22:13:09 And of course, the software supporting all that. So yes, at best its far far out in the future 22:13:12 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) 22:13:32 Yes, custom work is needed. I was meaning to explain what was behind the secure element 22:14:08 wallet3 should provide those functions hopefully 22:14:18 If there is a wallet3... maybe it is turning into something else 23:58:06 monero-ts