<l​owdegree:matrix.org> Hello

<e​xplodius:matrix.org> howdy

<c​ontroversial:matrix.org> Hi

<l​owdegree:matrix.org> I am the old 314stache_nathy from Reddit, nice to meet you again! :)

<e​longated:matrix.org> There was 8 block reorg not 9

<f​lyingfish0: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

<r​ucknium:monero.social> Good question for sech1

<r​ucknium:monero.social> AFAIK, with standard `xmrig`, no you won't know. IIRC, bitcoin was working on something like this.

elongated: Is that still not very concerning?

flynigfish0: If it doesn't have 33% or some such high percent of share, then aren't the odds pretty low...

*flyingfish0

<e​longated:matrix.org> Yes, after 10 block reorg, some txs will get invalidated

<d​oingitforplowsof: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

<d​oingitforplowsof:synod.im> Proof:

<d​oingitforplowsof:synod.im> ibb.co/GvHxJ23z

<d​oingitforplowsof:synod.im> ibb.co/934v4vCm

<d​oingitforplowsof:synod.im> <E​volver> 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...

<d​oingitforplowsof: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.

<c​urry.guo:matrix.org> Can I manually select outputs (UTXOs) when constructing a Monero (XMR) transaction? By default, are the outputs selected automatically?

<c​urry.guo:matrix.org> If the outputs are selected automatically, is there any way to obtain the key images before broadcasting the transaction?

<d​oingitforplowsof:synod.im> I think you can in feather wallet.

<d​oingitforplowsof:synod.im> Maybe monero-cli but I haven't tried.

<d​oingitforplowsof:synod.im> docs.featherwallet.org/guides/freeze-thaw-output

<d​oingitforplowsof:synod.im> You can freeze outputs, so only certain ones are chosen.

<c​urry.guo:matrix.org> When outputs are scanned into the wallet, can they be frozen by default?

<c​urry.guo:matrix.org> When outputs are scanned into the wallet, can they be frozen by default?

<d​oingitforplowsof:synod.im> What do you mean by default?

<e​longated:matrix.org> It is concerning for xmr, bcoz tx uses decoys and txs can become invalidated

<e​longated:matrix.org> It will get worse with fcmp++

<c​urry.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.

<d​oingitforplowsof:synod.im> With reorgs deeper than 10 blocks they can.

<d​oingitforplowsof:synod.im> I'm not sure...

<d​oingitforplowsof: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.

<e​longated:matrix.org> Double spend / privacy issue too

<e​longated:matrix.org> But hey we love botnets so let it be

<d​oingitforplowsof:synod.im> It's an issue but compared to a 51% still not concerning.

doingitforplowsof: What is a good platform to short stuff? And do I need a VPN?

<e​longated:matrix.org> Privacy is not concerning ? Really

<d​oingitforplowsof:synod.im> What do you mean?

<e​longated:matrix.org> If a tx is invalidated, and you again spend again then your outputs stick out

<e​longated:matrix.org> Fixing decoy selection is needed

<e​longated:matrix.org> It’s all a mess

<c​urry.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?

<e​longated:matrix.org> Doing so many things at a time while depending on basement warriors

<e​longated:matrix.org> Rescan your wallet and try spending

<e​longated:matrix.org> Doing so many things all at a time while depending on basement warriors

<d​oingitforplowsof:synod.im> <E​volver> 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.

<e​longated: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

<d​oingitforplowsof:synod.im> How can someone spend again with an invalid transaction when nodes can detect and reject invalid transactions?

<c​urry.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.

<e​longated: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

<e​longated:matrix.org> Did you rescan your wallet ?

<e​longated:matrix.org> Your spent outputs are valid but decoy was invalid, so when you spend again it will stand out

<d​oingitforplowsof:synod.im> This is just wrong.

<c​urry.guo:matrix.org> Not yet, but I try restoring the wallet based on the seed.

<d​oingitforplowsof:synod.im> You don't know what arbitrage is?

<c​urry.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?

<d​oingitforplowsof:synod.im> I'm adding another 50k at 2800 :D

<d​oingitforplowsof:synod.im> Yes due to one-time-spend. Once a key image has been used in a transaction, it cannot be reused again.

<c​urry.guo:matrix.org> But the problem I'm facing now is that a subsequent transaction is using the same key image again.

<c​urry.guo:matrix.org> Moreover, the two transactions are only 7 minutes apart.

<d​oingitforplowsof:synod.im> Is the transaction still pending?

<c​urry.guo:matrix.org> Moreover, the two transactions are 7 minutes apart.

<d​oingitforplowsof:synod.im> And has the first transaction been confirmed?

<c​urry.guo:matrix.org> The first transaction succeeded, but the second one failed to broadcast.

<c​urry.guo:matrix.org> The log reports a "double spend" error.

<c​urry.guo:matrix.org> Can I submit a support ticket

<d​oingitforplowsof:synod.im> Rescan your outputs using a node from monero.fail

<c​urry.guo:matrix.org> Refresh once without constructing a transaction?

<c​urry.guo:matrix.org> Refresh once every time a transaction is constructed?

<o​frnxmr:xmr.mx> Monero Support

<c​urry.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?

<o​frnxmr:xmr.mx> Theres somethint you're not telling us

<c​urry.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?

<c​urry.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?

<o​frnxmr:xmr.mx> you must be doing something unusual?

<o​frnxmr:xmr.mx> Something "extra"

<o​frnxmr:xmr.mx> Like sending from multiple wallets

<d​oingitforplowsof: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

<o​frnxmr: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

<o​frnxmr:xmr.mx> It updates as soon as it is spent

<d​oingitforplowsof:synod.im> This can fail though?

<o​frnxmr: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"

<o​frnxmr:xmr.mx> Not in my experience. The sending wallet will recodnize it in the mempool as well

<o​frnxmr:xmr.mx> only time it doesnt, is my experience, is multiple wallets using the same seed

<c​urry.guo:matrix.org> A seed only has one wallet

<o​frnxmr:xmr.mx> How do you sends txs?

<o​frnxmr:xmr.mx> What steps do you take

<c​urry.guo:matrix.org> transfer and relay_tx

<d​oingitforplowsof: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.

how do you make money with this?

<d​oingitforplowsof: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>

<d​oingitforplowsof: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

<d​oingitforplowsof: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.

<d​oingitforplowsof: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>

<d​oingitforplowsof: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.

<e​longated:matrix.org> Same can happen to xmr

<d​oingitforplowsof: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...

<d​oingitforplowsof: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...

<e​longated:matrix.org> If utility of coin is in danger, price doesn’t sustain

<d​oingitforplowsof: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.

<d​oingitforplowsof: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.

<d​oingitforplowsof:synod.im> We can fight fire with fire :D

what id the state/somebody help for up price ?