01:57:56 closed them 06:30:18 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 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 are these spam issues new? previously they would only spam comments 12:40:34 The last round of spam issues was just cleaned. They make issues now, and also comments :( 12:48:16 <1​23bob123:matrix.org> Spamgpt 15:47:57 hey frens. 17:40:21 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 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 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 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 There's no replace by fee 17:49:49 You can't broadcast transaction with higher fee, nodes will not accept it 17:50:18 You can only broadcast two transactions at the same time, and split the network into two halves 17:50:27 Then hope that merchant's tx will not be mined 17:51:33 Of course, if you have a list of major pool nodes, you increase the chances of a successful attack 17:51:48 Because you can then broadcast the second tx directly to mining pools 18:02:38 Why 18:03:11 It's simply not implemented. Regardless of fee the second tx will get rejected as a double-spend attempt 18:09:08 RBF is practical on BTC but I don't see usecase for XMR. 18:09:24 Except maybe if one want to cancel a payment before it confirm?! 18:12:30 It's a trade-off 18:26:49 Thanks sech! 18:46:21 whoa BawdyAnarchist on IRC 18:54:20 Is it possible to swap SIS into BTC? 18:54:56 What kind of token is this? Didn't research before buying it?😂 18:55:36 I didn't buy it) it's an Airdrop 18:55:48 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/iFTuQjCSlXrTlBHHNqTpngNx 18:56:16 So what's the project? SIS 18:56:51 symbiosis.icu 18:59:46 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 At least I'll get something out of it?)Maybe you know some places where the fee is lower? 19:02:26 Look it up yourself dude, or just swap it into 19:09:30 why ban? 19:15:39 for link maybe 19:29:23 I've seen many spambots/spammers playing that kind of "script" 19:31:55 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 Good catch 19:37:46 oic 19:42:03 I've been lurking for a long time. Have on occasion had lengthy interactions in #monero-markets 19:48:09 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 There'd likely be wallets created specifically to execute this attack. I do wonder though how much Dandelion mitigates that 19:48:56 (if at all) 19:49:22 Is Dandelion++ of the nature that a user can basically turn it off if they want? 19:50:53 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 Obviously you're not gonna let someone spending $10k run away without any confs 19:51:51 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 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 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 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 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 Someone could look into whether Monero can implement double spend proofs like BCH 19:56:50 This is the first time I hear about double-spend protection on zero-confs :D 19:58:06 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 IIRC xmr.to operated for years with 0-conf 20:00:12 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 You basically need both to bloom simultaneously to their respective targets 20:01:06 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 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 Which means either a large enough amount of money, or a time-vulnerable payment mechanism somewhere 20:07:16 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 I understand this is mostly theoretical at the moment. 20:08:00 But the success of individual attacks is not based on the number of merchants accepting 0-conf 20:08:13 But it is based on the number of attacks carrid out 20:08:28 More merchants means more opportunity and more targets to spread the attack over 20:09:45 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 A target will (or won't) be vulnerable regardless of the presence of other targets 20:10:48 You don't need more merchants to carry out an attack, the competing transaction could just be a self-spend 20:15:44 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 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 More merchants means more people incentivized to do the same. 20:18:13 You can already do that today, with the existing wallets 20:19:08 (Though working around their automated refreshing might be a bit of a pain without some code changes) 20:20:28 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 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 *2 txns spending the same output 20:23:25 You'd need a wallet that would generate both txns, and connect to specific nodes, deciding which nodes receive which txn 20:23:53 trying to get the double spend to mining pool nodes, and the fake spend to a merchant. 20:28:44 <1​23bob123:matrix.org> Doesnt that break conseus? 20:30:00 Nope. One of the two will eventually be mined, and the other one rejected 20:30:52 Couldn't a node report if it has received/rejected a double spend attempt for a transaction in the mempool? 20:30:52 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 It will print "Transaction with id=... used already spent key images" in the log 20:33:16 but it's on log level 1, and default is 0 20:35:05 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 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 Anyway, look at double spend proofs and zero conf escrows! Monero doesn't do "not invented here syndrome". 20:44:26 Node won't even accept the double-spend tx 20:55:05 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 ZCE looks to use BCH features Monero does not have. 21:06:21 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 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 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 Sorry, bad idea. They'd just use the same membership proof for both attempts. 21:45:50 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 [meta] Rucknium opened issue #897: Monero Research Lab Meeting - Wed 20 September 2023, 17:00 UTC 22:05:24 > https://github.com/monero-project/meta/issues/897 22:42:39 Is there a big party planned for the 10 years of Monero? 23:03:39 We live, we love, we lie 23:27:32 <1​23bob123:matrix.org> Hookers and blow?