17:00:38 meeting time: https://github.com/monero-project/meta/issues/706 17:00:38 1. greetings 17:00:38 hello 17:01:02 Hi 17:01:04 Hello 17:01:45 hello 17:01:59 hi 17:02:08 Hi :) 17:02:55 Hello 17:03:54 2. updates; what has everyone been working on/planning to work on? 17:05:18 I delivered the first working Python implementation of the Gamma Picker algo (part of the Decoy Algorithm) and was able to simulate the same behavior, that I did for the original C++ implementation. There are some visible differences, at least due to differences of the random number generator (Python's `... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a7331e67b6adb21a1a6986e7ede4c8af57381fe0) 17:06:08 C++ version for reference: 17:06:09 https://user-images.githubusercontent.com/63722585/169068204-8e82eb8f-4151-48a9-85d4-c554cc231839.png 17:06:26 for comparison purposes you should be able to write your own PRNG and use it in both impls 17:06:40 Yep. Point. 17:06:53 me: Implemented a robust input selection solver for seraphis, pushed multisig PRs forward a bit, and updated jamtis to support self-spends better (e.g. churn). Next I will finally implement the full enote scanning workflow that I have been really looking forward to. 17:08:01 Working on the statistical model to estimate the effect of minexmr dot com's fee increase. I think I'll go with Vector Autoregression, treating the fee increase as an exogenous shock and fiat/XMR exchange rate and hashing difficulty as endogenous. Any input appreciated, especially from mj-xmr . 17:08:51 Im learning and implement in Python Bulletproofs and CLSAG as it is in the C++ code. I am also continuing scanning the blockchain with the LibSodium library. 17:08:51 I'll chat you after I finalize the decoy (very soon) 17:10:29 finished up patching relatively trivial tor/i2p daemon connectivity bugs (my outgoing tor connections stay alive much longer now and I don't see tx submissions warnings nearly as often), I left the final one on the back-burner for now (see comment in 6938 for what that remaining one is), reviewed/provided guide to rbrunner on completing 8076, and for now moving back over to reviewing 7760 17:11:27 Thanks for that, will start to work on 8076 this evening, let's see I will be able to get in before the branch or not 17:13:09 thanks for the updates 17:13:19 3. discussion, anything to discuss? 17:14:48 aside from compilation errors/that reorg issue moneromoo submitted a patch for, anyone pick up on issues during testnet fork? 17:14:50 Do we want to discuss reducing the 10 block lock (MRL issue #102)? 17:15:22 Rucknium[m]: sure 17:16:20 my perspective is it will be difficult to evaluate whether changing the block limit is a good idea 17:16:46 * moneromooo agrees with that 17:17:21 FWIW, smooth had a strong opinion against lowering it, and is a clever one (and yes, it's argument from authority) 17:17:58 With higher network hash rate though, that argument feels maybe lessened a smidgen. 17:18:35 why does magnitude of hashrate change things? 17:18:46 Law of large numbers. 17:19:12 The more hash rate, the less likely someone to have a huge part of it, and so the less likely to have large reorgs. I think. 17:19:31 I guess with pools, that doesn't apply as much as it should though. 17:19:58 Yeah especially pools like minexmr 17:20:08 yeah prob not a good argument with current pool situation 17:20:23 If there is a network problem/attack, the current stable situation could be disrupted quite a bit. 17:20:45 Also, referencing outputs by pubkey helps the issue with invalidating lots of txes. 17:21:27 we've discussed that before. did we decide to do that? 17:21:32 Just thinking out loud here and revisiting the active attacker scenario in UkoeHB 's MRL issue #95: If someone is spamming lots of transactions, don't they already have a good idea of which recently-referenced ring members are decoys since transactions that reference recent outputs would be referencing the attacker's own outputs? 17:21:34 I don't think so. 17:21:51 doesn't help tx size though, and wouldn't be forward compatible with any deterministic reference solution 17:21:54 How will Seraphis referencing outputs? 17:22:27 Rucknium[m]: yes that's the decoy set poisoning attack 17:23:04 For tx size, we can have hybrid pubkey/index. New outputs by pubkey (non deterministic), older outs by index (deterministic). 17:23:06 tx size presumably is only an issue for network bandwidth, as we would still store only output index on-disk 17:23:15 rbrunner: right now I have deterministic bins. Manually define a set of locations (indices) in the enote set, then deterministically select ring members from around those locations. 17:23:22 UkoeHB Maybe we could create pubkey-IDs which are hashed and/or truncated pubkeys to a certain length and which must also unique as well as the pubkeys themselves 17:23:25 Assuming lots more older ones (ie, > 10 blocks or whatever), tx size doesn't increase much. 17:24:19 Rucknium: yes, but if the attacker gets an honest user's tx that had made into the chain to invalidate, the honest user has a previously successful tx now fail, and then must re-construct that tx with even *more* decoys that everyone knows are decoys 17:24:46 UkoeHB You would get the benefit of reorg protection and hopefully they wouldn't take up too much more space than the (64-bit I think it is) current way of indexing outputs 17:24:57 Though the "how to have deterministic while plugging N non deterministic outs" problem is not obvious, but doesn't seem insurmountable... 17:25:11 moneromooo: for me, deterministic means generating multiple locations from a single seed; it's hard to map a set of indeterminite locations into a deterministic representation 17:26:08 Well, if your deterministic algorithm picks a locatoin that's too recent, then pubkeys are listed there (as many as needed to fill the bin). 17:26:19 If only the bins are deterministic but not the actual outputs selected, then where's the advantage? Any wallet who doesn't conform to that will stick out 17:27:27 endor00 If they didn't conform I feel like it would be hard to create a valid ring sig 17:27:29 And if your implement the wallet such that it remembers which out it picked from that bin in case of a reorg/resubmit, then you might as well have deterministic inputs 17:27:37 jeffro256[m]: the reason I don't think supporting unique onetime addresses can work is it creates problems for 'tx engineering' things like atomic swaps. If you can block a tx-being-constructed from the chain by publishing one of its enotes, that would break any protocol that relies on the tx-being-constructed from being publishable. 17:30:09 merope: the outputs selected are deterministic, the bin locations are not 17:30:47 @Ukoe How would you be able to block? Just from virtue of smaller brute force space ? 17:30:49 Oooh ok, so random bin location but deterministic output within that bin 17:30:55 That seems like it could be tuned 17:31:41 jeffro256[m]: "and which must also unique as well as the pubkeys themselves " If you can't submit a tx because it contains some duplicate thing with another tx in the chain (other than key images). 17:33:35 All these annoying complexities are why I recommended 'floating outputs' last year (which wasn't received well...). 17:35:12 moneromooo: it's hard for me to imagine how it would work, although I'm open to suggestions 17:35:54 UkoeHB Except you can choose your own pubkey which means you could control your own "pubkeyID" cause it would be determinsitically generated from the pubkey. It would add some overhead for sure (checking uniqueness), but a hash is involved, it could be hard for a bad actor to reverse engineer a value to conflict 17:37:40 jeffro256[m]: anyone who is party to an off-chain tx engineering protocol (like atomic swaps) can see all the in-progress txs, so all they need to do is copy-paste the onetime address into a dummy output in another tx (with 0 amount); any duplicate check on onetime addresses will block the engineered tx from submission 17:37:54 I prefer binning though 17:38:24 prefer over what? 17:40:35 UkoeHB: I was thinking somethig like: for (i in 0..N-1) { O=deterministic_pick(); if (age(O) > 10 && tx.outputs[i] != O) return false; return true; } 17:41:00 Then the sender writes a pubkey, not an int, in any tx.outputs[i] which is young enough. 17:41:06 A bit handwavy for sure. 17:41:43 Basically when your deterministic_pick funciton returns something young enough, you allow anything. 17:41:57 referencing by pub key still doesn't fully negate the issue if decoys that are referenced are non-honest users' decoys which get reorged away (presumably whoever is triggering a deep reorg is also spamming to inflict max damage for this too). I think the root issue is still there 17:42:37 jberman[m]: +1 17:42:47 UkoeHB Oh yeah you're right, but what's stopping that from happening currently ? Pubkeys can only be sent to once, correct? Or is it just spent once ? 17:43:30 Pubkeys are not forced unique. 17:43:50 moneromooo: I think that's floating outputs (what we have now). So you'd have a bunch of ring members deterministic, then optionally any number of additional members as 'floating' (not deterministic) pubkey references. 17:43:55 They arguable should be. It was deemed not worth the bother (Extra db, extra lookup). 17:44:17 jeffro256[m]: right now the wallet will only try to spend the highest amount among outputs with the same onetime address 17:44:46 I originally wanted to enforce unique onetime addresses in my seraphis poc, until I realized the issue with off-chain tx engineering stuff. 17:45:31 Does "I think that's floating outputs" imply a flaw with those ? I do not have the background knowledge to map it to the implied thing you refer to. 17:45:35 UkoeHB: That's devious. I legitimately never considered that as an angle. ... new proposal for the RPC to allow checking if a one time key exists on chain so wallets can easily check that way? 17:46:00 moneromooo: not really, it's just an easier way to think about it imo 17:46:00 moneromooo Interesting. I had the misconception from somewhere a long time ago that pubkeys were completely unique but now it makes sense why they would not be. I guess you could "sort-of" patch that problem with relay rules, but its not a very strong guarantee 17:46:21 We have /is_key_image_spent but AFAIK, not /is_key_onchain to check against burning attacks 17:47:34 kayabaNerve: it's not like a wallet will make a duplicate onetime address on purpose (so idk what an RPC endpoint will gain you); you need a custom wallet 17:48:37 My frustration is the only way a wallet can securely receive funds is if it knows the entire wallet history for all of time. An RPC route, against a trusted daemon, would allow it to only sync the relevant tail blocks of its existence and then simply check for each input it receives if it's malicious. 17:48:54 It's not about sending such outputs. It's about extra certainty when receiving funds. 17:50:31 ah I suppose that would be useful (although then you also need to get all enotes with the same onetime address and figure out which one has the highest amount) 17:50:33 As a side note, while I know we have trolls, I really hope our community doesn't devolve into commentary on paid trolls existing unless we have literal evidence of that. It tears the community apart while making us look insane. Another coin's community recently went down that path and it's... hell. 17:51:16 UkoeHB: To optimize, sure, yet I personally care more about dropping the latter inputs as invalid and moving on. 17:51:42 It's a simpler flow and the malicious sender burns funds you consider not received. Same as if they never sent. 17:51:53 that would open another vector for breaking tx engineering protocols 17:52:03 How so? 17:52:25 Send 0.0001 XMR, then send 1 XMR, yet it only considers 0.0001? 17:52:30 yes 17:52:44 The malicious sender is definitively malicious though. It's perfectly fine to say they only sent 0.0001 and walk away accordingly. 17:53:14 With the atomic swap proposal, it'd be a wrong amount lock. Sure, they had an offer for a valid amount lock... but who cares? They're actively malicious. Walk away. 17:53:18 no, the problem is assumptions that are made off-chain before anything is even submitted to the ledger 17:53:30 ... oh 17:53:37 Right, this is still a DoS 17:53:43 ... got it 17:53:45 yep 17:54:09 And that's why we have is_key_image_spent because it's actually cryptographically secure 17:54:30 👍 17:54:52 we are approaching the hour, anyone have other comments/questions to address? we didn't get too far on our 10-block-lock discussion lol 17:56:11 Still a hard problem, but I think we could sort of fix that with a robust zero-conf wallet 17:56:39 how so? 17:56:51 the main issue is funds in the lock can't be spent at all 17:57:10 you could make a tx spending those funds and queue it up I guess 17:57:38 Yeah I think there's a wallet (cant remeber the name) that is working specifically on that problem 17:58:43 Or maybe it was just an idea thrown out there. If your wallet can guess (or you tell it) roughly how much money you're gonna spend and when, it can break it up into appropriate amounts 17:59:18 ah yeah I heard about that project, not sure the status 17:59:30 And on the other side, accepting zero-conf txs as a small merchant in Monero is still pretty dang safe 17:59:40 Actually, there is a roundabout way :D Technically, Townforge is a fork of monero, and you can freely move money between output based and balance based, and when transacting between balance based, you have no lock period :D 17:59:53 I think that's Monerujo with "pocket change". It doesn't help the issues that Haveno and similar services will encounter, however. 17:59:55 OK, it's cheeky because no ring sigs. 18:00:50 (in the balance based section, there are ring sings in hte out based section of course) 18:01:28 moneromooo: If it still has amount privacy, and you only ever fund new balance accounts (so you have a dedicated account to receive, and then you can create new accounts with deposits to send)... that's actually pretty qual 18:01:38 alrighty, that's the end of the hour; thanks for attending everyone [post-meeting discussions: https://libera.monerologs.net/monero-research-lab/20220518#c97345]