-
m-relay
<lowdegree:matrix.org> Hello
-
m-relay
<explodius:matrix.org> howdy
-
m-relay
<controversial:matrix.org> Hi
-
m-relay
<lowdegree:matrix.org> I am the old 314stache_nathy from Reddit, nice to meet you again! :)
-
m-relay
<elongated:matrix.org> There was 8 block reorg not 9
-
m-relay
<flyingfish0:matrix.org> Is it technically possible to know ( as a miner software) if i'm taking part to an attack from my pool on the network ? and if so adding an option on the mining software to switch to another pool if such attack is detected. This prevents those who invest in monero from hurting the trust in the token
-
m-relay
<rucknium:monero.social> Good question for sech1
-
m-relay
<rucknium:monero.social> AFAIK, with standard `xmrig`, no you won't know. IIRC, bitcoin was working on something like this.
-
Evolver
elongated: Is that still not very concerning?
-
Evolver
flynigfish0: If it doesn't have 33% or some such high percent of share, then aren't the odds pretty low...
-
Evolver
*flyingfish0
-
m-relay
<elongated:matrix.org> Yes, after 10 block reorg, some txs will get invalidated
-
m-relay
<doingitforplowsof:synod.im> I'm so lucky I closed my Monero short before it went up. Managed to open a QUBIC short and I'll keep increasing my position. I don't think renting hash rate is effective, since it's being peddled by xenu the midwit, so I'm shorting QUBIC instead :D
-
m-relay
<doingitforplowsof:synod.im> Proof:
-
m-relay
<doingitforplowsof:synod.im>
ibb.co/GvHxJ23z
-
m-relay
<doingitforplowsof:synod.im>
ibb.co/934v4vCm
-
m-relay
<doingitforplowsof:synod.im> <Evolver> It's concerning, but not that much of an issue. Bitcoin had over 30+ block reorgs in the past. Qubic will only be able to disrupt the network for a small amount of time (remember that 1 block equals 2 minutes). This is nothing compared to their claims of a 51% attack where every block could be orphaned...
-
m-relay
<doingitforplowsof:synod.im> Also, they're operating at a loss for every epoch (which is why I'm shorting right now and will continue increasing my position; I put my money where my mouth is). I don't know why they're continuing this attack. They might be able to 51% if they somehow get an entire pool to switch, so it's still a threat on the table.
-
m-relay
<curry.guo:matrix.org> Can I manually select outputs (UTXOs) when constructing a Monero (XMR) transaction? By default, are the outputs selected automatically?
-
m-relay
<curry.guo:matrix.org> If the outputs are selected automatically, is there any way to obtain the key images before broadcasting the transaction?
-
m-relay
<doingitforplowsof:synod.im> I think you can in feather wallet.
-
m-relay
<doingitforplowsof:synod.im> Maybe monero-cli but I haven't tried.
-
m-relay
-
m-relay
<doingitforplowsof:synod.im> You can freeze outputs, so only certain ones are chosen.
-
m-relay
<curry.guo:matrix.org> When outputs are scanned into the wallet, can they be frozen by default?
-
m-relay
<curry.guo:matrix.org> When outputs are scanned into the wallet, can they be frozen by default?
-
m-relay
<doingitforplowsof:synod.im> What do you mean by default?
-
m-relay
<elongated:matrix.org> It is concerning for xmr, bcoz tx uses decoys and txs can become invalidated
-
m-relay
<elongated:matrix.org> It will get worse with fcmp++
-
m-relay
<curry.guo:matrix.org> Outputs are in an available state by default, right? Can they be frozen by default? Otherwise, when I construct a transaction, I would need to freeze outputs manually, and if new outputs arrive during construction, they might be automatically selected.
-
m-relay
<doingitforplowsof:synod.im> With reorgs deeper than 10 blocks they can.
-
m-relay
<doingitforplowsof:synod.im> I'm not sure...
-
m-relay
<doingitforplowsof:synod.im> I'm fairly certain that this would lead to a situation similar to a double spend, allowing nodes to detect and discard invalid transactions.
-
m-relay
<elongated:matrix.org> Double spend / privacy issue too
-
m-relay
<elongated:matrix.org> But hey we love botnets so let it be
-
m-relay
<doingitforplowsof:synod.im> It's an issue but compared to a 51% still not concerning.
-
Evolver
doingitforplowsof: What is a good platform to short stuff? And do I need a VPN?
-
m-relay
<elongated:matrix.org> Privacy is not concerning ? Really
-
m-relay
<doingitforplowsof:synod.im> What do you mean?
-
m-relay
<elongated:matrix.org> If a tx is invalidated, and you again spend again then your outputs stick out
-
m-relay
<elongated:matrix.org> Fixing decoy selection is needed
-
m-relay
<elongated:matrix.org> It’s all a mess
-
m-relay
<curry.guo:matrix.org> Recently, my attempts to construct transactions keep failing due to double-spending issues. I want to try manually selecting outputs. Is there any way to do this?
-
m-relay
<elongated:matrix.org> Doing so many things at a time while depending on basement warriors
-
m-relay
<elongated:matrix.org> Rescan your wallet and try spending
-
m-relay
<elongated:matrix.org> Doing so many things all at a time while depending on basement warriors
-
m-relay
<doingitforplowsof:synod.im> <Evolver> I use MEXC with KYC. I don't think using a VPN will be effective, as you'll likely still get flagged for KYC verification. It's possible to short without KYC with DEX perpetuals on Ethereum using platforms like Hyperliquid, but they don't currently support Qubic.
-
m-relay
<elongated:matrix.org> You need to be able to have any effect on spot price, you need a exchange in your pocket to do that or allowing leverage on spot
-
m-relay
<doingitforplowsof:synod.im> How can someone spend again with an invalid transaction when nodes can detect and reject invalid transactions?
-
m-relay
<curry.guo:matrix.org> I tried using sweep_all to send all the outputs and then transfer them back, but I still encountered similar issues. I feel this doesn't solve the underlying problem.
-
m-relay
<elongated:matrix.org> To be able to have any effect on spot price, you need a exchange in your pocket to do that or allowing leverage on spot
-
m-relay
<elongated:matrix.org> Did you rescan your wallet ?
-
m-relay
<elongated:matrix.org> Your spent outputs are valid but decoy was invalid, so when you spend again it will stand out
-
m-relay
<doingitforplowsof:synod.im> This is just wrong.
-
m-relay
<curry.guo:matrix.org> Not yet, but I try restoring the wallet based on the seed.
-
m-relay
<doingitforplowsof:synod.im> You don't know what arbitrage is?
-
m-relay
<curry.guo:matrix.org> Moreover, I found a transaction that spent the key image less than 10 minutes ago. Continuing to refresh the wallet probably won't make much difference, right?
-
m-relay
<doingitforplowsof:synod.im> I'm adding another 50k at 2800 :D
-
m-relay
<doingitforplowsof:synod.im> Yes due to one-time-spend. Once a key image has been used in a transaction, it cannot be reused again.
-
m-relay
<curry.guo:matrix.org> But the problem I'm facing now is that a subsequent transaction is using the same key image again.
-
m-relay
<curry.guo:matrix.org> Moreover, the two transactions are only 7 minutes apart.
-
m-relay
<doingitforplowsof:synod.im> Is the transaction still pending?
-
m-relay
<curry.guo:matrix.org> Moreover, the two transactions are 7 minutes apart.
-
m-relay
<doingitforplowsof:synod.im> And has the first transaction been confirmed?
-
m-relay
<curry.guo:matrix.org> The first transaction succeeded, but the second one failed to broadcast.
-
m-relay
<curry.guo:matrix.org> The log reports a "double spend" error.
-
m-relay
<curry.guo:matrix.org> Can I submit a support ticket
-
m-relay
<doingitforplowsof:synod.im> Rescan your outputs using a node from monero.fail
-
m-relay
<curry.guo:matrix.org> Refresh once without constructing a transaction?
-
m-relay
<curry.guo:matrix.org> Refresh once every time a transaction is constructed?
-
m-relay
<ofrnxmr:xmr.mx> Monero Support
-
m-relay
<curry.guo:matrix.org> Isn't that too troublesome? The transaction being used was constructed less than 7 minutes ago, so refreshing wouldn't still lead to a similar problem, right?
-
m-relay
<ofrnxmr:xmr.mx> Theres somethint you're not telling us
-
m-relay
<curry.guo:matrix.org> Isn't that too troublesome? The transaction being used was constructed less than 7 minutes ago, so refreshing wouldn still lead to a similar problem, right?
-
m-relay
<curry.guo:matrix.org> Isn't that too troublesome? The transaction being used was constructed less than 7 minutes ago, so refreshing would still lead to a similar problem, right?
-
m-relay
<ofrnxmr:xmr.mx> you must be doing something unusual?
-
m-relay
<ofrnxmr:xmr.mx> Something "extra"
-
m-relay
<ofrnxmr:xmr.mx> Like sending from multiple wallets
-
m-relay
<doingitforplowsof:synod.im> I don't know your specific situation, but if a wallet spent your XMR but was unable to update its state properly before being closed, it may incorrectly believe that the funds were not spent. Try rescanning your spent outputs using a trusted node
-
m-relay
<ofrnxmr:xmr.mx> If you send funds from wallet A, wallet A automatically marks them as spent, and wont try to spend the same outputs again. If youre getting double spend error, you must be spending from multiple wallets at once, or sonething like that
-
m-relay
<ofrnxmr:xmr.mx> It updates as soon as it is spent
-
m-relay
<doingitforplowsof:synod.im> This can fail though?
-
m-relay
<ofrnxmr:xmr.mx> I wouldnt expect a wallet bug for this, but a "im have 10 copies of the same wallet and am tryinf ro send txs from all of them"
-
m-relay
<ofrnxmr:xmr.mx> Not in my experience. The sending wallet will recodnize it in the mempool as well
-
m-relay
<ofrnxmr:xmr.mx> only time it doesnt, is my experience, is multiple wallets using the same seed
-
m-relay
<curry.guo:matrix.org> A seed only has one wallet
-
m-relay
<ofrnxmr:xmr.mx> How do you sends txs?
-
m-relay
<ofrnxmr:xmr.mx> What steps do you take
-
m-relay
<curry.guo:matrix.org> transfer and relay_tx
-
m-relay
<doingitforplowsof:synod.im> CfB claims they already had rigs for "AI", which means the cost of mining Monero is essentially free, potentially earning them a profit. This guy is quite the scammer and I can't believe I'm making money from this stupid shit.
-
racional_poi
how do you make money with this?
-
m-relay
<doingitforplowsof:synod.im> Qubic's Ponzi scheme model is based on a flawed "flywheel" mechanism, where the project subsidizes miner rewards with high emissions but fails to burn tokens at an adequate rate to prevent rampant inflation. Qubic is operating at a loss and I've seen how this plays out countless times on Ethereum. The issue with this approach is that the burn rate does not keep pace with the emiss<clipped message>
-
m-relay
<doingitforplowsof:synod.im> ion rate, as evidenced by their burning less than 1/4 of the emissions given to miners. This means that excess tokens will be sold on exchanges by the miners. Shorting is how you make money on the price going down
-
m-relay
<doingitforplowsof:synod.im> As the price drops, it creates a snowballing effect where miners who receive Qubic are incentivized to sell them as quickly as possible before other miners in order to maximize their profit.
-
m-relay
<doingitforplowsof:synod.im> The only way they can make a profit is if they convince enough miners to switch to Qubic. A successful 51% attack on the Monero network would allow them to gain funds through double spending, which could then be used to buy back their token. However, an attack is now unlikely because it would require multiple pools to concentrate all of their hashrate on Qubic. So far, none have s<clipped message>
-
m-relay
<doingitforplowsof:synod.im> hifted towards Qubic (despite the high emissions rate), and it's uncertain that they will change course when their emissions start decreasing. DNS checkpointing and other security measures implemented in the short term are also likely preventing such an attack from occurring.
-
m-relay
<elongated:matrix.org> Same can happen to xmr
-
m-relay
<doingitforplowsof:synod.im> XMR emissions are too low to have the effect. Also, Monero has demand from users who rely on it for its privacy, which helps to prevent the price from dropping significantly. Qubic's recent high emissions rate of $500k per epoch make it unlikely that anyone with a brain is buying their token. At current prices, Monero's daily emissions are around $100k...
-
m-relay
<doingitforplowsof:synod.im> XMR emissions are too low to have the effect. Also, Monero has demand from users who rely on it for its privacy, which helps to prevent the price from dropping significantly. Qubic's recent high emissions rate of $200k per epoch make it unlikely that anyone with a brain is buying their token. At current prices, Monero's daily emissions are around $100k...
-
m-relay
<elongated:matrix.org> If utility of coin is in danger, price doesn’t sustain
-
m-relay
<doingitforplowsof:synod.im> The impact of an attack on Monero's utility (privacy) is negligible, because unlike transparent blockchains, Qubic cannot reliably censor transactions. The main concern is the security of the chain itself, from double spending and the potential for Qubic to disrupt it by producing orphaned blocks.
-
m-relay
<doingitforplowsof:synod.im> if anyone knows SirJamzAlot or other prominent community members on X, can you pass along this info? If people know that shorting Qubic can be profitable, they might just do it.
-
m-relay
<doingitforplowsof:synod.im> We can fight fire with fire :D
-
racional_poi
what id the state/somebody help for up price ?
-
plowsof
The price manager can be contacted in #monero-markets
-
btcdwed
;P
-
plowsof
I see that someone is doingitforplowsof, thank you
-
m-relay
<eddie:oblak.be> lololol, qubic claims 51% attack, kraken buys into the fud and now they are "going after" dogecoin. But this something actually happen? I just keep sending and receiving XMR no problem
-
m-relay
<freddi99:matrix.org> whole lotta FUD, opportunity to stock up i guess?
-
m-relay
<eddie:oblak.be> Yeah. I find it peculiar though that a respected CEX like Kraken buys into this stuff without doing any research
-
m-relay
<eddie:oblak.be> Doesn't look great on them
-
m-relay
<basses:matrix.org> wym?
-
m-relay
<eddie:oblak.be> I thought the qubic saga was almost over, but I see articles appearing on various outlets ..
-
midipoet
Kraken have to take it seriously as they could be the target of a double-spend attack. in reality though, they could just extend their deposit confirmation threshold and i am sure it would be fine.
-
btcdwed
"buys into" what stuff?
-
btcdwed
dat qubic coin?
-
yetanotherminer
any specific room for mining questions? I want to mine off a cluster of VPSes. Which combination of vCPU and RAM is desired? I don’t want to make a profit FWIW but rather ‘buy monero indirectly from mining‘
-
m-relay
<mx_mandelbrot42:matrix.org> Monero Mining
-
moneromooo
#monero-pools on rizon (it got kicked from libera chat for participants' general assholery).
-
btcdwed
thats crazy :)
-
moneromooo
But here would be ok too.
-
moneromooo
Well, some people were leaning *heavy* on racist and other hate in there.
-
moneromooo
You know, as constant "jokes".
-
btcdwed
yea, i agree on that
-
btcdwed
i dont want it to call toxic, but it is :P
-
moneromooo
Sometimes, some people just need a good joke in the face, hard.
-
btcdwed
yea, sometimes
-
btcdwed
constantly joking on that level makes you a racists, etc
-
btcdwed
:P
-
yetanotherminer
thanks moneromooo
-
sech1
midipoet they did extend deposit confirmation to 720 :D
-
sech1
720 blocks confirmation time, lol
-
midipoet
that's wild
-
midipoet
i guess it'll probably work
-
midipoet
what's 24 hours worth in crypto-trading anyway
-
nioc
Are deposits open again on kraken?
-
m-relay
<elongated:matrix.org> Yes explains the premium dilution
-
nioc
Not that I can use them?
-
nioc
Thx
-
nioc
-?
-
m-relay
<elongated:matrix.org> You can deposit xmr
-
m-relay
-
m-relay
<elongated:matrix.org> 720 block conf, processing time ~1 day
-
m-relay
<elongated:matrix.org> Something better than nothing 😅
-
nioc
I have never been able to use kraken
-
m-relay
<elongated:matrix.org> Sorry for your loss
-
m-relay
-
m-relay
<sbt:nope.chat> he's publicly asking for doxing somebody? how dumb is he
-
m-relay
<sbt:nope.chat> also more power to the yellow guy, he's allegedly ddosing them
-
m-relay
<eddie:oblak.be> probably part of his theater
-
m-relay
<rbrunner7:monero.social> That's not a "hieroglyph". Thats's a hanzi, a Chinese character. Their full Telegram name is 薄荷, which seems to stand for peppermint, the plant.
-
plowsof
Mr Pepper plant
-
m-relay
<hbs:matrix.org> And the address is Independence Avenue 17, Minsk, Belarus
-
plowsof
We got him
-
m-relay
<ofrnxmr:monero.social> Y r u posting my old address
-
m-relay
<ofrnxmr:monero.social> Haven't lived there in years
-
plowsof
Is there a graph of hash available for rent @ miningrigs i over time or price per hash? Interesting metric. Eventually there will be >50% of the network hash available for rent 😃 digging the hole even deeper
-
plowsof
The jetfund may need to used to build a data center in the arctic , gingeropolous can set up all the machines for us :P
-
m-relay
<eddie:oblak.be> I have a script to make it, but it's not running atm, so no historic data
-
m-relay
<eddie:oblak.be> I'll make it run somewhere, and share the data
-
plowsof
🥲 thank you
-
m-relay
<stfstf:matrix.org> how come at the beginning of the month 1xmr ~ 300 usd and now it is 250 usd
-
m-relay
<syntheticbird:monero.social> bro is living the dream
-
m-relay
<syntheticbird:monero.social> he is out of the loop
-
nioc
how come monero was 50 cents 9 years ago and it is $270 now?
-
m-relay
<elongated:matrix.org> Btc was in 3 digits
-
m-relay
<alexandre:uii.pt> looking at it as an investment it would be great to have xmr increase the price, but it would seriously hinder it's adoption as an actual currency
-
Evolver
Why would it hinder?
-
Evolver
I haven't seen any evidence why. As it is, its price already pumps and dumps heavily.
-
nioc
elongated yes, xmr btc price was 0.001
-
Evolver
Also, its price will never go up like BTC or ETH because XMR dilutes more.
-
m-relay
<elongated:matrix.org> What do you mean by dilute ?
-
Evolver
tail emission
-
Evolver
In fact I think that for Monero to remain secure, its price has to go up, as the tail emission is constant.
-
m-relay
<elongated:matrix.org> Emission % is lower than btc
-
m-relay
<elongated:matrix.org> Monero security depends on cpu, usage of desktops is going down ; only farms will be securing monero in near future
-
m-relay
<elongated:matrix.org> And our beloved bots
-
m-relay
<elongated:matrix.org> We need to lower randomx requirements so toasters can mine
-
m-relay
<eddie:oblak.be> and tv's
-
m-relay
<elongated:matrix.org> TVs can already mine they have enough ram
-
m-relay
<elongated:matrix.org> Xmrig Android tv app should be launched so it mines while you watch your fav tv shows
-
m-relay
<elongated:matrix.org> Or gupax with p2pool
-
Evolver
There are plenty of laptops. No shortage there. They're of poor qualify in that heavy mining will probably cut their life a lot.
-
m-relay
<17lifers:matrix.org> mfer
-
Evolver
and I mean laptops that always stay connected.
-
m-relay
<17lifers:matrix.org> android tv boxes have 2-4gb ram
-
m-relay
<17lifers:matrix.org> will xmrig fast mode run on that
-
m-relay
<elongated:matrix.org> Laptop battery issues, tvs stay connected to power
-
Evolver
About half the laptops never disconnect from mains power.
-
m-relay
<17lifers:matrix.org> yes i run this thing on the charger 24/7
-
m-relay
<elongated:matrix.org> While they are being used and if you are using your laptop, mining with it is a nuisance for user experience
-
m-relay
<alexandre:uii.pt> Evolver: I wouldn't really want to with 1xmr be able to buy a car one day and the next day not even able to buy a piece of bread
-
m-relay
<alexandre:uii.pt> hopefully it won't be like btc, but you get what i mean
-
Evolver
it's never going to be like that, so stop being hysterical
-
Evolver
If the car vs bread analogy ever comes true, it means it's dead.
-
Evolver
and it's a shitcoin at that point
-
Evolver
and it's game over
-
m-relay
<alexandre:uii.pt> i see
-
Evolver
The technical reason for this is that for non-shitcoins, e.g. Monero, a moving average of the price floor rises steadily, and only rises, not falls.
-
Evolver
It could hold steady though without rising, which too is fine.
-
Evolver
But if the bread analogy became true, that means it has sunk.
-
Evolver
People watch these levels and they buy. It's not some random insignificant number.
-
racional-poi
its true that only with 35% hashrate can be performed 51% attack ?
-
moneromooo
With any kind of hash rate, it's a probabilistic thing, so the lower the hash rate, the less likely it becomes.
-
yetanotherminer
How does RAM requirements differ from xmrig fast vs light mode?
-
m-relay
<17lifers:matrix.org> light mode requires 256mb free, fast mode requires 2.3gb free + hugepages
-
m-relay
<17lifers:matrix.org> wont fit in 2gb and will be extremely cramped in 4gb
-
racional-poi
moneromooo: you right, thank u
-
racional-poi
Qubic has over 70% hashrate now, source ->
miningpoolstats.stream/monero
-
Guest53
ok
-
racional-poi
am I right ? I see hashrate hasa 3.99 hashrte, network has 5.52 hashrate total
-
sT0p
reported pool hashrate is 7.6, and qubic reports indeed 3.99
-
sT0p
but at the moment only mining < 30% of the blocks
-
racional-poi
3.96 / 7.76 * 100 = 51% is Monero under attack ?
-
racional-poi
what is most important, blocks number or hashrate ?
-
sT0p
you need to look at blocks mined
-
sT0p
hashrate is not reliable
-
racional-poi
ok, what is a percent of blocks mined by Qubic that will be danger ?
-
sT0p
when they consistently mine more than 51% of the blocks, afaik
-
sT0p
if it just happens once, no man overboard
-
selsta
with selfish mining and 51% they would mine all blocks
-
racional-poi
so I don't understand, should I see blocked mined or hashrate =
-
m-relay_
<lowdegree:matrix.org> Use moneroconsensus.info for real data
-
m-relay_
<lowdegree:matrix.org> Use
moneroconsensus.info for real data
-
m-relay_
<jack_ma_blabla:matrix.org> doesn't show hashrate
-
m-relay_
<lowdegree:matrix.org> Moneroconsensus.info -> Blocks mined by mining pools
-
m-relay_
<lowdegree:matrix.org> :)
-
m-relay_
<lowdegree:matrix.org> Qubic problably have 20% of hashrate.
-
m-relay_
<lowdegree:matrix.org> Or less, Qubic use selfish mining
-
racional-poi
@lowdegree thank you
-
m-relay_
<lowdegree:matrix.org> Qubic problably have ~20% of hashrate.
-
racional-poi
-
selsta
racional-poi: pools self advertise their hashrate so it can be faked
-
m-relay_
<lowdegree:matrix.org> Qubic can falsify the hashrate API
-
m-relay_
<gingeropolous:monero.social> there was a pool the other day that posted a 7 GH read
-
m-relay_
<gingeropolous:monero.social> for the lulz, just to prove its not trustworthy
-
m-relay_
<lowdegree:matrix.org> Fastpool.xyz maked this.
-
m-relay_
<gingeropolous:monero.social> yeah
-
racional-poi
this page just trust in the Mining pool's API ?
-
m-relay_
<lowdegree:matrix.org> Fastpool🤝Qubic - Falsify the hashrate
-
m-relay_
<lowdegree:matrix.org> Yep
-
btcdwed
thanks for the infos guys!
-
racional-poi
the way more reliable is see blocked mined, right ?
-
btcdwed
right
-
m-relay_
<shortwavesurfer2009:monero.social> Hey, does anybody know if any of the big wallet services like cake are running an I2P node?
-
racional-poi
btcdwed thank you
-
btcdwed
kudos to the others, i was just reading :P
-
m-relay_
-
m-relay_
<shortwavesurfer2009:monero.social> I'm afraid of ending up with a chain analysis spy node by using that link.
-
m-relay_
<lowdegree:matrix.org> You can: go to the Monero.fail website -> select 'I2P' and filter. Done :)
-
plowsof
-
m-relay_
<lowdegree:matrix.org> Or are you talking about accidentally selecting a malicious node? I always recommend running your own node + opening port 18081 + using it via I2P/TOR. But if you can't, use a node via Tor/I2P that you trust.
-
m-relay_
<lowdegree:matrix.org> I noticed that the number of public nodes using I2P has increased in recent times.
-
plowsof
shortwavesurfer2009 do not use monero.fail
-
plowsof
-
m-relay_
<ofrnxmr:xmr.mx> I am
-
m-relay_
<ofrnxmr:xmr.mx> Its on link plowsof posted
-
plowsof
the i2p list on monero fail has many recently added too, spider senses tingling no thank you, especially after all those 1211231332133 tor nodes there
-
m-relay_
<shortwavesurfer2009:monero.social> Thanks, I'm trying I2P again and needed an RPC to test with.
-
m-relay_
<shortwavesurfer2009:monero.social> Yeah, I wasn't planning on using any of those. I figure any of them that are there are likely to be chain analysis spy nodes, and I don't want to touch them.
-
m-relay_
<lowdegree:matrix.org> Correct me if I'm wrong. But after FCMP++, if I potentially use a Tor/I2P node, that kind of renders the malicious nodes useless, right? Hidden IP and no decoy issue.
-
nioc
send nodes
-
nioc
what specs are recommended for a good public node?
-
m-relay_
<ofrnxmr:xmr.mx> No, a malicious node can still track your ip an correlate txids with whatever FBI service youre depositing to
-
plowsof
deciding if transactions belong to the same entity, uhm doing all the other malicious stuff like giving a bogus tx fee or essentially bricking your wallet / displaying wrong balance etc
-
plowsof
tor/i2p node can do all of that
-
m-relay_
<ofrnxmr:xmr.mx> fcmp solves the decoy issue, not any networking ones
-
m-relay_
<shortwavesurfer2009:monero.social> No, even after FCMP, you cannot rely on remote nodes unless you know they are safe.
-
m-relay_
<shortwavesurfer2009:monero.social> As mentioned above, they are able to mess with the transaction fee and make it easier to fingerprint your transactions.
-
m-relay_
<shortwavesurfer2009:monero.social> I have some trust in ofrnxmr bc hes real
-
m-relay_
<lowdegree:matrix.org> Thx guys.
-
plowsof
monerod print_cn | grep I2P ..... what on earth is that monero fail i2p node list lol
-
plowsof
nioc specs for a good public node? you have to just hope not everyone uses it at once to be honest. bandwidth will be the main bottleneck assuming you have all the cores and all the ram moneys can buy
-
m-relay_
<ofrnxmr:xmr.mx> I was going to say: how public?
-
plowsof
:D
-
m-relay_
<ofrnxmr:xmr.mx> Cake wallet public? Like 256gb ram
-
nioc
just follow the wire to my house
-
m-relay_
<ofrnxmr:xmr.mx> Plowsof is everyones proxy public? Probably shit ton of upload bandwidth
-
nioc
how much bandwidth?
-
m-relay_
<ofrnxmr:xmr.mx> Ofrn i2p public? Like 0.4 average weekly users
-
m-relay_
<ofrnxmr:xmr.mx> Plowsof - wikd guess, many TBs
-
nioc
ofrn maybe you should do an xmr giveaway
-
m-relay_
<ofrnxmr:xmr.mx> how much?
-
nioc
get people to use it
-
m-relay_
<lowdegree:matrix.org> Well, at least we have good news with Rucknium starting their research on remote nodes and protection against malicious nodes. (
ccs.getmonero.org/proposals/Rucknium-Research-II.html)
-
nioc
other things will take priority rn but we are still lucky to have him as well as many others <3
-
plowsof
yes bandwidth limits hit but you should be at least able to push/pull around ~1TB a month so 100Mbit/s up/down minimum
-
nioc
thx plowsof
-
m-relay_
<shortwavesurfer2009:monero.social> I was always under the impression that I2P was supposed to be faster than a tor hidden service, but so far as I can tell, that is not the case.
-
btcdwed
cakexmrl7bonq7ovjka5kuwuyd3f7qnkz6z6s6dmsy3uckwra7bvggyd.onion
-
btcdwed
xmr-node.cakewallet.com
-
btcdwed
should i use other nodes with cake wallet?
-
btcdwed
oh, i see the first one in your list plowsof :P
-
m-relay_
<shortwavesurfer2009:monero.social> Oh, see, look, it only took me 31 minutes to pull 51 megabytes of data to synchronize 1,500 blocks on my wallet over I2P.
-
btcdwed
both are in there. sry for asking :P
-
m-relay_
<shortwavesurfer2009:monero.social> Tor is WAYYYYYY faster