06:30:48 <kico> Inge-, can you guys add pool.xmr.pt ? :)
06:31:55 <Inge-> I can't. I'm nobody. but sech1 probably can - if you can convince him :P
06:33:35 <niocbrrrrrr> pool.xmr.pt is a long running pool
06:34:42 <Inge-> doesn't change my inability to list it :D
06:34:49 <Inge-> hm. do I have a faulty CPU?
06:34:51 <Inge-> [202348.318001] Bad FPU state detected at __switch_to+0x1b6/0x4e0, reinitializing FPU registers.
06:34:54 <Inge-> [202348.318008] WARNING: CPU: 23 PID: 1848 at /build/linux-UDHJtG/linux-4.15.0/arch/x86/mm/extable.c:104 ex_handler_fprestore+0x65/0x70
06:34:59 <Inge-> or just too low voltage
06:35:44 <niocbrrrrrr> Inge-: I was trying to convince sech1 :)
06:37:01 <kico> sech1, ^ :)
06:39:51 <Inge-> hah niocbrrrrrr
06:43:25 <sech1> I've asked xmrig dev to add it
06:45:37 <niocbrrrrrr> thx
06:59:13 <kico> thank you sir!
07:08:13 <sech1> But https://pool.xmr.pt/#/help/getting_started really needs updating, all miners listed there are obsolete
07:09:29 <Inge-> kico ^
07:09:41 <kico> true
07:09:45 <kico> will do asap
07:09:57 <kico> also been working on new.xmr.pt
07:10:16 <kico> that's why that was forgotten
07:10:22 <kico> but will update later
15:32:11 <tevador> interesting read: https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html
15:32:18 <tevador> randomx mentioned in the second reply
15:33:31 <tevador> if they are OK with using Argon2 then IMO RandomX is a much better choice
15:45:59 <gingeropolous> ermagerd. how do we convince them to couple that effort with actually performing monero work?
15:46:27 <gingeropolous> in effect, tor becomes "merge-mined"
15:47:10 <gingeropolous> users not running their own node can connect with a pool setup
15:47:37 <gingeropolous> "get rewarded in piconero to use tor"
15:50:04 <moneromooo> *To act as a Tor relay.
15:50:12 <moneromooo> Pay to use tor :)
15:50:25 <tevador> why merge mining? onion services could just run their own Monero pools
15:51:07 <gingeropolous> well, its a kind of merge mining. i.e., the onion service PoW can be re-purposed as a monero PoW. They are one and the same.
15:51:27 <moneromooo> If I had the time, I'd extend primo for this. It only does web servers atm, but is meant to be extended to bittorrent peers, tor relays, etc. Though for tor, the issue of knowing who to pay is possibly knotty.
15:52:22 <gingeropolous> i wonder if they came across primo. Is anyone here actually participating in that listserv? well they list a github
15:53:13 <sech1> They won't use RandomX
15:53:37 <sech1> too memory-heavy and slow
15:53:46 <tevador> and Argon2 is different?
15:53:55 <sech1> https://lists.torproject.org/pipermail/tor-dev/2020-April/014225.html
15:54:05 <sech1> "This means that assymetric PoW schemes like Equihash and family is what we
15:54:05 <sech1>  should be looking at next"
15:55:20 <tevador> of course, asymmetric pow is the best for this purpose
15:56:09 <gingeropolous> i dunno. all it does it set themselves up for a brutal attack by a determined and resourceful adversary
15:56:31 <gingeropolous> or even a script kiddie with an asic
15:56:51 <tevador> but if their goal is "hundreds of verifications per second" then even RandomX can reach that
15:56:58 <gingeropolous> its probably worse than not having PoW as ddos protection
15:58:34 <gingeropolous> indeed: "Finally, our proposal has a big benefit over the blockchain use cases: it's
15:58:34 <gingeropolous>    much more agile. We can deploy changes to the PoW algorithm without having
15:58:34 <gingeropolous>    to hard-fork, and we can do this even through the consensus for maximum
15:58:34 <gingeropolous>    agility."
15:59:59 <tevador> GPUs outperform CPUs by several orders of magnitude in Equihash
16:00:55 <tevador> but I guess an onion service that you need a beefy GPU to access is better than nothing
16:03:01 <gingeropolous> mfw asic'd ddos PoW cause asic mining farms to sell their hashpower to whoever wants to attack some tor service
16:03:22 <gingeropolous> because its not like asic farms focus entirely on market dynamics
16:03:24 <gingeropolous>  /s obvi
16:03:56 <gingeropolous> instead of botnets, they'll have asic farms attacking them. brilliant
16:05:17 <tevador> I think they will use some Equihash flavor for which there is no ASIC (yet)
16:05:39 <gingeropolous> the best kind of asic, that is developed produced and used in secret
16:06:39 <gingeropolous> though they can just respond with a software update though with no massive ecosystem change
16:09:27 <sech1> It's not a blockchain, they can design a secure VM and send some random code to execute as PoW
16:09:39 <sech1> not necessarily RandomX, but some useful computations
16:09:50 <sech1> and sell this compute power to researchers
16:10:15 <sech1> like BOINC
16:10:30 <sech1> then ASICs will be irrelevant
16:16:36 <tevador> "useful" computations that have to be verified to make sure they are correct are not very useful
16:17:41 <sech1> there are a lot of computations that can be easily verified but hard to compute
16:17:58 <sech1> basically all BOINC projects
16:23:11 <tevador> it's more complicated than that: https://boinc.berkeley.edu/trac/wiki/ValidationSummary
16:25:50 <sech1> I run a BOINC project, I know all that
16:26:50 <sech1> But since they want "hundreds per second", BOINC tasks as they are now are not suitable
16:28:16 <sech1> some pools were added: https://xmrig.com/wizard
16:28:53 <sech1> alphabetical order as far as I see
16:52:20 <hyc> I'm not seeing how they can choose an equihash config that an ASIC could not be made flexible enough to accomodate
16:52:53 <hyc> so you could mine zcash or attack tor, depending on your customer demands
16:56:36 <hyc> but I suppose an ASIC-only PoW will reduce their botnet exposure
16:57:08 <tevador> it will also reduce their user exposure
16:57:38 <hyc> true
16:58:32 <hyc> really as far as PoW properties go I don't think they can shift their requirements far from ours
16:59:00 <hyc> argon2 alone, in hardware, will still spank any CPUs
17:08:10 <tevador> supportxmr and minexmr still at ~60% *sigh*
19:37:04 <gingeropolous> tevador, pool centralization is gonna require more than unicorns and rainbows to fix imo
19:38:06 <moneromooo> SWAT teams to the pool op homes ?
19:40:24 <jwinterm> doubt they're running hardware at their actual place of residence
19:40:27 <jwinterm> but maybe
19:57:36 <hyc> how about some custom malware to break into the pool itself and start forwarding clients elsehwere
21:26:29 <tevador> all you need is to blackmail/hack two pool operators
21:27:45 <tevador> if stratum self select was widely adopted it would not be such an issue
21:29:32 <sech1> self select has no economic incentive for miners, so it's DoA
21:31:03 <sech1> pools can create the incentive though (smaller fee for self-select), but they don't care either
21:32:20 <tevador> pools can even fight centralization with fees but they don't care
21:34:34 <tevador> it's a classic example of tragedy of the commons, people cause centralization for personal gain even if it hurts the network as a whole