has anyone tried calling this library with ruby ffi? github.com/monero-ecosystem/monero-cpp I am specifically interested in the verify message function: moneroecosystem.org/monero-cpp/clas…l#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

call from ruby? :D

The wallet has the secret keys to verify the message.

You could extract the crypto code though.

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

didnt know the verifier needs a secret

The verifier does not need a secret. Only the signer does. So you're right, even easier to extract.

Sorry, didn't think before writing :)

<moneromooo> "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

good approach.

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

same with checkSpendProof which will be the next in line lol

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.

<moneromooo> "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 github.com/monero-ecosystem/monero-…wallet/monero_wallet_full.cpp#L1029 so it seems like

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:

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.

s/checkSpendProof/checktxproof/

Yes, that's what I meant. The wallet is basically the Monero user.

We could have added a new program to verify a signature too in this case. You could even do that and PR it.

<moneromooo> "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

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! 👍️😀

Reminder that there is a meeting scheduled here in just under an hour

I can only be present intermittently. Hopefully someone can volunteer to moderate

Wtf is utc

a timezone :D

Weird one

nah

it's the standard

Universal Coordinated Time, +4HRS EST

The what is UST for

Wait

I think I meant EST

I'm confused

So how does the meeting work, since it's also happening in liberachat the same time

I am talking from liberachat :)

Ah ok

What do you guys think of p2pool? I think it's awesome but it's kinda impossible for me to get shares

I mined with 4000 h/s for 2 days straight and found like 2 shares but they somehow didn't get credited

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

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?

> <@carrington:monero.social> Reminder that there is a meeting scheduled here in just under an hour

>

> monero-project/meta #614

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.

FixedFloat uses integrated addresses and I use FixedFloat often. :(

Is MorphToken legit?

seems like a question for #monero or #monero-community

whoops!

<monerobull[m]> "Ok different topic, i think it..." <- I haven't really pushed for the removal of main addresses no

i thought i was in #monero 🤦‍♀️

:)

I think that was only in connection with Seraphis, no?

Where many things will change anyway at the same time

I haven't thought about that but maybe I would support that

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.

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?

<sgp_1> "I haven't really pushed for..." <- sorry, it was seth

meeting?

Meeting time?

Meeting time?

rbrunner I do believe so.

Hello people. Someone wanted a meeting. So since they do not seem to be around yet, anyone wants to talk about dev related things ?

<carrington[m]> "I can only be present intermitte..." <- ^ Does someone want to volunteer to moderate?

Who is running? :)

Well, lets start with point one on the agenda. Thanks to everyone for coming. Who would like to tell us about BP+?

It's ready to go in, code wise. Can't recall whether it's been audited now.

BP+ is basically ready, it's missing an approval on Github. Wownero has been running it for a couple months.

It is audited.

Seems to have been audited twice, anyone audited the audits?

There was no change in ring size for BP+ impl?

BP+ does not care about rings.

Ring size is separate.

I guess that missing aproval on GitHub is a formularity then?

Could someone quickly summarize what BP+ adds to BPs?

It doesn't add, it removes :D

(bytes)

there are some source code conflicts that need to be resolved

BP+ are simply more efficient than BP

For the BP patch, vtnerd ?

yeah, thats what Github says

OK, I'll fix then soon then. Thanks.

Sounds great. Anything else to add to the topic or do we move on to the next one?

One minor BP+ thing

Any progress on using the BP+ storage for a txid - type/soze string or not yet?

s/soze/size

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.

As something like an tx_extra alternative?

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.

moneromooo: Ah okay thanks

Triptych :)

Right :D

Does seraphis allow such stashage without leakage btw ?

I think only Koe, Aaron, or Aram could answer that right now

Moving on to 3? Fee changes

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.

It's ready AFAIK. ukoeHB reviewed it.

No it definitely is high priority

In my view, its priority has become more urgent due to the tx volume anomaly

There is a consensus change here. If current trends continue we could reach the penalty zone in 12 - 18 months

The consensus portion needs tp go into the next HF

Hmmm ... would that mean more than simply growing blocks?

(Reaching the penalty zone)

ArticMine you need an agreement on the ringsize to finalize this right?

The current formulation allows for a ring size up to 26

Ah so no blocker there then re ringsize for now

So with the discussion between 15 - 25 there is no blocker

Anything else on the topic? Maybe someone can tell us how or if this will impact regular users at all?

Marginally higher base fees, greater fee downward pressure at large volumes

They'll pay peanuts in fees instead of fifts of peanuts.

Well, would this be the right time to settle on a number already? If not, what is still missing for doing so?

rbrunner: If this is re ringsize wait for 5 pls

thanks

Oh, ok, separate topic. Sorry.

:)

We still got a lot of headroom so this shouldnt be a problem. Good job ArticMine.

Thanks

Moving on to the next topic: Decoy selection algorithm changes

Indeed, the pdf was very detailed/precise.

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.

Thorough it the word I was looking for :D

Yeah! More code, less, er, other things.

Patching integer truncation is still sitting in PR 7798

The following is new public information. Previously I had said publicly that an "applied statistician" was reviewing my HackerOne submission.

Now I can say that :

Syksy, who holds a Ph.D. in biostatistics, is in the process of examining the HackerOne submission.

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.

Are there any others besides 7798 that are waiting for merge

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?

I don't think we should even discuss that at the moment at all.

sgp_1 nope, nothing else at the moment in PR stage

sgp_1: any other what?

Agreed

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

<binaryFate> I don't think we should even discuss that at the moment at all <--- agree

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

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

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

re: fee PR, I’d like someone else to review as well in case I missed some detail. vtnerd selsta maybe?

You mean the code in 7798 does that? Not sure how to understand "recommended"

it's too complicated for me

I doubt I can review much there but I can take a look

jberman: Seems reasonable, and luckily this is an edge case

Maybe one of the guys who show up saying ‘let me do something’ could review?

rbrunner The code in 7798 doesn't do that, it's sech1' PR . I'll create a new PR

Unrelated: is anyone keeping notes or should i do that?

Do we stil have a recent spend window ? I thought that was gone with the switch to gamma...

UkoeHB - already put the fee PR review in my todo list ...

monerobull[m]: usually we post all the logs in the issue

Great thanks vtnerd

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 :)

the recent spend window is when gamma "selects" blocks 0-10

Right

Wait no sorry

Oh a new thing. OK, sorry, don;'t mind me.

tossing that result ruins the intended distribution

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 ^^

Someone else can get it no worries

vtnerd as in, if the gamma selects an output 5 blocks ago, and then tosses, it ruins the intended distribution youre' saying?

correct, that was the change I saw for monero-lws, no? to _not_ throwaway selections in the locked phase

Yep. Didn't see moo's question

moo was just unclear what recent spend window meant, because it sounded like an older algorithm used a few years back

Idea is to re-select an output at random from the "recent spend window"

Will submit a PR to drop that window from blocks 10-60 (what it is now), to blocks 10-20

And this only impacts txs with a lock_time or all txs?

All txs

Next up on that list is "binning"

I assume you're choosing 10 because it's a better fit? Can you include data for that in the PR you make?

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

> what it would look like

the integer truncation I assume fix

fix I assume*

shows what fixing integer truncation + modifying the recent spend window look like, with different windows

e.g. user-images.githubusercontent.com/2…0a4-0cfa-4b91-bc1e-28ecbceac330.png

re: binning, jberman were you hoping to push for binning in the upcoming hard fork?

I think that depends on unlock time

it seems there is a lot of support for deprecating unlock times

is it reasonable to push for deprecation of a feature that soon?

I would like to have a statistician look at binning before it is implemented in production code.

If everyone agrees we can discuss unlock times right now and ringsizes after.

Maybe another question would be, do we want to introduce significant new changes/PRs for the next hard fork?

Or take what we have and wrap it up?

I mean, I have "looked at" it, but not really examined it with much scrutiny.

I'm definitely somewhat worried about trying to squeeze binning in

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

jberman: I just eyeballed it, but 10 or 15 seem the most sensible so I say it looks good

Code-wise, binning would basically starting from zero, right?

Binning really ought to go in with seraphis/triptych/whatever.

moneromooo: I generally agree with this yes

That makes the most sense to me.

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

MRL issue 86

I suspect it's pretty easy to prove that a slight increase of the ring + some binning does not degrade situation wrt. now

(and of course is very likely to improve it)

If binning does what it says it does, then it seems to me that it would reduce the statistical attack surface of ring signatures.

I am not certain that it does what it says since I haven't examined it closely.

Actually I was thinking of binning including parametric ring description. Binning alone is wallet only so could go in.

Though it'd likely mean other wallets would not follow suit, or with a delay, giving isthmus more puddles.

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?

I think 2 is realistic for a very short time period, yes

But moo is right it has the issue of more puddles

Who has vetted binning?

Yeah with small rings, binning makes sense to be wallet-side.

Nobody, since there's no proposed algorithm yet.

You'd probably only get 2-3 ring members per bin

Isn't it directly from Moser et al. (2018)? Or have more papers discussed it?

moneromooo: Then (2) above seems infeasible.

I feel a little lost on tracking the progress of binning, so a clear summary of the situation and desired change would help me

not sure everyone has same definition of "very simple binning" in mind

Rucknium[m]: these guys also basically advocate for binning petsymposium.org/2021/files/papers/issue3/popets-2021-0047.pdf

The question I have with binning is number of bins and number of ring ring member per ring

I'll write up a PoC for "very simple binning" in the wallet, and that can be vetted/reviewed

per bin

Thanks jberman

Okay cool, maybe it's best to wait for that

thanks

UkoeHB: Yeah I saw that paper. Haven't gone line-by-line though.

Their 'partitioning' concept is essentially binning.

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.

That might be good. Not sure...

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?

(assuming binning picks contiguous outputs and not outputs in the same general area).

I wasn't thinking of selecting contiguous outputs

I mean, that's a research ethics issue

rucknium[m]: There have probably been dozens of papers over the years that recommend binning of some form

sgp_[m]: Send them my way then

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?

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).

I think unless someone has a strong argument otherwise, we go with ringsize 16

lol

There's roughly strong support for anywhere 15-19

And knaccc made the best argument for 16 in particular imo

This is a hard fork. My though here is can we accommodate binning with the choice of ring size

Ringsize 16 because it would be compatible with the tryptich alternative, right?

monerobull[m]: No it would significantly change then

Binning not dependent on ring size, in theory could just have remainder in a separate smaller bin

monerobull[m]: triptych/etc/ would have ring size 64-256

But probably would be nicer to have equal sized bins

for example 8 bins 2 ring members per bin 16 or 3 members per bin 24

what is the best argument for 16? missed that

I think 16 is good, less than 50% increase in per-ring-member cost.

8 bins 2 member per bin

also using a per of 2 for the number of bins

power

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

the next I would consider is 24 8 bins 3 members per bin

Ok I always found this psychologic "1 million" target arbitrary. But nothing against it anyway.

Slightly sad we depart from primes :)

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

binaryFate: I agree it's arbitrary

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

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

approach

7 "bins" would be gamma selected, basically, as opposed to the current 10

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)?

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

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.

eh I don't know, I keep changing my mind about binning

did MRL issue 86 have any impact on your thoughts, or was that all a wash :)

theres a point where binning is clearly recuding/revealing time windows, otoh it helps when the attacker definitely knows a time window

the argument that it's a backup if the gamma is missing outputs doesn't have much strength you think?

so from 11->8 reduces possible spend timeframes, but still might be a win. its just hard to quantify

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?

Yeah binning is strictly better for some and strictly worse for others, so it's a balancing act

I depends on how well one trusts the the gamma

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

ArticMine: It seems there are varying opinions about how well to trust the gamma distribution. hmmm

Rucknium[m]: Im not certain, because I would have to spend more sketching out a potential tracing tool

"there is no timing footprint" ... There seems to be some sort of sleep-wake cycle in the data. Not surprising, I suppose.

vtnerd_: Seems like binning has not been fully vetted

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

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

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

binaryFate: Understood.

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.

We could not compromise at all and choose 11 bins, 2 outputs per bin :p

Then ring 22

Seems wasteful but hey no hard decisions

otoh, I don't know how valuable that is in tracing

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.

or increase the gamma to 12v with ring 24

Personally I'd wait to see jberman write up to elaborate more, so at least we have a basis for more structured discussion

(y)

I think we're all roughly on the same page of understanding

jberman: MRL 86 didn't change my thinking about binning specifically, but helped highlight 2 difficulties in the distribution selection

how would binning affect verification time?

A simple wallet-only approach wouldn't affect it at all

oh no sorry, no jberman it did highlight why binning would be useful

it just didn't change that there may be a downside

Makes sense :)

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.

Every time it's brought up in these meetings, everyone kind of just repeats no one wants it

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?

Yes.

Any connection with binning, perhaps?

Or with range proofs ?

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

If old locks stay valid, those HODLers could now lock before the hardfork, and all is good :)

Oh, one thing lock time was good at: some people like proof of burn for some reason.

Yes the application where the lock time is > age of universe

But I think there are other ways to burn?

Can't you send to 0 address and provide the tx key?

Yes, presumably sending to a public key that looks not random.

send the funds to point at infinity?

I like that. I sent monero to infinity. Actually I dn't like that at all, I just like the sound of it.

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

they used it for smooth to prove unspent funds, and there are alternatives to proving unspent funds

but that's a use case at least

not sure how practical it is and no one seems to be using it for that purpose

On the other hand, 200 txs in a million is pretty damning, thinking of it. Maybe just the psychological problem of letting go something.

by damning, you're saying "low", right?

Yes, it seems to speak loud and clearly that nobody really wants and nobody really needs

Despite some ideas that we may have.

Agree

rbrunner: afaik there has never been a hard fork to remove a consensus feature (just a wallet feature - unencrypted payment ids)

Yes, I agree it's worth it to be careful to take something away.

But maybe we have done "due diligence" now already.

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.

0-rings got removed I guess.

The ability to claim less block reward than you can.

I think that's a comparable thing, considering it's something no one really uses :)

reddit post sounds good to me

It will provide useful feedback

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

A general Reddit post then, not just a few days before deadline, for the HODLers?

If yes, I was thinking about doing one, but in the end was too lazy until now ...

i dont think you need to pin this for another 12 months, would probably lead to peole experimenting and some locking funds forever

In any case, just an post to inform about the dropping of a feature

Because unused or not, dropping features is special

at least to some degree

Ill make a post asking for feedback

Nice

Alright, last specifically named topic for today: integrated addresses

Seems quite a big topic, given that time is quite advanced already. Maybe next meeting?

do the exchanges already use subadresses?

everyone ok with that?

Well, maybe not big, but potentially controversal and multi-faceted

Any other business?

A lot of exchanges / merchants still use integrated addresses. It would be a controversial change.

let's push to next meeting, not sure everyone is still around with enough time. Large enough topic indeed

yep

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?

or still too early to say

Not specifically on the list but unless there is more on the tryptic / alternatives front, i dont think any time soon?

s/tryptic/tryptich/

The idea for this HF is before tryptic / alternatives

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

Yes, seems to me with BP+ ready, and no binning "adventures" we could be ready pretty soon

sounds good to me

binning does not need a HF

once ring size is chosen

Ah, yes

Would it be possible to aim for something like a saturday? I hated having to watch the eth london fork at work lol

it would be nice to do in a HF I think, to try and get wallets to conform selection algos at the same time

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 monero-project/monero #7877

Time for next meeting?

Oct 10 or 17 at 1700 UTC?

In for that

1 or two weeks, what do you guys think

2 weeks seems fine to me

October 17

Sounds good, ill gather feedback for the removal of timelocks till then.

Thanks for taking the time everyone, have a nice day. Next meeting in 2 weeks.

Thanks

<UkoeHB> "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

15-17 ring size bump, bp+ and what else? temporary hardfork wen sir?

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

looks like stoffu did most of the review for the original implementation

<rottenstonks> 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

should i edit anything?

I would add a link to the meeting logs

This can be done in a comment anyway

Also link to the original github issue: monero-project/research-lab #78

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.

any consensus on ring size bump number? 15, 17, 22, 24?

wownero runs fixed 22 ring size since inception, no issue, fwiw.

<monerobull[m]> Would it be possible to aim for something like a saturday?

Preferably the date is during the week, as services have less staff available on weekends typically

<dEBRUYNE> Preferably the date is during the week, as services have less staff available on weekends typically

+1

Yeah i guess that's true.

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.

I'll add more links if I spot anything relevant in the next 2 weeks

tks carrington[m].

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 :)

Thanks :)

niiiice.

yay

selsta: IPA or light beer?

Feedback and edits welcome: monero.observer/community-consensus-to-remove-monero-timelocks

<binaryFate> "The core team together with..." <- Great to hear it!

<binaryFate> "The core team together with..." <- Besides this good news, anything else worth reporting from today's dev meeting? I'm very tired today.

looks like an awesome meeting! i like the ringsize 22 / binning solution

gingeropolous!

escapethe3ra[m]1: nice summary. monero.observer/community-consensus-to-remove-monero-timelocks

escapethe3ra[m]1: some links on the bottom are clickable and some others are not. 11, 12, 13 are... fyi.