-
xmr-pr
abyssal0 opened issue #6719: Illegal instruction
-
xmr-pr
-
Steven_M
How does DeepOnion's privacy features compare to Monero's privacy features, are they inferior, equal to, or superior to Monero?
-
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.
-
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.
-
» moneromooo crap at web stuff
-
dsc_
I can do that but I'm not sure if I can use those hours on my GUI CCS
-
sarang
Sounds like a good way to get a list of addresses...
-
moneromooo
Good point. Enforce subaddress then.
-
asymptotically
use a unique subaddress when signing up for this donation service or feel the wrath of sarang!
-
dsc_
hosted under .getmonero.org domain would be nice
-
dsc_
any word on hosting?
-
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.
-
dsc_
well I'm interested seeing as I code web apps faster than my shadow
-
moneromooo
Nice. Feel free to ask if you have questions about primo, I know it fairly well.
-
lza_menace
I'm down to help....web stuff is all I'm "good" at :)
-
dsc_
Going in blind here; how do I generate a primo config?
-
dsc_
do you have an example?
-
dsc_
As for domain, I can use `donate.xmr.pm`
-
» moneromooo goes look
-
dsc_
Registration: username/password + captcha would suffice
-
dsc_
And no, not Google Captcha :P
-
asymptotically
dsc_: what about monero PoW instead of a captcha? :D
-
moneromooo
There is a config example for apache in the README there.
-
moneromooo
(there are 4 READMEs btw, a top one, and one for each of apache, firefox and control center)
-
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
-
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
-
dsc_
oh
-
moneromooo
Ah, yes. It uses the "account" system monerod has.
-
dsc_
what asymptotically said makes sense
-
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.
-
dsc_
Ah okay, so I myself would run Apache with primo, my own monerod+rpc, and pay out to user's addresses
-
moneromooo
Yes.
-
moneromooo
Maybe primo could be changed to allow different addresses for different pages. I don't think it can do that atm.
-
dsc_
Nice concept.
-
sarang
Weekly meeting in #monero-research-lab begins at 17:00 UTC (about 20 minutes from now)
-
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
-
dsc_
address"
-
dsc_
s/incoming payments/incoming hashrate/
-
moneromooo
IIRC you "tag" with a custom string, used for which RPC call is used. I'll go look.
-
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.
-
moneromooo
Then your payout process uses access_data and pays out whoever got a balance increase and was not paid yet.
-
moneromooo
It's a bit more involved than it'd ideally be I guess.
-
moneromooo
Looks like you'd need to add code to the apache server to call access_data with the beneficiary account id.
-
moneromooo
The apache primo plugin.
-
moneromooo
(when the client finds a block)
-
moneromooo
Alternatively, you can make it so you pay out on shares received, and keep the blocks.
-
moneromooo
This way beneficiaries get a steady small income rather than the lottery thing.
-
moneromooo
(and you eat the randomness instead)
-
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?
-
dsc_
s/subaddr index/account index/
-
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.
-
moneromooo
Oh, there's simpler actually:
-
moneromooo
Currently, without changes, a user will mine and increase their balance.
-
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.
-
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.
-
moneromooo
No need to use paying_for or access_data.
-
moneromooo
And it decreases beneficiaries' exposure to variance.
-
moneromooo
Kinda like a pool really.
-
dsc_
Yeah.
-
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.
-
moneromooo
ie, restart primo currently.
-
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
-
sgp_
-
dEBRUYNE
Probably better for -gui? :P
-
asymptotically
i have an apparmor profile for monerod, i can pr it to the utils folder soon(TM)? :)
-
moneromooo
Sure, thanks (contrib is the better place).
-
moneromooo
Someone actually asked for that recently on github.
-
moneroist
if CLSAG implementation is compatible with eventual future DLSAG?
-
sarang
It could be, but dlsag has a tracing issue
-
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?
-
sarang
Basically yes