09:46:23 has anyone tried calling this library with ruby ffi? https://github.com/monero-ecosystem/monero-cpp I am specifically interested in the verify message function: https://moneroecosystem.org/monero-cpp/classmonero_1_1monero__wallet__full.html#a9277185e29b8fa29b860d54b5eda2b2b Do I need to instantiate a wallet to use it? having a wallet seems to be unrelated to verifying a message. Is there a different library that might be less "hairy" to 09:46:23 call from ruby? :D 09:53:01 The wallet has the secret keys to verify the message. 09:53:25 You could extract the crypto code though. 09:54:52 moneromooo: okay. i thought i can sign a message with my primary address then give this stuff to someone else and he can verify the message together with my address and check that i really control the primary address 09:55:09 didnt know the verifier needs a secret 10:02:03 The verifier does not need a secret. Only the signer does. So you're right, even easier to extract. 10:02:28 Sorry, didn't think before writing :) 10:07:56 "The verifier does not need a..." <- so you mean I should grab the code of the function and recompile it and than call it with ruby ffi? or even rewrite it in ruby? I was just about to try to directly work with the compiled monero cpp lib. and just try to call this function somehow with ruby ffi haha. I am not super experienced with cpp and this is the first time i will be using ffi so i am asking haha. maybe you guys have a 10:07:56 good approach. 10:08:55 i think this verifying a message is not really tied to a wallet so I am a bit confused by all of this. I dont understand why this is tied to the wallet rpc/ wallet.h 10:10:23 same with checkSpendProof which will be the next in line lol 10:15:38 I do not know about calling from Ruby, I'm just saying that the code can be extracted if you want a small amount of code. 10:23:30 "I do not know about calling from..." <- hm...cool. and by extracting you mean: copy the code of the function and make my own small cpp program, right? I just saw that functions i am interested in depend on this m_w2 thingy and it seems to come from opening/ creating a wallet https://github.com/monero-ecosystem/monero-cpp/blob/4662d35bedc3875545ac7e5a93d5bebd171aa1be/src/wallet/monero_wallet_full.cpp#L1029 so it seems like 10:23:30 everything is tied to having a wallet even though there is no "real need" for it. or am I am missing something? i am not trying to criticize i just wanna understand. I want to write a plugin for discourse( which is written in ruby) which allows people to login by signing a message with their wallet. And also people should be able to pay for stuff and then supply transaction proof so they can get access to it. (like this: 10:23:30 https://www.getmonero.org/resources/user-guides/prove-payment.html )So i need to verify transaction proof and signed messages on the server with ruby. I am trying to figure out the easiest and quickest way to do this. 10:38:16 s/checkSpendProof/checktxproof/ 10:39:41 Yes, that's what I meant. The wallet is basically the Monero user. 10:40:25 We could have added a new program to verify a signature too in this case. You could even do that and PR it. 10:45:57 "We could have added a new..." <- maybe i should do that. The problem is that I need to feed my stomach haha. So I cant afford to get side tracked too much. The low risk way to solve my problem is to host the wallet rpc next to my discourse instance and make rpc calls to it. This is kind of hacky and also has a big burden of hosting this separate long running process. If I had a small library that did just these two things 10:45:57 that i could embed in the ruby code it would be so much nicer and easier. I will think about it more and make some experiments haha. thanks for your help! 👍️😀 16:04:46 Reminder that there is a meeting scheduled here in just under an hour 16:04:46 https://github.com/monero-project/meta/issues/614 16:05:29 I can only be present intermittently. Hopefully someone can volunteer to moderate 16:23:28 Wtf is utc 16:23:46 a timezone :D 16:23:57 Weird one 16:24:00 nah 16:24:09 it's the standard 16:24:23 https://en.wikipedia.org/wiki/Coordinated_Universal_Time 16:24:29 Universal Coordinated Time, +4HRS EST 16:24:38 The what is UST for 16:24:52 Wait 16:25:06 I think I meant EST 16:25:27 I'm confused 16:26:21 So how does the meeting work, since it's also happening in liberachat the same time 16:26:59 I am talking from liberachat :) 16:27:12 Ah ok 16:28:22 What do you guys think of p2pool? I think it's awesome but it's kinda impossible for me to get shares 16:29:23 I mined with 4000 h/s for 2 days straight and found like 2 shares but they somehow didn't get credited 16:30:37 shares get "credited" according to how many shares you have in the PPLNS when a Monero block is found by p2pool miners, though if you have more questions about P2Pool there are dedicated channels for that 16:33:16 Ok different topic, i think it was Justin, who seemed to be for the removal of normal adresses and only keep subadresses. Does anyone know how that would work? 16:35:04 > <@carrington:monero.social> Reminder that there is a meeting scheduled here in just under an hour 16:35:04 > 16:35:04 > https://github.com/monero-project/meta/issues/614 16:35:04 i am really hoping they dont remove integrated addresses. Really need them for my project. Integrated addresses are really good for non custodial services. We should keep them. 16:36:49 FixedFloat uses integrated addresses and I use FixedFloat often. :( 16:52:01 Is MorphToken legit? 16:53:07 seems like a question for #monero or #monero-community 16:53:13 whoops! 16:53:21 "Ok different topic, i think it..." <- I haven't really pushed for the removal of main addresses no 16:53:31 i thought i was in #monero 🤦‍♀️ 16:53:37 :) 16:54:12 I think that was only in connection with Seraphis, no? 16:54:32 Where many things will change anyway at the same time 16:56:46 I haven't thought about that but maybe I would support that 16:58:12 IIRC the reason mining does not work with a subaddress is that it would have required a fair amount of extra changes on top of the subaddress patch. 16:59:40 https://github.com/monero-project/monero/pull/3839 17:00:06 I want to build a website where people can sell digital products for monero in a noncustodial way. How could this be done without integrated addresses that isnt a complete mess? 17:02:54 "I haven't really pushed for..." <- sorry, it was seth 17:03:06 meeting? 17:03:08 Meeting time? 17:03:13 Meeting time? 17:03:30 rbrunner I do believe so. 17:05:41 Hello people. Someone wanted a meeting. So since they do not seem to be around yet, anyone wants to talk about dev related things ? 17:05:45 "I can only be present intermitte..." <- ^ Does someone want to volunteer to moderate? 17:05:50 Who is running? :) 17:05:53 Well, lets start with point one on the agenda. Thanks to everyone for coming. Who would like to tell us about BP+? 17:06:14 It's ready to go in, code wise. Can't recall whether it's been audited now. 17:06:18 BP+ is basically ready, it's missing an approval on Github. Wownero has been running it for a couple months. 17:06:31 It is audited. 17:06:40 Seems to have been audited twice, anyone audited the audits? 17:06:41 There was no change in ring size for BP+ impl? 17:06:55 BP+ does not care about rings. 17:06:55 Ring size is separate. 17:07:53 I guess that missing aproval on GitHub is a formularity then? 17:07:54 Could someone quickly summarize what BP+ adds to BPs? 17:08:15 It doesn't add, it removes :D 17:08:19 (bytes) 17:08:23 there are some source code conflicts that need to be resolved 17:08:27 BP+ are simply more efficient than BP 17:08:42 For the BP patch, vtnerd ? 17:08:51 yeah, thats what Github says 17:09:03 OK, I'll fix then soon then. Thanks. 17:09:28 Sounds great. Anything else to add to the topic or do we move on to the next one? 17:10:13 One minor BP+ thing 17:10:44 Any progress on using the BP+ storage for a txid - type/soze string or not yet? 17:11:07 s/soze/size 17:11:34 I did work on that recently ish, but it kinda sucked, only the sender can retrieve the data without leaking the index of the real spend. 17:11:37 As something like an tx_extra alternative? 17:12:32 It was better for.... forgot its name... the pre-seraphis ring algorithm from sarang, where you send 32 bytes without leakage. But I've not done the code for it yet. And might not since we might use seraphis instead. 17:12:35 moneromooo: Ah okay thanks 17:12:58 Triptych :) 17:13:03 Right :D 17:13:30 Does seraphis allow such stashage without leakage btw ? 17:13:58 I think only Koe, Aaron, or Aram could answer that right now 17:16:22 Moving on to 3? Fee changes 17:16:29 Alright, the next topic is about changes to transaction fees. Ive read into it a little and it doesnt seem to be of the highest priority right now since it seems to only be important should there be a drastic increase to the amount of daily transactions but it should still be looked at. 17:16:59 It's ready AFAIK. ukoeHB reviewed it. 17:17:06 No it definitely is high priority 17:17:16 In my view, its priority has become more urgent due to the tx volume anomaly 17:17:32 There is a consensus change here. If current trends continue we could reach the penalty zone in 12 - 18 months 17:18:21 The consensus portion needs tp go into the next HF 17:18:24 Hmmm ... would that mean more than simply growing blocks? 17:18:34 (Reaching the penalty zone) 17:18:40 ArticMine you need an agreement on the ringsize to finalize this right? 17:19:38 The current formulation allows for a ring size up to 26 17:20:01 Ah so no blocker there then re ringsize for now 17:20:23 So with the discussion between 15 - 25 there is no blocker 17:21:32 Anything else on the topic? Maybe someone can tell us how or if this will impact regular users at all? 17:22:19 Marginally higher base fees, greater fee downward pressure at large volumes 17:22:22 They'll pay peanuts in fees instead of fifts of peanuts. 17:22:41 Well, would this be the right time to settle on a number already? If not, what is still missing for doing so? 17:23:08 rbrunner: If this is re ringsize wait for 5 pls 17:23:21 thanks 17:23:23 Oh, ok, separate topic. Sorry. 17:23:39 :) 17:23:57 We still got a lot of headroom so this shouldnt be a problem. Good job ArticMine. 17:24:13 Thanks 17:24:36 Moving on to the next topic: Decoy selection algorithm changes 17:24:53 Indeed, the pdf was very detailed/precise. 17:25:07 I don't know if jberman is here right now. Anyway, "my portion" of improvements to the decoy selection algorithm have been much discussed recently, to say the least. I have a CCS proposal in the "idea" stage. 17:25:07 Thorough it the word I was looking for :D 17:25:40 Yeah! More code, less, er, other things. 17:25:57 Patching integer truncation is still sitting in PR 7798 17:25:57 * moneromooo approves of this planned work 17:26:02 The following is new public information. Previously I had said publicly that an "applied statistician" was reviewing my HackerOne submission. 17:26:18 Now I can say that : 17:26:18 Syksy, who holds a Ph.D. in biostatistics, is in the process of examining the HackerOne submission. 17:26:28 Syksy links his username to his real identity, so interested individuals can do their own due diligence if they prefer. moneromooo could comment as well. 17:26:31 Are there any others besides 7798 that are waiting for merge 17:27:01 rucknium, some people are really concerned since you want to keep some part of your work undisclosed to the public. Can you explain what exactly that would be? 17:27:21 I don't think we should even discuss that at the moment at all. 17:27:43 sgp_1 nope, nothing else at the moment in PR stage 17:27:49 sgp_1: any other what? 17:27:50 Agreed 17:28:11 monerobull[m]: I'm not sure that at the end of the day, that will be the case. I think I shouldn't disclose everything right now, as my CCS proposal is being discussed and possibly funded. But later, maybe, probably, most things will be released. It's out of my hands, anyway 17:28:15 I don't think we should even discuss that at the moment at all <--- agree 17:28:23 In this dev meeting, I'm more interested in making sure all the desired decoy updates for this round are in and ready to go 17:28:33 I also recommended in 7798 to reduce the "recent spend window" where the algo selects an output from the recent window if gamma suggests an output < lock time 17:29:19 I recommended reducing it from 50 blocks to 10, because 50 was selected assuming integer truncation would not be patched, and so 50 selected a wider portion of the very recent blocks 17:29:32 re: fee PR, I’d like someone else to review as well in case I missed some detail. vtnerd selsta maybe? 17:29:44 You mean the code in 7798 does that? Not sure how to understand "recommended" 17:29:45 it's too complicated for me 17:29:57 I doubt I can review much there but I can take a look 17:29:58 jberman: Seems reasonable, and luckily this is an edge case 17:30:19 Maybe one of the guys who show up saying ‘let me do something’ could review? 17:30:23 rbrunner The code in 7798 doesn't do that, it's sech1' PR . I'll create a new PR 17:30:26 Unrelated: is anyone keeping notes or should i do that? 17:30:40 Do we stil have a recent spend window ? I thought that was gone with the switch to gamma... 17:30:41 UkoeHB - already put the fee PR review in my todo list ... 17:30:44 monerobull[m]: usually we post all the logs in the issue 17:30:49 Great thanks vtnerd 17:31:22 monerobull[m]: It would be helpful for you to later post the logs and a neutral summary on GitHub and forum.monero.space if you're offering :) 17:31:47 the recent spend window is when gamma "selects" blocks 0-10 17:31:57 Right 17:32:07 Wait no sorry 17:32:09 Oh a new thing. OK, sorry, don;'t mind me. 17:32:11 tossing that result ruins the intended distribution 17:32:14 sgp_1: Sorry, I dont have a clue how i would do that, best i can do is a reddit post with a summery on each topic ^^ 17:32:30 Someone else can get it no worries 17:33:00 vtnerd as in, if the gamma selects an output 5 blocks ago, and then tosses, it ruins the intended distribution youre' saying? 17:33:51 correct, that was the change I saw for monero-lws, no? to _not_ throwaway selections in the locked phase 17:34:14 Yep. Didn't see moo's question 17:35:04 moo was just unclear what recent spend window meant, because it sounded like an older algorithm used a few years back 17:35:04 Idea is to re-select an output at random from the "recent spend window" 17:35:42 Will submit a PR to drop that window from blocks 10-60 (what it is now), to blocks 10-20 17:36:20 And this only impacts txs with a lock_time or all txs? 17:36:31 All txs 17:37:18 Next up on that list is "binning" 17:37:35 I assume you're choosing 10 because it's a better fit? Can you include data for that in the PR you make? 17:39:23 7798 shows the impact of what it would look like on the distribution for early blocks on a chart. I don't exactly know what framework to use to actually determine "better fit", since there is no guaranteed way to know as far as we know 17:40:48 > what it would look like 17:40:48 the integer truncation I assume fix 17:40:56 fix I assume* 17:41:26 shows what fixing integer truncation + modifying the recent spend window look like, with different windows 17:41:47 e.g. https://user-images.githubusercontent.com/26468430/132962516-f71800a4-0cfa-4b91-bc1e-28ecbceac330.png 17:42:09 re: binning, jberman were you hoping to push for binning in the upcoming hard fork? 17:42:27 I think that depends on unlock time 17:42:48 it seems there is a lot of support for deprecating unlock times 17:43:25 is it reasonable to push for deprecation of a feature that soon? 17:43:28 I would like to have a statistician look at binning before it is implemented in production code. 17:43:31 If everyone agrees we can discuss unlock times right now and ringsizes after. 17:43:32 Maybe another question would be, do we want to introduce significant new changes/PRs for the next hard fork? 17:43:54 Or take what we have and wrap it up? 17:43:54 I mean, I have "looked at" it, but not really examined it with much scrutiny. 17:44:36 I'm definitely somewhat worried about trying to squeeze binning in 17:44:44 UkoeHB my thinking is no, would rather not hold up the other changes in the pipeline, and take time to get other things done right 17:45:06 jberman: I just eyeballed it, but 10 or 15 seem the most sensible so I say it looks good 17:45:09 Code-wise, binning would basically starting from zero, right? 17:45:26 Binning really ought to go in with seraphis/triptych/whatever. 17:46:07 moneromooo: I generally agree with this yes 17:46:10 That makes the most sense to me. 17:46:58 What I was trying to show with 86 is that binning as a fallback for any inconsistencies in the gamma/other timing related analysis would still be sensible to consider with ring sizes close to today's/slightly higher 17:47:03 MRL issue 86 17:47:56 I suspect it's pretty easy to prove that a slight increase of the ring + some binning does not degrade situation wrt. now 17:48:08 (and of course is very likely to improve it) 17:48:29 If binning does what it says it does, then it seems to me that it would reduce the statistical attack surface of ring signatures. 17:48:48 I am not certain that it does what it says since I haven't examined it closely. 17:49:53 Actually I was thinking of binning including parametric ring description. Binning alone is wallet only so could go in. 17:50:17 Though it'd likely mean other wallets would not follow suit, or with a delay, giving isthmus more puddles. 17:50:25 It appears to me we have 2 potential options right now: 1) skip binning, or 2) do very simple binning to get the easy win(s). Is that fair, and is 2 a realistic goal for a very short time period? 17:50:47 I think 2 is realistic for a very short time period, yes 17:51:02 But moo is right it has the issue of more puddles 17:51:13 Who has vetted binning? 17:51:19 Yeah with small rings, binning makes sense to be wallet-side. 17:51:30 Nobody, since there's no proposed algorithm yet. 17:51:37 You'd probably only get 2-3 ring members per bin 17:51:40 Isn't it directly from Moser et al. (2018)? Or have more papers discussed it? 17:52:19 moneromooo: Then (2) above seems infeasible. 17:52:24 I feel a little lost on tracking the progress of binning, so a clear summary of the situation and desired change would help me 17:52:36 not sure everyone has same definition of "very simple binning" in mind 17:52:59 Rucknium[m]: these guys also basically advocate for binning https://petsymposium.org/2021/files/papers/issue3/popets-2021-0047.pdf 17:53:00 The question I have with binning is number of bins and number of ring ring member per ring 17:53:17 I'll write up a PoC for "very simple binning" in the wallet, and that can be vetted/reviewed 17:53:30 per bin 17:53:30 Thanks jberman 17:53:35 Okay cool, maybe it's best to wait for that 17:53:39 thanks 17:53:44 UkoeHB: Yeah I saw that paper. Haven't gone line-by-line though. 17:54:10 Their 'partitioning' concept is essentially binning. 17:54:19 One funny thing is that if Alice splits an output (to herself), someone might use both of these in a ring since they're contiguous. 17:54:43 That might be good. Not sure... 17:54:50 Which makes me suspicious of their work since they don't cite it as specifically coming from Moser et al. (2018). Trying to hide that it isn't too novel? 17:55:12 (assuming binning picks contiguous outputs and not outputs in the same general area). 17:55:16 I wasn't thinking of selecting contiguous outputs 17:55:20 I mean, that's a research ethics issue 17:55:32 rucknium[m]: There have probably been dozens of papers over the years that recommend binning of some form 17:55:50 sgp_[m]: Send them my way then 17:56:06 Waiting for jbermans writeup sounds good, do we move on to the next point on the list? Its the porposed ringsize increase. Im not sure how urgent this is, till when do we need to decide this? 17:56:40 Partitioning is like 'one big bin', while Moser's binning is like 'several bins from the gamma'. Moser's binning is technically 'mimicking + partitioning' in that paper (which they advocate for). 17:56:40 I think unless someone has a strong argument otherwise, we go with ringsize 16 17:57:09 lol 17:57:22 There's roughly strong support for anywhere 15-19 17:57:33 And knaccc made the best argument for 16 in particular imo 17:57:38 This is a hard fork. My though here is can we accommodate binning with the choice of ring size 17:58:04 Ringsize 16 because it would be compatible with the tryptich alternative, right? 17:58:21 monerobull[m]: No it would significantly change then 17:58:23 Binning not dependent on ring size, in theory could just have remainder in a separate smaller bin 17:58:26 monerobull[m]: triptych/etc/ would have ring size 64-256 17:58:51 But probably would be nicer to have equal sized bins 17:59:06 for example 8 bins 2 ring members per bin 16 or 3 members per bin 24 17:59:28 what is the best argument for 16? missed that 17:59:34 I think 16 is good, less than 50% increase in per-ring-member cost. 17:59:56 8 bins 2 member per bin 18:00:14 also using a per of 2 for the number of bins 18:00:20 power 18:00:30 binaryFate: knaccc shared relatively favorable churning characteristics for that number in particular. Besides that, it's similar to 15-17, so it's the only number that really stands out 18:00:44 the next I would consider is 24 8 bins 3 members per bin 18:00:59 * monerobull[m] uploaded an image: (17KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/uIOghXobQrJjHxVUgfrSStqC/image.png > 18:02:00 Ok I always found this psychologic "1 million" target arbitrary. But nothing against it anyway. 18:02:17 Slightly sad we depart from primes :) 18:02:41 ArticMine: I think this is fair to consider with the binning discussion once we can review the overview. I'm not against this if there is a substantial gain in privacy 18:03:03 binaryFate: I agree it's arbitrary 18:03:41 ArticMine's reason is a good one, we don't know how/if we put binning in place before next-gen signature schemes, but with 16 we'd be more flexible 18:03:51 wrt number of bin members and bins, Moser did some solid analysis on that front. Need to review and probably research further to arrive at a solid decision. But going with ring size 16, and 2 members per bin, you get the benefit of binning, and still maintain the highest degree of the current implementation. So I think it's a sensible incremental 18:03:52 approach 18:04:50 7 "bins" would be gamma selected, basically, as opposed to the current 10 18:05:07 vtnerd, are you still skeptical about binning? Do you see the anonymity in practice dropping from today's 11 to 8 tomorrow (if we went with 8bin by 2 output)? 18:06:19 Yes which I why I would consider 24 as the next alternative. with the option of 12 bins 2 elements per bin or 8 bins with 3 elements per bin 18:07:04 It sounds like everyone is onboard with ringsize 16, not sure what happens now but I assume we move on to "removing unlock time". There is currently no real use for it and out of the last million blocks less than 200 transactions utelized this feature, most of which were falsly configured anyways. 18:07:41 eh I don't know, I keep changing my mind about binning 18:08:25 did MRL issue 86 have any impact on your thoughts, or was that all a wash :) 18:08:40 theres a point where binning is clearly recuding/revealing time windows, otoh it helps when the attacker definitely knows a time window 18:09:57 the argument that it's a backup if the gamma is missing outputs doesn't have much strength you think? 18:10:17 so from 11->8 reduces possible spend timeframes, but still might be a win. its just hard to quantify 18:10:26 vtnerd_: So, binning may not strictly improve privacy under all threat models? Is that what you are saying? It may reduce privacy for some threat models? 18:11:13 Yeah binning is strictly better for some and strictly worse for others, so it's a balancing act 18:11:15 I depends on how well one trusts the the gamma 18:11:50 It definitely could reduce privacy in some ways, if the gamma was perfect, and if there is no timing footprint, then you'd want the highest number of gamma selected outputs 18:12:22 ArticMine: It seems there are varying opinions about how well to trust the gamma distribution. hmmm 18:12:57 Rucknium[m]: Im not certain, because I would have to spend more sketching out a potential tracing tool 18:13:04 "there is no timing footprint" ... There seems to be some sort of sleep-wake cycle in the data. Not surprising, I suppose. 18:13:24 vtnerd_: Seems like binning has not been fully vetted 18:13:25 Rucknium[m]: both ArticMine and I (and few others) are reviewing your submission, so I'd let related discussion for later once feedback is gathered and this discussion can be more public 18:13:27 jberman: It's fair to assume there could be a timing footprint however in some cases, and that taking the gamma loss is still a net + overall 18:13:50 taken to the extreme, if you've got only 2 bins, this effectively tells the attacker that the real output was received within 2 time windows 18:14:08 binaryFate: Understood. 18:14:09 It seems to me not everyone has the same definition of binning, or that we mix binning with current ring size with binning with increased ring size. Not sure it's very productive in that context. 18:14:12 We could not compromise at all and choose 11 bins, 2 outputs per bin :p 18:14:30 Then ring 22 18:14:56 Seems wasteful but hey no hard decisions 18:14:58 otoh, I don't know how valuable that is in tracing 18:15:01 This uncertainty is why I originally did not propose binning for small ring sizes. If the ring size greatly increases, then you can have _both_ an incremental gain in time windows, _and_ start mitigating known-timing analysis. 18:15:04 or increase the gamma to 12v with ring 24 18:15:38 Personally I'd wait to see jberman write up to elaborate more, so at least we have a basis for more structured discussion 18:16:01 (y) 18:16:14 I think we're all roughly on the same page of understanding 18:17:25 jberman: MRL 86 didn't change my thinking about binning specifically, but helped highlight 2 difficulties in the distribution selection 18:17:28 how would binning affect verification time? 18:18:16 A simple wallet-only approach wouldn't affect it at all 18:19:01 oh no sorry, no jberman it did highlight why binning would be useful 18:19:51 it just didn't change that there may be a downside 18:20:12 Makes sense :) 18:20:29 I assume we now move on to "removing unlock time". There is currently no real use for it and out of the last million blocks less than 200 transactions utelized this feature, most of which were falsly configured anyways. Best case someone forces themselves to hodl for a few years, worst case its used in a malicious way to lock funds forever. In any case they currently make transactions stand out from the rest. 18:21:19 Every time it's brought up in these meetings, everyone kind of just repeats no one wants it 18:21:27 One question about dropping unlock_time that came up again today on Reddit: Could Monero, without any big technical effort or problems, honor locks for "old" transactions after the hardfork? 18:21:40 Yes. 18:21:56 Any connection with binning, perhaps? 18:22:07 Or with range proofs ? 18:23:05 rbrunner: 1) if small-ring-size binning is implemented (wallet-side), then it is easy to work around past locked outputs; 2) if large-ring-size binning is implemented (deterministic), then all outputs would be segregated from old outputs anyway (new key image construction), so no concern 18:23:30 If old locks stay valid, those HODLers could now lock before the hardfork, and all is good :) 18:24:14 Oh, one thing lock time was good at: some people like proof of burn for some reason. 18:24:59 Yes the application where the lock time is > age of universe 18:25:21 But I think there are other ways to burn? 18:25:53 Can't you send to 0 address and provide the tx key? 18:25:54 Yes, presumably sending to a public key that looks not random. 18:25:56 send the funds to point at infinity? 18:26:44 I like that. I sent monero to infinity. Actually I dn't like that at all, I just like the sound of it. 18:27:35 in the related MRL issue (78), yorha-0x talked about the use case where you want someone holding Monero for a set duration to perform some role for that period of time 18:28:50 they used it for smooth to prove unspent funds, and there are alternatives to proving unspent funds 18:29:10 but that's a use case at least 18:30:01 not sure how practical it is and no one seems to be using it for that purpose 18:30:27 On the other hand, 200 txs in a million is pretty damning, thinking of it. Maybe just the psychological problem of letting go something. 18:31:41 by damning, you're saying "low", right? 18:32:09 Yes, it seems to speak loud and clearly that nobody really wants and nobody really needs 18:32:20 Despite some ideas that we may have. 18:32:42 Agree 18:32:42 rbrunner: afaik there has never been a hard fork to remove a consensus feature (just a wallet feature - unencrypted payment ids) 18:33:18 Yes, I agree it's worth it to be careful to take something away. 18:33:40 But maybe we have done "due diligence" now already. 18:33:55 imop there should just be a reddit post pinned on the sub for a few days before its removed telling people if they want to force hodl, they now have the last chance to lock funds. 18:34:15 0-rings got removed I guess. 18:34:45 The ability to claim less block reward than you can. 18:34:52 * moneromooo unashamed pedant 18:35:36 I think that's a comparable thing, considering it's something no one really uses :) 18:36:16 reddit post sounds good to me 18:36:34 It will provide useful feedback 18:36:40 for some outside perspective, im not a dev, just a regular user. if you told me privacy improves and blockchain grows a little slower in exchange for some feature that is barely ever used, id be happy you made the change 18:37:07 A general Reddit post then, not just a few days before deadline, for the HODLers? 18:37:37 If yes, I was thinking about doing one, but in the end was too lazy until now ... 18:37:55 i dont think you need to pin this for another 12 months, would probably lead to peole experimenting and some locking funds forever 18:38:51 In any case, just an post to inform about the dropping of a feature 18:39:10 Because unused or not, dropping features is special 18:39:23 at least to some degree 18:39:53 Ill make a post asking for feedback 18:40:25 Nice 18:41:25 Alright, last specifically named topic for today: integrated addresses 18:42:21 Seems quite a big topic, given that time is quite advanced already. Maybe next meeting? 18:42:21 do the exchanges already use subadresses? 18:43:07 everyone ok with that? 18:43:10 Well, maybe not big, but potentially controversal and multi-faceted 18:43:52 Any other business? 18:44:15 A lot of exchanges / merchants still use integrated addresses. It would be a controversial change. 18:44:51 let's push to next meeting, not sure everyone is still around with enough time. Large enough topic indeed 18:44:54 yep 18:45:58 IIRC one of the hopes for this meeting was to think about/set a date for next hard fork. Is there any loose idea on that? 18:46:50 or still too early to say 18:47:16 Not specifically on the list but unless there is more on the tryptic / alternatives front, i dont think any time soon? 18:47:30 s/tryptic/tryptich/ 18:48:02 The idea for this HF is before tryptic / alternatives 18:48:20 Nov/Dec still ballpark target for me. But I think most important is we keep rolling the dev (and mrl) meetings regularly, then it should become clear enough quickly 18:48:32 Yes, seems to me with BP+ ready, and no binning "adventures" we could be ready pretty soon 18:48:55 sounds good to me 18:49:06 binning does not need a HF 18:49:18 once ring size is chosen 18:49:23 Ah, yes 18:49:31 Would it be possible to aim for something like a saturday? I hated having to watch the eth london fork at work lol 18:49:43 it would be nice to do in a HF I think, to try and get wallets to conform selection algos at the same time 18:49:46 one topic not on the agenda (maybe for next time): this big multisig PR is open and I'm hoping to get it in with the next big release https://github.com/monero-project/monero/pull/7877 18:51:03 Time for next meeting? 18:51:43 Oct 10 or 17 at 1700 UTC? 18:51:59 In for that 18:52:46 1 or two weeks, what do you guys think 18:53:15 2 weeks seems fine to me 18:53:18 October 17 18:54:28 Sounds good, ill gather feedback for the removal of timelocks till then. 18:55:34 Thanks for taking the time everyone, have a nice day. Next meeting in 2 weeks. 18:55:48 Thanks 19:00:44 "one topic not on the agenda (..." <- might be worth asking for reviews a couple times during the week here so we get more eyes on it 19:01:26 15-17 ring size bump, bp+ and what else? temporary hardfork wen sir? 19:04:56 utxobr[m]: ok I will bring it up some more :) it is probably difficult to review, especially since very few people know much about multisig 19:11:38 looks like stoffu did most of the review for the original implementation 19:12:34 15-17 ring size bump, bp+ and what else? temporary hardfork wen sir? Ring size, BP+ and issue 70 / fees are the HF needed changes 19:12:42 https://www.reddit.com/r/Monero/comments/q0oiln/proposal_to_remove_timelock_feature/?utm_source=share&utm_medium=web2x&context=3 19:12:55 should i edit anything? 19:15:04 I would add a link to the meeting logs 19:15:46 This can be done in a comment anyway 19:16:14 Also link to the original github issue: https://github.com/monero-project/research-lab/issues/78 19:22:57 ArticMine: copy that. now let's get a date figured out. guess that's left for next -dev meeting. ring size bump, bp+, mrl70 sound great to me. 19:23:09 any consensus on ring size bump number? 15, 17, 22, 24? 19:23:24 wownero runs fixed 22 ring size since inception, no issue, fwiw. 19:27:36 Would it be possible to aim for something like a saturday? 19:27:48 Preferably the date is during the week, as services have less staff available on weekends typically 19:32:49 Preferably the date is during the week, as services have less staff available on weekends typically 19:32:50 +1 19:36:18 Yeah i guess that's true. 20:01:56 Sorry that I couldn't sit in on the meeting. It looks like it was a success in several ways. I've made an issue/agenda for the next meeting and added UkoeHB's multisig work. 20:01:56 https://github.com/monero-project/meta/issues/617 20:03:16 I'll add more links if I spot anything relevant in the next 2 weeks 21:25:22 tks carrington[m]. 22:25:44 The core team together with the current hackerone team decided to add selsta to help with hackerone disclosures. We're glad he accepted. Thank you selsta :) 22:25:57 Thanks :) 22:31:58 niiiice. 22:32:07 * rottenstonks gets selsta a beer 22:36:37 yay 22:38:15 selsta: IPA or light beer? 22:38:27 * rottenstonks creates #monero-beer channel 23:03:25 Feedback and edits welcome: https://www.monero.observer/community-consensus-to-remove-monero-timelocks/ 23:04:44 "The core team together with..." <- Great to hear it! 23:04:57 "The core team together with..." <- Besides this good news, anything else worth reporting from today's dev meeting? I'm very tired today. 23:09:43 looks like an awesome meeting! i like the ringsize 22 / binning solution 23:20:07 gingeropolous! 23:23:39 escapethe3ra[m]1: nice summary. https://www.monero.observer/community-consensus-to-remove-monero-timelocks/ 23:26:44 escapethe3ra[m]1: some links on the bottom are clickable and some others are not. 11, 12, 13 are... fyi.