03:14:07 Are there any feature ideas for the GUI that are like desired but nobody’s actually done yet? 04:02:36 bevanoff[m], yep. my favorite non existing feature is creating the stuff for RPC-pay 04:20:59 Ohhh okay that’d be cool 04:24:21 That’d be an advanced feature no? Or would you try to incorporate it into the simple mode 04:27:34 well, in a fully functioning rpc-pay environment, i imagine it like this bevanoff[m]. 04:28:05 A new user downloads the GUI and wants to use funds immediately. They start up GUI, use simple mode, and get a bootstrap connection 04:28:33 the bootstrap connection is over rpc, so they would need rpc-pay 04:30:24 because its simple mode, i imagine a status box would exist that says "Working for connection" or something 04:31:36 presumably on the backend the GUI would either pick a random rpc-pay node from the p2p list, or try to find the cheapest one 04:36:15 Ohhh I see, I’m only vaguely familiar with the concept 04:36:23 Any links for documentation? 04:38:29 documentation>!>!>!? this is monero! documentations in the code :) 04:38:46 lemme see if i can find something... 04:41:11 bevanoff[m], https://github.com/monero-project/monero/commit/2899379791b7542e4eb920b5d9d58cf232806937 04:42:14 Thanks! 10:36:19 That list of public nodes via P2P is just full of spies and scammers. It seemed like a good idea at the time, but like so many other things, people happened. 10:36:30 So I'm not sure it's a good idea anymore. 11:01:44 maybe the "mesh of trust" idea could see some revival in XMR node-space 11:03:15 moneromooo: What would you propose as alternative? 11:09:21 Filtering any that's not a hidden service or eepsite. 11:10:09 I have a patch for this but it works only if the daemon is set with --tx-proxy, since otherwise they won't receive tor/i2p peer lists. 12:22:11 i imagine there's gotta be a solution to this 17:06:35 i mean any node can be a spy / scammer, indeed thats why dandelion was implemented. 17:07:35 i think a potential solution is to just use the RPC connection for downloading the wallet refresh data, and then the data for creating the transaction 17:08:13 the wallet then crafts the transaction, and pushes it over the p2p network via a different node. Then it becomes just like a dandelion tx (mebbe) 17:08:51 IIRC mooo said the data for creating a transaction is enough to identify it later in the mempool 17:09:08 but yeah, just restricting to hidden services would do the job too 17:10:31 well we could add noise. so the wallet requests (ABC) from node A, (DEF) from node B, (GHI) from C, etc. 17:11:27 and the tx ends up being created with DJR 17:12:10 well.... would that work? hrm 17:16:02 no, because then if node B sees output G in a transaction, it could know it came from that wallet user 17:16:25 but node B could see output G being used in another transaction from another IP because of ring members 17:17:13 yep, that'll do it. sprinkle some statistics on there, boost ringsize to a bajillion, you got yourself a potential solution. 17:28:29 i guess you might not need the noise, you'd just need to get the ring members information from different nodes 17:28:44 so currently, you would pull info from 11 different nodes 18:57:02 so 11 different nodes would know that tx A that used outputs A1-A11 came from IP A, but presumably there would be another tx B that used outputs B1-B11 and those nodes would know it came from IP B. 18:58:06 and as long as theres some union between A1-A11 and B1-B11, you can't pin a particular wallet IP to a particular tx 19:02:09 maybe? need to run it through the mathimologic confabulator 19:03:40 i mean, or we could just use tor. but the inclusion of dandelion makes me believe that there's a general idea that its better for stuff to be internal if possible 23:10:09 bevanoff[m], another idea would be some kind of pool miner plugin or something for the GUI 23:12:32 Did that not get rejected ? I remember coding this. 23:34:53 why would it have been rejected? something about true decentralization and every user mining a little? 23:42:52 Favouritism IIRC (due to the list of pools). 23:43:04 Might have been other reasons. 23:43:46 And it included a standalone miner, a bit unwieldy. 23:44:14 Then again, it would fit a new GUI program very well. 23:44:29 Does xmrig have a GUI ? 23:47:07 afaik, it does not 23:47:47 the current idea in the mining space is to somehow get mining programs to auto-select a pool, and to switch occasionally 23:48:01 New program ? Same as I did a standalone updater/verifier. Simple UI, pool selection, etc. 23:48:14 the thought being that noobs don't know what they are doing, and just find lists of pools and pick the one on top 23:48:15 Right, that'd be nice. 23:48:25 the one on top tends to be the largest one 23:49:28 I wonder if today's kids would like gamification. "You've hashed 4 million hashes in hte last 24 hours, can you beat this ?" 23:49:44 Share your hash rate on twatter or Faecebook! 23:50:07 i dunno. 23:50:32 "Congrats, you've mined your ten billionth hash!" Here's a worthless medal :D 23:51:28 "You've spent a week on a pool with < 10% of the network hash. You get the STALWART SUPPORTER badge!" 23:52:02 Might work better for a panopticoin like bitcoin I guess. 23:57:49 i think a gui plugin would be great 23:58:08 and mining pools can pay / donate to core team to have their pool included in the GUI 23:58:26 cause anythings better than the current situatio