libera #monero

11 Aug 2025

[XMR] Be excellent to each other and welcoming to newcomers || getmonero.org || Dev: #monero-dev || Pool related: Rizon.net :: #monero-pools || Price chat: #monero-markets || People can & do log this channel

• 04:58
  m-relay
  <s​bt:nope.chat> How to make methamphetamine?
• 05:00
  m-relay
  <s​bt:nope.chat> Tor is kinda centralized. Way more than it should be. Majority relays are in germany. You can't be a directory authority without identifying yourself which is concerning.
• 05:43
  m-relay
  <o​frnxmr:xmr.mx> thats why i use mullvad
• 06:58
  m-relay
  <e​ddie:oblak.be> same here +/- made half in PPLNS of what I paid
• 07:18
  m-relay
  <l​eonarth_:matrix.org> the other asshole breaks even
• 08:46
  m-relay
  <e​ddie:oblak.be> For P2Pool I can't seem to find numbers on the share difficulty, does anyone know where I can find it?
• 09:21
  sech1
  You can find it by running P2Pool and checking the logs. But the easy way is to multiply hashrate by 10 for p2pool-main/mini, and by 30 for p2pool-nano
• 11:30
  m-relay
  <l​eonarth_:matrix.org> what would happen if large pools start submitting hash into p2pool rather than mining directly?
• 11:30
  m-relay
  <l​eonarth_:matrix.org> would doing this reduce their reward or disadvantage them in any way?
• 13:15
  m-relay
  <n​eromonero1024:monero.social> they will be neither advantaged nor disadvantaged... the payout will always be proportional to their hash rates (especially true for large hash rates)
• 13:20
  m-relay
  <n​eromonero1024:monero.social> the reason a 51% attacker can force orphan blocks is because they can continue building a private chain with bigger cumulative diff, right?
• 13:21
  m-relay
  <n​eromonero1024:monero.social> from what I remember, cumulative difficulty is calculated as the summation of how much difficulty blocks had to overcome
• 13:22
  m-relay
  <n​eromonero1024:monero.social> when it comes to choosing the canonical chain, why not switch to the summation of individual blocks' difficulty?
• 13:22
  m-relay
  <n​eromonero1024:monero.social> for example, current network hash rate is 5
• 13:23
  m-relay
  <n​eromonero1024:monero.social> *5.5 GH/s, so blocks will have to overcome 5.5G * 120 difficulty
• 13:24
  m-relay
  <n​eromonero1024:monero.social> however, each block can actually have difficulty quality of much higher
• 13:35
  m-relay
  <n​eromonero1024:monero.social> basically, the canonical chain would be: chain with highest cumulative difficulty + lowest sum of PoW hashes
• 14:31
  m-relay
  <l​eonarth_:matrix.org> for a 51% attack, one must have the cumulative hashrate divided by 1.9
• 14:31
  m-relay
  <l​eonarth_:matrix.org> it's not easy because your hashrate also grows the total hashrate
• 14:33
  m-relay
  <n​eromonero1024:monero.social> not really
• 14:33
  m-relay
  <n​eromonero1024:monero.social> the 51% attacker can build a private chian, and only expose 1-2 blocks at a time to drop blocks from other miners
• 14:33
  m-relay
  <n​eromonero1024:monero.social> thus, he can do it without increasing the difficulty
• 14:34
  m-relay
  <l​eonarth_:matrix.org> if now the HR is 5GH/s, to get to 2.6GH you're adding to the 5 and so it scales becoming 7.6GH/s of which you need 4GH/s to attack so forth
• 14:35
  m-relay
  <l​eonarth_:matrix.org> you're right, b/c they can selfish-mine and hide the blocks
• 14:37
  m-relay
  <l​eonarth_:matrix.org> maybe a solution could be having a p2pool-style share-chain directly in the consensus protocol
• 14:38
  m-relay
  <n​eromonero1024:monero.social> fyi, you can also 51% p2pool
• 14:38
  m-relay
  <n​eromonero1024:monero.social> think of p2pool as just another monero chain but with shorter block time
• 14:38
  m-relay
  <l​eonarth_:matrix.org> you cannot hide blocks from p2pool
• 14:42
  m-relay
  <l​eonarth_:matrix.org> controlling the p2pool sharechain is irrelevant for an attack
• 14:44
  m-relay
  <n​eromonero1024:monero.social> you find a share, publish it to the network
• 14:44
  m-relay
  <n​eromonero1024:monero.social> build a private chain of shares
• 14:44
  m-relay
  <n​eromonero1024:monero.social> every time someone else finds a share, publish your own... you either get uncle'd or uncle other miners' shares
• 14:44
  m-relay
  <n​eromonero1024:monero.social> hmm... so it depends on how uncle is decided
• 14:44
  m-relay
  <n​eromonero1024:monero.social> I totally forgot how uncle is decided... whether it's "first come, first served" or whichever share is better quality
• 15:01
  m-relay
  <l​eonarth_:matrix.org> even if you uncle other miners and get most of the reward, you still cannot attack the main chain and orphan blocks
• 15:01
  m-relay
  <l​eonarth_:matrix.org> alright, you've 51%'ed the p2pool and getting most of the rewards but that's it, right?
• 15:02
  Cindy
  so basically p2pool is free from the same disadvantages 51% attacks have?
• 15:03
  Cindy
  why not just force all mining to be from p2pool?
• 15:03
  Cindy
  via consenus
• 15:05
  m-relay
  <l​eonarth_:matrix.org> .
• 15:11
  Cindy
  oh wait i forgot you suggested that
• 15:11
  Cindy
  i didn't scroll up sorry (my terminal is small)
• 15:31
  m-relay
  <l​eonarth_:matrix.org> with 100kh/s better to be on p2pool-main or mini?
• 15:32
  Cindy
  you can investigate on your own
• 15:33
  m-relay
  <x​3cc:nope.chat> Mini, after 200-300 you can try main
• 15:33
  m-relay
  <x​3cc:nope.chat> Have a look at miners hashrate on mini and main
• 15:33
  m-relay
  <x​3cc:nope.chat> /miners
• 15:34
  Cindy
  but i think the main chain is filled with megahash miners
• 15:35
  m-relay
  <x​3cc:nope.chat> Actually lowest miner in PPLNS window on main is 500 khs
• 15:35
  Cindy
  100Kh/s is actually pretty decent for mini
• 15:35
  m-relay
  <x​3cc:nope.chat> Just checked
• 15:35
  Cindy
  like the top 20% or something
• 15:35
  m-relay
  <x​3cc:nope.chat> Yea
• 15:35
  m-relay
  <l​eonarth_:matrix.org> yeah, I'd be top 20 on mini
• 15:36
  m-relay
  <x​3cc:nope.chat> Leonardo: do you have miner alias?
• 15:36
  m-relay
  <l​eonarth_:matrix.org> jeez, there's people with 40MH on main
• 15:37
  m-relay
  <a​lexandre:uii.pt> what would be the recomended for nano?
• 15:39
  m-relay
  <l​eonarth_:matrix.org> guess anything under 100kh should go to nano?
• 15:39
  m-relay
  <l​eonarth_:matrix.org> does the difficulty setting in xmrig matter when using p2pool?
• 15:41
  m-relay
  <n​eromonero1024:monero.social> not really, no
• 15:41
  m-relay
  <x​3cc:nope.chat> There is miners in nano with 1khs
• 15:41
  m-relay
  <n​eromonero1024:monero.social> p2pool uses xmrig difficulty to keep track of the hash rate of individual workers
• 15:41
  m-relay
  <n​eromonero1024:monero.social> that's it
• 15:41
  m-relay
  <x​3cc:nope.chat> p2pool will automatically adjust diff for xmrig
• 15:43
  m-relay
  <x​3cc:nope.chat> Yep
• 15:43
  m-relay
  <a​lexandre:uii.pt> gupax makes 50KH/s the threshold for main and mini
• 15:43
  m-relay
  <a​lexandre:uii.pt> but i guess there's no downside in having a huge hashrate in nano?
• 15:44
  m-relay
  <l​eonarth_:matrix.org> well, there is, you're submitting too many shares, too quickly
• 15:45
  m-relay
  <l​eonarth_:matrix.org> therefore gupax sends miners over 50kh/s to main?
• 15:46
  m-relay
  <n​eromonero1024:monero.social> nano is too small... it should benefit from a couple of MH/s
• 15:46
  m-relay
  <n​eromonero1024:monero.social> it will not shrink the pplns window size much while increasing the block hits
• 15:48
  m-relay
  <a​lexandre:uii.pt> you can still manually select, but has that recomendation yeah
• 15:49
  m-relay
  <l​eonarth_:matrix.org> then with 100kh/s I should go to main
• 15:57
  Cindy_
  nano does not find blocks as often
• 15:57
  Cindy_
  you can find a lot of shares, but you're not getting paid until it actually finds a block
• 15:59
  m-relay
  <e​ddie:oblak.be> but when nano finds a block, you get a bigger reward because it's shared among less miners?
• 16:37
  m-relay
  <e​ddie:oblak.be> Can someone remind me where to find the spy node ban list for monerod?
• 16:42
  rbrunner
  Not 100% sure, but I think this is it: github.com/Boog900/monero-ban-list
• 16:45
  jush
  how does one determine whats a spy node or not
• 16:45
  m-relay
  <e​ddie:oblak.be> ok, I still wonder how effective this is, who ever is running these spy nodes, haven't they cycled all these IP's yet?
• 16:45
  rbrunner
  Somewhat surprisingly, not.
• 16:45
  m-relay
  <e​ddie:oblak.be> thank btw :)
• 16:45
  m-relay
  <e​ddie:oblak.be> thanks btw :)
• 16:46
  rbrunner
  jush: They answer in a special way to some query over the p2p network, from that you see they are not really nodes, but just proxies that posit as nodes.
• 16:47
  rbrunner
  Running so many full nodes would probably be prohibitively expensive
• 16:47
  rbrunner
  And not really necessary
• 16:50
  jush
  i see
• 16:51
  m-relay
  <b​oog900:monero.social> jush: github.com/Boog900/p2p-proxy-checker
• 16:54
  Cindy_
  what stops a proxy node to change the peer_id
• 16:54
  Cindy_
  on every response
• 16:55
  m-relay
  <b​oog900:monero.social> Nothing
• 17:25
  m-relay
  <l​eonarth_:matrix.org> they basically take your request and forward it to a real node meanwhile parse and store your traffic
• 17:47
  m-relay
  <e​ddie:oblak.be> is this down just for me or in general? -> monerodocs.org/interacting/monerod-reference .. I am looking for a man-page for the monerod config file
• 17:50
  m-relay
  <e​ddie:oblak.be> Oh nevermind I found it at docs.getmonero.org
• 17:50
  m-relay
  <e​ddie:oblak.be> Maybe the links here (getmonero.org/resources/moneropedia/daemon.html ) should be updated
• 17:51
  m-relay
  <e​ddie:oblak.be> also here: getmonero.org/resources/developer-guides a link to docs.getmonero.org would come in handy 😁
• 17:52
  m-relay
  <e​ddie:oblak.be> I see you can get there via RPC docs, but it wasn't clear to me because I wasn't looking for rpc information..
• 21:07
  m-relay
  <m​atrixuser2175:matrix.org> best currency to exchange for XMR? BTC fees are way too high for regular purchases
• 21:12
  m-relay
  <s​yntheticbird:monero.social> LTC
• 21:17
  m-relay
  <e​ddie:oblak.be> Last time I did it with DAI so I don't have to worry about the non-xmr volatility
• 21:44
  m-relay
  <f​iatmoneysucks:matrix.org> What characteristics do you think the perfect mining pool would have?
• 21:44
  m-relay
  <f​iatmoneysucks:matrix.org> reddit.com/r/Monero/comments/1mmfdd…ld_design_the_perfect_monero_mining
• 21:45
  Cindy_
  blackjack
• 21:46
  Cindy_
  but seriously, i don't get this question :P
• 21:46
  Cindy_
  we already have the perfect mining pool, it's called p2pool
• 21:48
  Cindy_
  sorry
• 21:57
  m-relay
  <e​ddie:oblak.be> the perfect pool pays you money without mining 😂
• 22:32
  m-relay
  <f​iatmoneysucks:matrix.org> In other words, a pool that would help Monero mining while benefiting the miners who use it.
• 22:32
  m-relay
  <f​iatmoneysucks:matrix.org> P2Pool is good, but what could be improved in your opinion?
• 22:32
  m-relay
  <f​iatmoneysucks:matrix.org> In other words, a pool that would help Monero decentralization of mining while benefiting the miners who use it.
• 22:32
  m-relay
  <f​iatmoneysucks:matrix.org> P2Pool is good, but what could be improved in your opinion?
• 22:36
  Cindy_
  a centralized pool already hurts monero's decentralization of mining
• 22:39
  m-relay
  <e​ddie:oblak.be> P2Pool is "hard" for newbies to setup. Afaik you need to run the P2Pool binary, a node, and xmrig, which makes it relatively complex for a non-technical person to join in the fun.
• 22:41
  nioc
  AIUI you don't need a monero node
• 22:41
  Cindy_
  yeah you don't need one
• 22:41
  ruidx
  I was saying it's hard too until I just tried ...
• 22:42
  Cindy_
  gupax is an attempt to make it easier
• 22:42
  m-relay
  <e​ddie:oblak.be> ok, misunderstanding then
• 22:42
  Cindy_
  there is no pool that will "help monero's decentralization"
• 22:42
  m-relay
  <e​ddie:oblak.be> But you need a node that has zmq enabled, no?
• 22:42
  Cindy_
  hosting a pool goes against decentralization of mining
• 22:42
  ruidx
  also I suggested earlier we should add p2pool info on xmrig wizard, newbies use it to configure their mining machines first, there is nothing about p2pool
• 22:42
  nioc
  well you need to use a node but you can do so without using your own
• 22:42
  Cindy_
  eddie: plenty of remote nodes have ZMQ enabled
• 22:43
  m-relay
  <e​ddie:oblak.be> Allright, didn't know that. I have never used someone elses node ..
• 22:44
  nioc
  me neither :)
• 22:44
  Cindy_
  i have used someone else's node
• 22:44
  Cindy_
  but only through tor
• 22:44
  Cindy_
  as you SHOULD
• 22:44
  Cindy_
  there was some talk about some monero wallet programs sharing your wallet's view key to "simplify" viewing transactions
• 22:44
  m-relay
  <e​ddie:oblak.be> Btw, Cindy I agree pools are against decentralization, but the reality is that individual miners with low hashrate do want to work together for at least some payout
• 22:44
  Cindy_
  is this a FUD or...?
• 22:45
  Cindy_
  is this an actual feature in the official one too?
• 22:45
  Cindy_
  eddie: that's why p2pool is split between main, mini, and nano
• 22:46
  m-relay
  <e​ddie:oblak.be> Yes and that's good, but I don't know if it would be practical to *only* have p2pool (even though it's really nice)
• 22:46
  m-relay
  <e​ddie:oblak.be> because if monero mining is so unprofitable nobody wants to mine it, then there's no network ..
• 22:47
  Cindy_
  i mined in a centralized pool for a bit
• 22:48
  Cindy_
  and the payout was about the same as if i mined in p2pool
• 22:48
  m-relay
  <e​ddie:oblak.be> It is not good if miners all flock to one big pool like minexmr and supportxmr, but you still need some economic incentive for miners to mine.
• 22:48
  Cindy_
  or even lower
• 22:48
  Cindy_
  if NOBODY actually mines, then there'll be more rewards for those who mine
• 22:49
  m-relay
  <e​ddie:oblak.be> yes but then it's also easier for a big solo miner to take over the network
• 22:50
  m-relay
  <e​ddie:oblak.be> Maybe you are right and P2Pool only is the way to go, apart from pure solo mining
• 22:50
  Cindy_
  but i don't know what's your point in this
• 22:50
  Cindy_
  p2pool does have good rewards, even for low hashrates
• 22:50
  Cindy_
  i've seen as much in centralized pools
• 22:51
  m-relay
  <e​ddie:oblak.be> That I think there should be an effort made to increase the volume of miners and increase of total hashrate, so that it becomes more expensive for 1 party to buy the network
• 22:52
  m-relay
  <e​ddie:oblak.be> I don't know if there's a technical solution for that
• 22:52
  Cindy_
  volume of miners do not matter when there's a better chance of collusion
• 22:52
  Cindy_
  centralized pools makes it easier to collude
• 22:53
  m-relay
  <e​ddie:oblak.be> Sure the miners should be distributed right, preferably no single group has more than 5-10 % of the network
• 22:57
  m-relay
  <e​ddie:oblak.be> Anyway, my answer to the 3.14stache account is that it could be made even more simple for newbies to start mining on p2pool, so it's a question of UX I guess
• 22:57
  m-relay
  <e​ddie:oblak.be> Gupaxx is a really great effort in that sense
• 23:33
  m-relay
  <j​ack_ma_blabla:matrix.org> (no of txs: 463, size: 1205.14 kB, updated every 5 seconds)
• 23:34
  Cindy_
  not updated every 5 seconds
• 23:34
  Cindy_
  which is a good thing, you'd be flooding the IRC chanel
• 23:34
  Cindy_
  channel
• 23:44
  m-relay
  <j​ack_ma_blabla:matrix.org> atleast i dont spam garbage like you
• 23:45
  m-relay
  <j​ack_ma_blabla:matrix.org> There are txs pending conf for last 30min+
• 23:45
  m-relay
  <j​ack_ma_blabla:matrix.org> this is not "normal" for xmr
• 23:46
  Cindy_
  sorry i talk too much :P
• 23:54
  Cindy_
  jack_ma_blabla: what are the pending txs' fees?
• 23:55
  Cindy_
  it might be normal if they paid a really low fee