01:57:56 <luigi1111w> closed them
06:30:18 <m-relay> <p​lowsof:matrix.org> bitmain x5 miners' firmware has been released, its being looked at/discussed in #monero-pow https://libera.monerologs.net/monero-pow/20230919
08:13:22 <m-relay> <r​brunner7:monero.social> It's always a happy day if a new toy gets available.
09:45:11 -xmr-pr- [css-proposals] billyroberts opened issue #75: The Role of Online Casinos in the New Zealand Economy
09:45:11 -xmr-pr- > https://repo.getmonero.org/monero-project/ccs-proposals/-/issues/75
11:30:11 -xmr-pr- [css-proposals] Joyce121 opened issue #76: Spinning the Future: Online and the Path Ahead
11:30:11 -xmr-pr- > https://repo.getmonero.org/monero-project/ccs-proposals/-/issues/76
11:48:05 <selsta> are these spam issues new? previously they would only spam comments
12:40:34 <plowsof> The last round of spam issues was just cleaned. They make issues now, and also comments :(
12:48:16 <m-relay> <1​23bob123:matrix.org> Spamgpt
15:47:57 <m-relay> <m​r7seven7_91387_20052> hey frens.
17:40:21 <BawdyAnarchist> 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
17:41:51 <BawdyAnarchist> 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?
17:43:56 <BawdyAnarchist> 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?
17:44:52 <BawdyAnarchist> 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
17:49:37 <sech1> There's no replace by fee
17:49:49 <sech1> You can't broadcast transaction with higher fee, nodes will not accept it
17:50:18 <sech1> You can only broadcast two transactions at the same time, and split the network into two halves
17:50:27 <sech1> Then hope that merchant's tx will not be mined
17:51:33 <sech1> Of course, if you have a list of major pool nodes, you increase the chances of a successful attack
17:51:48 <sech1> Because you can then broadcast the second tx directly to mining pools
18:02:38 <m-relay> <c​ryptogrampy:monero.social> Why
18:03:11 <m-relay> <r​brunner7:monero.social> It's simply not implemented. Regardless of fee the second tx will get rejected as a double-spend attempt
18:09:08 <RavFX> RBF is practical on BTC but I don't see usecase for XMR.
18:09:24 <RavFX> Except maybe if one want to cancel a payment before it confirm?!
18:12:30 <m-relay> <e​ndor00:matrix.org> It's a trade-off
18:26:49 <BawdyAnarchist> Thanks sech!
18:46:21 <Inge> whoa BawdyAnarchist on IRC
18:54:20 <m-relay> <d​_s_i_l_v_a_:matrix.org> Is it possible to swap SIS into BTC?
18:54:56 <m-relay> <c​ouldbecollin:matrix.org> What kind of token is this? Didn't research before buying it?😂
18:55:36 <m-relay> <d​_s_i_l_v_a_:matrix.org> I didn't buy it) it's an Airdrop
18:55:48 <m-relay> <d​_s_i_l_v_a_:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/iFTuQjCSlXrTlBHHNqTpngNx
18:56:16 <m-relay> <c​ouldbecollin:matrix.org> So what's the project? SIS
18:56:51 <m-relay> <d​_s_i_l_v_a_:matrix.org> symbiosis.icu
18:59:46 <m-relay> <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😅
19:00:53 <m-relay> <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?
19:02:26 <m-relay> <c​ouldbecollin:matrix.org> Look it up yourself dude, or just swap it into
19:09:30 <m-relay> <s​needlewoods_xmr:matrix.org> why ban?
19:15:39 <m-relay> <c​ouldbecollin:matrix.org> for link maybe
19:29:23 <m-relay> <e​ndor00:matrix.org> I've seen many spambots/spammers playing that kind of "script"
19:31:55 <m-relay> <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
19:32:09 <plowsof> Good catch 
19:37:46 <m-relay> <s​needlewoods_xmr:matrix.org> oic
19:42:03 <BawdyAnarchist> <Inge> I've been lurking for a long time. Have on occasion had lengthy interactions in #monero-markets
19:48:09 <BawdyAnarchist> 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
19:48:53 <BawdyAnarchist> There'd likely be wallets created specifically to execute this attack. I do wonder though how much Dandelion mitigates that
19:48:56 <BawdyAnarchist> (if at all)
19:49:22 <BawdyAnarchist> Is Dandelion++ of the nature that a user can basically turn it off if they want?
19:50:53 <m-relay> <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
19:51:43 <m-relay> <e​ndor00:matrix.org> Obviously you're not gonna let someone spending $10k run away without any confs
19:51:51 <BawdyAnarchist> 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
19:52:27 <BawdyAnarchist> I'm not tryna criticize. Just genuinely trying to understand how likely/unlikely such attacks would become if 0-conf was widely used.
19:53:52 <BawdyAnarchist> 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.
19:54:41 <m-relay> <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
19:55:33 <m-relay> <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.
19:56:00 <m-relay> <r​ucknium:monero.social> Someone could look into whether Monero can implement double spend proofs like BCH
19:56:50 <m-relay> <e​ndor00:matrix.org> This is the first time I hear about double-spend protection on zero-confs :D
19:58:06 <BawdyAnarchist> 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
19:58:56 <m-relay> <r​ucknium:monero.social> IIRC xmr.to operated for years with 0-conf
20:00:12 <BawdyAnarchist> 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."
20:00:43 <BawdyAnarchist> You basically need both to bloom simultaneously to their respective targets
20:01:06 <m-relay> <r​ucknium:monero.social> I think this case used BTC's RBF. I'm not sure : https://protos.com/bitcoin-double-spending-canada-atm-honeybadger-scam-calgary/
20:04:25 <m-relay> <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
20:06:02 <m-relay> <e​ndor00:matrix.org> Which means either a large enough amount of money, or a time-vulnerable payment mechanism somewhere
20:07:16 <BawdyAnarchist> 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.
20:07:46 <BawdyAnarchist> I understand this is mostly theoretical at the moment.
20:08:00 <m-relay> <e​ndor00:matrix.org> But the success of individual attacks is not based on the number of merchants accepting 0-conf
20:08:13 <BawdyAnarchist> But it is based on the number of attacks carrid out
20:08:28 <BawdyAnarchist> More merchants means more opportunity and more targets to spread the attack over
20:09:45 <m-relay> <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
20:10:27 <m-relay> <e​ndor00:matrix.org> A target will (or won't) be vulnerable regardless of the presence of other targets
20:10:48 <m-relay> <e​ndor00:matrix.org> You don't need more merchants to carry out an attack, the competing transaction could just be a self-spend
20:15:44 <BawdyAnarchist> 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.
20:16:50 <BawdyAnarchist> 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)
20:17:37 <BawdyAnarchist> More merchants means more people incentivized to do the same.
20:18:13 <m-relay> <e​ndor00:matrix.org> You can already do that today, with the existing wallets
20:19:08 <m-relay> <e​ndor00:matrix.org> (Though working around their automated refreshing might be a bit of a pain without some code changes)
20:20:28 <m-relay> <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
20:21:54 <BawdyAnarchist> Right, but the attack isnt regarding nodes accepting a double spend, but about sending two different txns simultaneously to different parts of the network.
20:22:11 <BawdyAnarchist> *2 txns spending the same output
20:23:25 <BawdyAnarchist> You'd need a wallet that would generate both txns, and connect to specific nodes, deciding which nodes receive which txn
20:23:53 <BawdyAnarchist> trying to get the double spend to mining pool nodes, and the fake spend to a merchant.
20:28:44 <m-relay> <1​23bob123:matrix.org> Doesnt that break conseus?
20:30:00 <m-relay> <e​ndor00:matrix.org> Nope. One of the two will eventually be mined, and the other one rejected
20:30:52 <m-relay> <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?
20:30:52 <m-relay> <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.
20:32:27 <sech1> It will print "Transaction with id=... used already spent key images" in the log
20:33:16 <sech1> but it's on log level 1, and default is 0
20:35:05 <m-relay> <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.
20:36:38 <m-relay> <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.
20:37:21 <m-relay> <r​ucknium:monero.social> Anyway, look at double spend proofs and zero conf escrows! Monero doesn't do "not invented here syndrome".
20:44:26 <sech1> Node won't even accept the double-spend tx
20:55:05 <m-relay> <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. 
20:55:05 <m-relay> <s​packle_xmr:matrix.org> ZCE looks to use BCH features Monero does not have.
21:06:21 <BawdyAnarchist> <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.
21:36:37 <m-relay> <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.
21:36:37 <m-relay> <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.
21:42:20 <m-relay> <s​packle_xmr:matrix.org> Sorry, bad idea. They'd just use the same membership proof for both attempts.
21:45:50 <m-relay> <e​ndor00:matrix.org> Couldn't it be combined with the txid, in some way? That way, the two competing transactions would invalidate eachother
22:00:11 -xmr-pr- [meta] Rucknium opened issue #897: Monero Research Lab Meeting - Wed 20 September 2023, 17:00 UTC
22:00:11 -xmr-pr- > https://github.com/monero-project/meta/issues/897
22:05:24 <nioc> [meta] Rucknium opened issue #897: Monero Research Lab Meeting - Wed 20 September 2023, 17:00 UTC
22:05:24 <nioc> > https://github.com/monero-project/meta/issues/897
22:42:39 <m-relay> <c​hch3003:monero.social> Is there a big party planned for the 10 years of Monero?
23:03:39 <m-relay> <A​bo Gemaal el-Folani 👑 {𝕭𝕽𝕲}> We live, we love, we lie
23:27:32 <m-relay> <1​23bob123:matrix.org> Hookers and blow?