02:00:38 -xmr-pr- abyssal0 opened issue #6719: Illegal instruction
02:00:38 -xmr-pr- > https://github.com/monero-project/monero/issues/6719
03:22:10 <Steven_M> How does DeepOnion's privacy features compare to Monero's privacy features, are they inferior, equal to, or superior to Monero?
16:05:18 <moneromooo> Anyone around who wants to contribute but whose skills are web stuff rather than C++ ? A site where people can register an address, and which use primo to let others mine for them. Like a "donate to that person with your CPU time" site.
16:06:39 <moneromooo> Primo does all the monero side stuff for you. You just have to maintain a db of users with their address, have a page per user with the primo config set for that user's address.
16:07:28 * moneromooo crap at web stuff
16:07:51 <dsc_> I can do that but I'm not sure if I can use those hours on my GUI CCS
16:07:53 <sarang> Sounds like a good way to get a list of addresses...
16:08:38 <moneromooo> Good point. Enforce subaddress then.
16:08:43 <asymptotically> use a unique subaddress when signing up for this donation service or feel the wrath of sarang!
16:09:51 <dsc_> hosted under .getmonero.org domain would be nice
16:09:56 <dsc_> any word on hosting?
16:10:46 <moneromooo> I dunno, I view this as something no from monero, it just uses monero. But if pony wants to host it, why not I guess.
16:11:54 <dsc_> well I'm interested seeing as I code web apps faster than my shadow
16:13:16 <moneromooo> Nice. Feel free to ask if you have questions about primo, I know it fairly well.
16:19:54 <lza_menace> I'm down to help....web stuff is all I'm "good" at :)
16:19:56 <dsc_> Going in blind here; how do I generate a primo config?
16:20:32 <dsc_> do you have an example?
16:20:58 <dsc_> As for domain, I can use `donate.xmr.pm`
16:21:25 * moneromooo goes look
16:22:00 <dsc_> Registration: username/password + captcha would suffice
16:22:06 <dsc_> And no, not Google Captcha :P
16:23:13 <asymptotically> dsc_: what about monero PoW instead of a captcha? :D
16:23:18 <moneromooo> There is a config example for apache in the README there.
16:27:02 <moneromooo> (there are 4 READMEs btw, a top one, and one for each of apache, firefox and control center)
16:27:14 <dsc_> moneromooo: This webapp would generate apache configs? I'm not seeing an address in there, the Apache module dynamically retreives it from RPC it seems
16:27:55 <asymptotically> dsc_: i think make a page for each user with the primo header that tells it to start mining to that user's address
16:28:08 <dsc_> oh
16:28:10 <moneromooo> Ah, yes. It uses the "account" system monerod has.
16:28:48 <dsc_> what asymptotically said makes sense
16:28:49 <moneromooo> So you can't have multiple addresses, you'd need to pay the user when a block is found. And probably keep a fee.
16:35:01 <dsc_> Ah okay, so I myself would run Apache with primo, my own monerod+rpc, and pay out to user's addresses
16:36:02 <moneromooo> Yes.
16:36:38 <moneromooo> Maybe primo could be changed to allow different addresses for different pages. I don't think it can do that atm.
16:37:17 <dsc_> Nice concept.
16:37:36 <sarang> Weekly meeting in #monero-research-lab begins at 17:00 UTC (about 20 minutes from now)
16:49:26 <dsc_> moneromooo: uncertain how to identify/distinguish incoming payments on the primo/monerod side of things so you know what "user & address" it was for (which is in a seperate database) - I also don't see Primo using Monero accounts - it's seems to be doing 3 unique RPC commands: `rpc_access_pay`, `rpc_access_submit_nonce`, `rpc_access_info`. I'm not sure how that translates to "user has mined for a certain
16:49:32 <dsc_> address"
16:50:20 <dsc_> s/incoming payments/incoming hashrate/
16:53:51 <moneromooo> IIRC you "tag" with a custom string, used for which RPC call is used. I'll go look.
16:56:07 <moneromooo> Right, there is a "access_pay" RPC. You can give it a "paying_for" arg. So you'd call this with that param set to the account id of whoever the user was mining for.
16:56:39 <moneromooo> Then your payout process uses access_data and pays out whoever got a balance increase and was not paid yet.
16:57:02 <moneromooo> It's a bit more involved than it'd ideally be I guess.
16:57:47 <moneromooo> Looks like you'd need to add code to the apache server to call access_data with the beneficiary account id.
16:57:58 <moneromooo> The apache primo plugin.
16:58:11 <moneromooo> (when the client finds a block)
16:58:50 <moneromooo> Alternatively, you can make it so you pay out on shares received, and keep the blocks.
16:59:11 <moneromooo> This way beneficiaries get a steady small income rather than the lottery thing.
16:59:32 <moneromooo> (and you eat the randomness instead)
17:01:53 <dsc_> If I understand correctly, if I submit the right `paying_for` (subaddr index?) then during my payout process I can call `access_data` from an external script/program (so I don't have to modify the primo module) that just checks if anything new happened yet on that account?
17:02:06 <dsc_> s/subaddr index/account index/
17:03:13 <moneromooo> Yes. paying_for will likely be an account id, and you keep a mapping of account id to the user's address in your db.
17:03:53 <moneromooo> Oh, there's simpler actually:
17:04:29 <moneromooo> Currently, without changes, a user will mine and increase their balance.
17:05:15 <moneromooo> So what you can do is, when you receive a block (from whoever), you just increase every beneficiary's balance by the ratio of how many shares have been mined for them.
17:07:02 <moneromooo> So, for example: Alice and Bob register their addresses. Carol mines 200 shares to Alice. Dave mines 500 shares to Bob. Eve tries to mine to Eve but fails. Dave mines another 100 shares, finding a block worth 1 monero. You increase Alice's balance by 1 * 200 / 800, Bob's balance by 1 * 600 / 800.
17:07:25 <moneromooo> No need to use paying_for or access_data.
17:07:45 <moneromooo> And it decreases beneficiaries' exposure to variance.
17:07:53 <moneromooo> Kinda like a pool really.
17:07:57 <dsc_> Yeah.
17:08:46 <moneromooo> Though for this to work, a mining user would have to generate a new key if they want to change who they donate to.
17:09:07 <moneromooo> ie, restart primo currently.
17:14:23 <dsc_> I'm barely following. But I'm good at all the web stuff. Perhaps a mining god would like to cocreate this with me
18:42:06 <sgp_> https://www.reddit.com/r/Monero/comments/hvynq2/what_the_monero_community_could_do_to_improve_the/
18:48:42 <dEBRUYNE> Probably better for -gui? :P
18:51:07 <asymptotically> i have an apparmor profile for monerod, i can pr it to the utils folder soon(TM)? :)
18:53:36 <moneromooo> Sure, thanks (contrib is the better place).
18:53:49 <moneromooo> Someone actually asked for that recently on github.
19:03:09 <moneroist> if CLSAG implementation is compatible with eventual future DLSAG?
19:09:40 <sarang> It could be, but dlsag has a tracing issue
19:25:56 <moneroist> "a recipient of a DLSAG-signed transaction must spend the funds to themselves before using, in order to ensure the original sender cannot detect when the funds are moved." this is that tracing issue? I mean sending all funds to self with one output?
19:45:54 <sarang> Basically yes