00:59:51 Yeah. Monero hash rate renting went exponential 00:59:51 One provider wend from ~30Mh/s wedndesday, to ~300Mh/s this weekend. No idea who is renting, good guys or Qubit assholes... 09:30:00 <1​7lifers:matrix.org> high number = celebrate 11:51:35 hey, does anyone know why this one is not mined after over 5 hours in the mempool? 11:51:37 https://xmrchain.net/tx/d6de63a33a073c1c5cb19315576d4bc1a90a161d9e8dac665036e164fe127516 12:11:32 Probably a double spend 12:13:17 Ah yeah that would explain it 12:13:28 But wouldn't the xmrchain node discard it? 12:14:13 monerod doesn't, Cuprate does :) 12:15:45 If the node receives a block with a tx that double spends a tx in its pool monerod won't drop the tx in the pool 12:16:04 What's the current rough eta before cuprate is production ready for use with my wallets? 12:18:40 Qubic SHOULD have RBF, fite me :C 12:18:43 Hopefully the RPC is ready within a few months, a stable release won't be for a while yet. 12:19:20 *Cuprate 12:19:22 Not qubic 12:19:39 Once we have the RPC interface you can test with wallets 12:20:04 I'm ready to fight even tho idk the implications of RBF 12:20:07 Sorry, I'm still quite tired and was reading through the above on *someone* renting hash rate 😅 12:20:30 Rbf kills the digital cash usecase 12:21:02 Mining on cuprate won't be recommended until we are stable, so would be wasted until then 12:21:03 Eh, it makes 0-conf 'less secure' 12:21:06 It makes them completely insecure 12:21:28 Right now they are secure enough for small in-person payments 12:21:37 Prior, you could simultaneously send two TXs to netsplit the view of the mempool and have a 50% chance of your TX being the one seen by the store (and a distinct 50% chance of being the one mined) 12:21:56 With Rbf it gets way too easy to "double spend" 12:21:57 With RBF, you can guarantee the ordering so long as a block isn't mined before a store recognizes acceptance 12:22:30 (Assuming the store doesn't run several nodes with anonynous IPs and geographic distribution, cross-checking their mempools to try and find any potential double spends) 12:22:56 Oh no, something that has a 25% chance of working by anyone who bothers now has a 90% chance of working 12:23:12 Our insecure idea is even more obviously insecure 12:23:15 The horror 12:23:30 It's a compromise 12:23:44 But we don't have to kill it 12:24:07 0-conf TXs are a 25% off discount at every store which accepts them, fite me :C 12:24:41 Kayaba do you support gun control 12:25:00 *it's even better if you can send the TX to yourself directly to the major pools, solely sending the TX to the store to other nodes. 12:25:06 We don't hand everyone a gun either 12:25:20 You can get the existing odds to around 90% with a sufficient map of the network. 12:25:31 If you target mining nodes with one tx and other nodes with the other you could probably pull this off with a better probability 12:25:37 All RBF does is remove the requirement of such a decent map. 12:25:53 You can also 3d print your own guns but most people won't bother due to the effort involved 12:26:24 Doesn't mean we should openly sell the parts to everyone because "you can also just print them" 12:26:25 monerobull: I don't think I'd support banning giving guns out on the street if there's a store nearby you can just walk into and get a gun. The existence of a simple door doesn't make a difference IRL. 12:27:12 Make 0-conf secure or don't use insecure technology 12:27:15 People did literally just fraud when they heard of the chase "glitch", because they could 12:27:45 If it required filling out a form and a bunch of extra effort, barely anyone would have done that 12:28:01 But if it's just two buttons to do the fraud, enough people will be stupid enough to try it 12:28:08 You realize my concern is with sellers, right? 12:28:38 Promoting zero-conf is promoting 25-90% off by anyone who cares enough 12:29:33 Zero conf is useful for in-person payments and gambling on blockhashes, not much else 12:29:51 But for the in-person payments is very useful 12:30:13 We shouldn't advertise, promote, or enable insecure bs IMO 12:30:17 The likelihood that someone will try and rip you off is super low 12:30:20 RBF is useful 12:30:30 RBF isn't insecure 12:30:40 So are zero conf payments 12:30:52 Those are insecure though 12:31:12 You don't need 100% security on zero conf payments. 12:31:18 kayabanerve be like: 12:31:19 "This is completely insecure and utter shit... Here's why we should think about it for Monero!" 12:31:21 Go build a PCN 12:31:26 kayabanerve be like: 12:32:15 "This is completely insecure and utter shit... Here's why we should think about it for Monero..." 12:32:15 But you absolutely need zero conf to enable smooth in person payments 12:32:15 It's a compromise 12:32:15 Or a PC 12:32:15 Monero also compromises on scaling to have better privacy 12:32:15 this 12:32:15 Or confirmations with latency of less than 10s 12:32:15 VISA is great 12:32:20 Here we compromise on zero conf security to make payments instant 12:32:31 With reasonable efforts involved to abuse 12:32:44 SyntheticBird: if re: TEEs, those would've been a layer, not a premise. 12:33:03 The proper solution is a PC mb 12:33:11 A what 12:33:25 I wasn't referring to TEE but thx anw 12:33:26 Payment channel 12:33:33 Ah 12:33:37 aka VISA 12:34:11 Oh, then what else were you referring to? 12:34:23 But what about one-off payments? What benefits would Rbf actually give us? Seems like more downsides than upsides 12:34:40 well this rbf discussion 12:34:53 PCN mb 12:35:02 also R1CS proposal 12:35:19 i think you said you really disliked it yet made a detailed and appreciated explanations on mrl github 12:35:21 SB: But I'm saying 0-conf is insecure so we shouldn't think about it 12:35:45 oh my bad im confused 12:36:26 Payment channels? 12:36:27 Or what does the N add 12:36:43 network 12:36:48 payment channel network 12:36:49 Yeah SB, it was TEEs and I said insecure but should consider lol 12:37:14 mb: Network. You don't need a direct connection and can make one-off payments given any indirect route. 12:37:23 Why do those require rbf? To do bidding wars in case there is contestation? 12:37:38 They don't? 12:37:54 Well, they might, see how much of a fuck up LN has been 12:38:01 But I'm separately calling for RBF 12:38:04 I just like RBF 12:38:11 Fee bumping is good 12:38:13 I specifically asked for the benefits of Rbf ?:3 12:38:32 I think I have a dedicated issue to discuss 'anyone-can-bump' fees... 12:38:40 Fee bumping. 12:38:53 I mean I kinda get it 12:38:56 I support my R1CS proposal long-term, and I support PCN-support long-term SB. 12:39:07 Sucks when there is a backlog and your tx is stuck for an entire day 12:39:17 isn't this in complete opposition with the fee discretization proposal 12:39:24 But I appreciate the relative security of zero conf as it is right now 12:39:27 We just need competent designs to agree on, the bandwidth for it, and the proper timeline. 12:39:41 No, even with discretization, there'd be prioritization. 12:40:16 When I receive a payment, I can tell the other person "got it" as soon as I see it in my wallet 12:40:24 I don't want to worst case wait 20 minutes for the first conf 12:40:56 We can give each TX a canonical, in-consensus weight, as we currently do (but don't technically need to make TXs) 12:40:57 And then require the prioritization value be from 0 .. 32. 12:40:59 That's the exponent such that the fee paid is 2**prioritization * weight. 12:41:36 That also inherently bans zero-fee TXs, which is an interesting anecdote. 12:41:45 You want fee bumping for serai right 12:42:03 Bcs it's more structured, I understand that 12:42:18 Uhhhh 12:42:32 I mean, I want in general. 12:42:44 I'm not on a crusade to impl it with the HF. 12:43:04 My 'pushing' for it is just saying "RBF good" anytime it comes up 12:43:13 But yeah, it'd notably help multisig UX and Serai 12:43:32 But only if fee bumping is non-interactive 12:43:40 RBF doesn't enable non-interactive fee bumping 12:44:16 Non interactive meaning everyone can bump it? 12:44:41 https://github.com/monero-project/research-lab/issues/128 12:45:22 Yeah 12:45:58 Interesting 12:46:42 And you are saying PCN would "solve" the "one-off in-person" usecase 12:46:57 LN has been such a massive failure, I don't know about that 12:49:13 LN is like the first to be deployed and practically only PCN 12:49:25 it was advertised as experimental 12:49:41 yet fanatics started using it like this was production ready 12:49:49 PCN aren't bad 12:50:10 They also didn't deploy it on Ethereum 12:50:11 there are better designs than LN 12:50:15 They deployed it on Bitcoin 12:50:26 My PCN issue proposes a hard fork to support a PCN 12:50:54 and i fully support it, when are taking the weapons 12:50:56 Not cramming one into what exists + a general purpose soft fork that's presumed sufficient but also doesn't go all the way as it's 'general purpose' 12:51:07 I don't quite propose enshrining the PCN? 12:51:41 But see how Bitcoin hadn't adopted the covenant-esque solution named after Lightning. Bitcoin devs aren't adding whatever Lightning needs to be its best self. 12:51:50 And that's fair, keeping Bitcoin neutral and all 12:52:07 But my PCN issue did propose explicitly adding full support for a generally agreed upon design 12:52:35 So hopefully, we can achieve better results, especially with years of existing theory to build on 12:54:27 its not like rbf would have to be mandatory. You could, as a merchant, require 1 conf for txs that have rbf enabled 12:55:03 Also, the more I gaslight everyone into believing my solution is correct, the more I get everyone to be quiet about solutions I arbitrarily dislike 12:55:32 mb: You support 0-conf. Is this related to your support of requiring KYC to access Wikipedia? 12:55:45 /s :p 12:56:49 Like obviously, I'm making the point I'm not perfect and in charge lol. There's a reason Monero doesn't have RBF today and that fee bumping issue is likely a better overall solution for my issues (and doesn't conflict with 0-conf as it requires a matching output set). 12:56:51 It also isn't that important to me as I haven't done anything to promote that issue in months lol 12:56:53 So take everything here with a grain of salt 12:57:07 But even if the sole benefit of RBF is it stops people from using 0-conf, I support it, heyoooo 12:58:11 someone on reddit said i am against auditing code because i told them its silly to spend millions on auditing haveno (because the cryptography is done by wallet2 anyways) 12:58:27 ofrnxmr @ofrnxmr:xmr.mx: TX uniformity requires all TXs have RBF or none :/ 12:59:06 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/MwdcpliGxCUrPdNdmXaBHdtR 12:59:08 this made me so mad >:( 12:59:23 nOtEd fReN 12:59:23 But in ringct, txs arent uniform 😂. Also, we dont have uniform fees 12:59:42 Also, these designs do complicate the mempool. If we have fee bumping, we have to only accept non-conflicting TXs into the mempool (as current policy) and then distinctly denote TXs which bump the fees. That way, if a fee bumping TX conflicts with another fee bumping TX, one gets mined and for the other, we revert back to its non-bumped version. 13:00:00 We also have to cover the edge case we receive the fee bump TX before the base TX, and code logic to re-define the base TX. 13:00:04 Would be nice if we could reject txs that arent following the fee tiers 13:00:32 monerobull: You should personally rewrite Haveno to use monero-wallet. 13:01:36 Tbf, the Bisq-forked swap code is probably worth an audit. I've reported a bug before. 13:01:48 kayaba is advocating for having non-devs vibecode critical monero infrastructure. noted fren 13:01:56 Like, lack of cryptographic bugs due to using wallet2 != lack of bugs. 13:02:05 yeah i know 13:02:55 but like, funds should be always recoverable as long as the basic wallet operations work correctly 13:04:45 What if it has memory corruption due to relying on code written in unsafe languages? 13:05:13 mb, you claim you promote a safe society, and yet you use apps written in memory-unsafe languages? 13:05:18 Would you say you're a hypocrite all of the time or just most of it? 13:05:30 :pp 13:06:22 I'll stop joking around so much. *someone*, yes, should do that fee bumping thing as it's a good idea *except* for the cost to the membership proofs (non-issue with CLSAG, issue with FCMPs). 13:07:15 Eh. No. It should be fine because we have membership/SAL separation. We can still have a batch membership proof so long as we have independent SAL proofs... 13:11:33 Best of luck, I remain skeptical of rbf but I can see it's few merits 13:20:04 The fee bumping proposal isn't RBF in the traditional sense and doesn't conflict with zero-conf if implemented correctly. 16:49:04 so looking for some feedback with monerosim. As i've been developing this, i've come to appreciate that ethshadow really focused on the networking / consensus aspect of ethereum... simulating and testing that. It wasn't really concerned with tx propagation etc. It was mainly node synchronizing, network communications, etc. 16:49:05 So I plan monerosim to be more than that. Currently i'm developing it with an "agent" framework. So, for a given agent (i call them user agents), it can have various attributes and processes. So a user agent will have a node, a wallet, and a python script that governs their behavior (send transactions at this interval, etc). 16:49:07 there are other agents that are just python scripts. For instance, to simulate mining, there is a block controller agent that randomly selects (based on weights that mimic mining hashrate) a mining enabled user agent to be the winner of a given 2 minutes (I haven't bothered with varying the block production to mimic the temporal randomness of block finding). This kind of agent i' m referring to as controller agents, or coordinators. Haven't really decided. 16:49:11 with this framework, i hope to eventually expand other controller agents. we can imagine a marketplace agent, which is a python script that gathers monero addresses from the user agents. User agents with the attribute of being a member of marketplace1 can then poll the marketplace agent to get a monero address to send monero to. (this could also be done with just a list of monero addresses populated at the start, instead of being dynamic). 16:49:15 i'm also debating integrating scenario / controller scripts. The current agent-based makes it sorta headless. Scenarios can still be orchestrated by agent start times (e.g.,, have a stable network running for 3 hours, then have a bunch of agents start that do 100-fold rate of transaction sending). With a scenario script, we could have a python script that coordinates these behavio rs (e.g., at timepoint x, select n user agents and increase tx frequency x fold). 16:49:19 any thoughts? 17:36:55 are you running the orig. monerod wrapped in a python skript ? 17:39:20 no, the monerod is called directly. shadow doesn't do well with child processes 17:42:50 whats the interface called on a kernel level again? 17:47:16 im not sure what you mean. shadow intercepts system calls 17:55:55 well, congrats. Lots of possibilities there... I watched the ethshadow vid and the # of nodes was limited to ~200 iirc ? 17:55:55 My idea was from the beginning to model Eigentrust. Then use trust levels to select validators like in Stellar consensus (!=POS). We are in fantasy land right now. TBC 22:59:44 https://takebackourtech.org/moneros-51-attack-centralization-vs-decentralization/ Rucknium