closed them

<p​lowsof:matrix.org> bitmain x5 miners' firmware has been released, its being looked at/discussed in #monero-pow libera.monerologs.net/monero-pow/20230919

<r​brunner7:monero.social> It's always a happy day if a new toy gets available.

are these spam issues new? previously they would only spam comments

The last round of spam issues was just cleaned. They make issues now, and also comments :(

<1​23bob123:matrix.org> Spamgpt

<m​r7seven7_91387_20052> hey frens.

Hey all, had a question about 0-conf. So we often reply with "0-conf" is okay for small purchases, but I have some doubts. Maybe yall can confirm/deny

So hypothetically, couldn't you create a special version of a wallet, designed for 0-conf, double spend trickery? Like spend funds to merchant who accepts 0-conf, then broadcast a 2nd transaction with a higher fee?

Or create two conflicting transactions, and target broadcasting different txns to different nodes that you're connected to, such that, it's more likely for the merchant to see their txn that is their payment, and more likely that geographically distant nodes/miners are likely to see the devious double spend?

Obviously you wont "double spend" onchain, but the idea being that, you've deceived a 0-conf merchant into accepting your txn for long enough, with decent chances that your other trick transaction gets picked up by the network instead

There's no replace by fee

You can't broadcast transaction with higher fee, nodes will not accept it

You can only broadcast two transactions at the same time, and split the network into two halves

Then hope that merchant's tx will not be mined

Of course, if you have a list of major pool nodes, you increase the chances of a successful attack

Because you can then broadcast the second tx directly to mining pools

<c​ryptogrampy:monero.social> Why

<r​brunner7:monero.social> It's simply not implemented. Regardless of fee the second tx will get rejected as a double-spend attempt

RBF is practical on BTC but I don't see usecase for XMR.

Except maybe if one want to cancel a payment before it confirm?!

<e​ndor00:matrix.org> It's a trade-off

Thanks sech!

whoa BawdyAnarchist on IRC

<d​_s_i_l_v_a_:matrix.org> Is it possible to swap SIS into BTC?

<c​ouldbecollin:matrix.org> What kind of token is this? Didn't research before buying it?😂

<d​_s_i_l_v_a_:matrix.org> I didn't buy it) it's an Airdrop

<d​_s_i_l_v_a_:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/iFTuQjCSlXrTlBHHNqTpngNx

<c​ouldbecollin:matrix.org> So what's the project? SIS

<d​_s_i_l_v_a_:matrix.org> symbiosis.icu

<c​ouldbecollin:matrix.org> It's ETH token, ETH network, can be exchanged to BTC only through several exchanges, all your airdrop will go to the commission fee😅

<d​_s_i_l_v_a_:matrix.org> At least I'll get something out of it?)Maybe you know some places where the fee is lower?

<c​ouldbecollin:matrix.org> Look it up yourself dude, or just swap it into

<s​needlewoods_xmr:matrix.org> why ban?

<c​ouldbecollin:matrix.org> for link maybe

<e​ndor00:matrix.org> I've seen many spambots/spammers playing that kind of "script"

<e​ndor00:matrix.org> Asking questions about the latest ~scam~ airdrop, link to the website as soon as someone asks something, plus screenshot of metamask with the token in their wallet

Good catch

<s​needlewoods_xmr:matrix.org> oic

<Inge> I've been lurking for a long time. Have on occasion had lengthy interactions in #monero-markets

So thinking about this some more, 0-conf seems like a real concern. Not right now, but if merchants ever started using it to a significant degree

There'd likely be wallets created specifically to execute this attack. I do wonder though how much Dandelion mitigates that

(if at all)

Is Dandelion++ of the nature that a user can basically turn it off if they want?

<e​ndor00:matrix.org> This has been brought up before. The key takeaway is that it's up to the business owner to decide what's a "safe" amount for 0-conf *for them*. i.e. pick a limit amount low enough that it's really not worthwhile to perform such an attack - and if it somehow still happens, you don't lose much anyway

<e​ndor00:matrix.org> Obviously you're not gonna let someone spending $10k run away without any confs

Well that's just the thing. It might be safe now. But if 0-conf becomes widely used, maybe some more sophisticated attacks emerge that make it generally unsafe. That's what I'm trying to understand

I'm not tryna criticize. Just genuinely trying to understand how likely/unlikely such attacks would become if 0-conf was widely used.

For example, rn it seems like it'd be easy to target miner pools with the "double spend", and target the local merchant node with the "fake spend." But I wonder if Dandelion++ makes that difficult, due to the unpredictability of when the txn will flood.

<e​ndor00:matrix.org> iirc D++ makes things *slightly* worse (because txes don't get propagated like a "floodfill", but there's the whole stem/fluff mechanism), but it's still negligible. Txes get relayed across most of the network in the order of tens seconds. It's a pretty tight attack window

<r​ucknium:monero.social> A node can decide to immediately broadcast txs to the "fluff" phase of Dandelion++. So, yes, a node can "turn off" D++. AFAIK, a wallet cannot decide to do it. It's the node that decides what to do with a tx than a wallet has submitted.

<r​ucknium:monero.social> Someone could look into whether Monero can implement double spend proofs like BCH

<e​ndor00:matrix.org> This is the first time I hear about double-spend protection on zero-confs :D

Was talking with someone on Twitter who was VERY confident that 0-conf attacks would 100% become common if 0-conf was common. I dont think he necessarily understands the full ins/outs of this, but neither was I confident in my knowledge either

<r​ucknium:monero.social> IIRC xmr.to operated for years with 0-conf

I feel like, if a wallet cant decide whether its txn will have D++ (or what the stem/bloom timing will look like), then 0-conf attack becomes very low success rate. Coz you cant be sure if your "double spend" to a mining pool will bloom before the intended "fake spend."

You basically need both to bloom simultaneously to their respective targets

<r​ucknium:monero.social> I think this case used BTC's RBF. I'm not sure : protos.com/bitcoin-double-spending-…canada-atm-honeybadger-scam-calgary

<e​ndor00:matrix.org> I think it's not so much about the popularity of 0-conf, but the incentive - i.e. if there's a big enough target that it's actually worth the time and effort

<e​ndor00:matrix.org> Which means either a large enough amount of money, or a time-vulnerable payment mechanism somewhere

Assume that 0-conf is accepted by numerous merchants for txns below $20 value. Furthermore, we assume a probability of successful attack. More merchants mean more successful attacks, and a higher incentive to create a wallet to implement that attack.

I understand this is mostly theoretical at the moment.

<e​ndor00:matrix.org> But the success of individual attacks is not based on the number of merchants accepting 0-conf

But it is based on the number of attacks carrid out

More merchants means more opportunity and more targets to spread the attack over

<e​ndor00:matrix.org> Unless you and your buddie(s) all go to different coffee shops at the same time and try to buy coffee using the same wallet, you're not gonna get much out of it

<e​ndor00:matrix.org> A target will (or won't) be vulnerable regardless of the presence of other targets

<e​ndor00:matrix.org> You don't need more merchants to carry out an attack, the competing transaction could just be a self-spend

I understand that # of merchants accepting 0-conf has no bearing on the success of any particular attack. What I'm saying is that it increases the likelyhood one or more people will create a wallet to attempt the attack.

If I have a special wallet that can 0-conf double spend, then if there's lots of merchants where I'm spending daily, I'll always try to double spend, and occasionally get a free coffee (or whatever)

More merchants means more people incentivized to do the same.

<e​ndor00:matrix.org> You can already do that today, with the existing wallets

<e​ndor00:matrix.org> (Though working around their automated refreshing might be a bit of a pain without some code changes)

<e​ndor00:matrix.org> You can always generate a "new spend", even for old spent outputs. But as soon as you submit that tx to a node, it will get rejected

Right, but the attack isnt regarding nodes accepting a double spend, but about sending two different txns simultaneously to different parts of the network.

*2 txns spending the same output

You'd need a wallet that would generate both txns, and connect to specific nodes, deciding which nodes receive which txn

trying to get the double spend to mining pool nodes, and the fake spend to a merchant.

<1​23bob123:matrix.org> Doesnt that break conseus?

<e​ndor00:matrix.org> Nope. One of the two will eventually be mined, and the other one rejected

<s​packle_xmr:matrix.org> Couldn't a node report if it has received/rejected a double spend attempt for a transaction in the mempool?

<s​packle_xmr:matrix.org> I know it would never receive the other tx if it was isolated from the wrong part of the network, but if a node has even 10 out connections the probability of seeing the second transaction would be high.

It will print "Transaction with id=... used already spent key images" in the log

but it's on log level 1, and default is 0

<s​packle_xmr:matrix.org> I was imagining a nicer convenience feature, but that makes sense. I don't see why that can't be part of instructing merchants on taking 0-conf if this is a concern.

<r​ucknium:monero.social> Node won't broadcast the double-spend tx, right? There will be a "wall" in the network graph. Only nodes on the frontier of the wall will see that message.

<r​ucknium:monero.social> Anyway, look at double spend proofs and zero conf escrows! Monero doesn't do "not invented here syndrome".

Node won't even accept the double-spend tx

<s​packle_xmr:matrix.org> A quick read on double spend proofs suggests this is the answer people are looking for. Relaying part of tx when receiving a double-spend attempt as a notice makes sense.

<s​packle_xmr:matrix.org> ZCE looks to use BCH features Monero does not have.

<s​packle_xmr:matrix.org> Yeah that does seem to be a viable mitigation. At least a high enough threshold that merchants could easily feel comfortable for smaller amounts.

<s​packle_xmr:matrix.org> I suppose the Monero version could be to send a notice made of key image + membership proof + ring member offsets. That way there's enough information to mark the attempt, and the notice can't be fabricated by an adversary.

<s​packle_xmr:matrix.org> I am not familiar with the network communications side of things, but I imagine this would take a significant amount of work.

<s​packle_xmr:matrix.org> Sorry, bad idea. They'd just use the same membership proof for both attempts.

<e​ndor00:matrix.org> Couldn't it be combined with the txid, in some way? That way, the two competing transactions would invalidate eachother

[meta] Rucknium opened issue #897: Monero Research Lab Meeting - Wed 20 September 2023, 17:00 UTC

> monero-project/meta #897

<c​hch3003:monero.social> Is there a big party planned for the 10 years of Monero?

<A​bo Gemaal el-Folani 👑 {𝕭𝕽𝕲}> We live, we love, we lie

<1​23bob123:matrix.org> Hookers and blow?