-
spirobel[m]
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
-
spirobel[m]
call from ruby? :D
-
moneromooo
The wallet has the secret keys to verify the message.
-
moneromooo
You could extract the crypto code though.
-
spirobel[m]
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
-
spirobel[m]
didnt know the verifier needs a secret
-
moneromooo
The verifier does not need a secret. Only the signer does. So you're right, even easier to extract.
-
moneromooo
Sorry, didn't think before writing :)
-
spirobel[m]
<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
-
spirobel[m]
good approach.
-
spirobel[m]
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
-
spirobel[m]
same with checkSpendProof which will be the next in line lol
-
moneromooo
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.
-
spirobel[m]
<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
-
spirobel[m]
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:
-
spirobel[m]
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.
-
spirobel[m]
s/checkSpendProof/checktxproof/
-
moneromooo
Yes, that's what I meant. The wallet is basically the Monero user.
-
moneromooo
We could have added a new program to verify a signature too in this case. You could even do that and PR it.
-
spirobel[m]
<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
-
spirobel[m]
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! 👍️😀
-
carrington[m]
Reminder that there is a meeting scheduled here in just under an hour
-
carrington[m]
-
carrington[m]
I can only be present intermittently. Hopefully someone can volunteer to moderate
-
monerobull[m]
Wtf is utc
-
atomfried[m]
a timezone :D
-
monerobull[m]
Weird one
-
easrng
nah
-
easrng
it's the standard
-
easrng
-
jimmyt[m]
Universal Coordinated Time, +4HRS EST
-
monerobull[m]
The what is UST for
-
monerobull[m]
Wait
-
monerobull[m]
I think I meant EST
-
monerobull[m]
I'm confused
-
monerobull[m]
So how does the meeting work, since it's also happening in liberachat the same time
-
DataHoarder
I am talking from liberachat :)
-
monerobull[m]
Ah ok
-
monerobull[m]
What do you guys think of p2pool? I think it's awesome but it's kinda impossible for me to get shares
-
monerobull[m]
I mined with 4000 h/s for 2 days straight and found like 2 shares but they somehow didn't get credited
-
DataHoarder
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
-
monerobull[m]
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?
-
spirobel[m]
> <@carrington:monero.social> Reminder that there is a meeting scheduled here in just under an hour
-
spirobel[m]
>
-
spirobel[m]
-
spirobel[m]
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.
-
anarkiocrypto[m]
FixedFloat uses integrated addresses and I use FixedFloat often. :(
-
easrng
Is MorphToken legit?
-
nioc
seems like a question for #monero or #monero-community
-
easrng
whoops!
-
sgp_1
<monerobull[m]> "Ok different topic, i think it..." <- I haven't really pushed for the removal of main addresses no
-
easrng
i thought i was in #monero 🤦♀️
-
nioc
:)
-
rbrunner
I think that was only in connection with Seraphis, no?
-
rbrunner
Where many things will change anyway at the same time
-
sgp_1
I haven't thought about that but maybe I would support that
-
moneromooo
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.
-
selsta
-
spirobel[m]
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?
-
monerobull[m]
<sgp_1> "I haven't really pushed for..." <- sorry, it was seth
-
binaryFate
meeting?
-
rbrunner
Meeting time?
-
sgp_1
Meeting time?
-
Rucknium[m]
rbrunner I do believe so.
-
moneromooo
Hello people. Someone wanted a meeting. So since they do not seem to be around yet, anyone wants to talk about dev related things ?
-
Rucknium[m]
<carrington[m]> "I can only be present intermitte..." <- ^ Does someone want to volunteer to moderate?
-
sgp_1
Who is running? :)
-
monerobull[m]
Well, lets start with point one on the agenda. Thanks to everyone for coming. Who would like to tell us about BP+?
-
moneromooo
It's ready to go in, code wise. Can't recall whether it's been audited now.
-
selsta
BP+ is basically ready, it's missing an approval on Github. Wownero has been running it for a couple months.
-
selsta
It is audited.
-
monerobull[m]
Seems to have been audited twice, anyone audited the audits?
-
Inge
There was no change in ring size for BP+ impl?
-
moneromooo
BP+ does not care about rings.
-
selsta
Ring size is separate.
-
rbrunner
I guess that missing aproval on GitHub is a formularity then?
-
monerobull[m]
Could someone quickly summarize what BP+ adds to BPs?
-
moneromooo
It doesn't add, it removes :D
-
moneromooo
(bytes)
-
vtnerd_
there are some source code conflicts that need to be resolved
-
sgp_1
BP+ are simply more efficient than BP
-
moneromooo
For the BP patch, vtnerd ?
-
vtnerd_
yeah, thats what Github says
-
moneromooo
OK, I'll fix then soon then. Thanks.
-
monerobull[m]
Sounds great. Anything else to add to the topic or do we move on to the next one?
-
sgp_1
One minor BP+ thing
-
sgp_1
Any progress on using the BP+ storage for a txid - type/soze string or not yet?
-
sgp_1
s/soze/size
-
moneromooo
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.
-
rbrunner
As something like an tx_extra alternative?
-
moneromooo
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.
-
sgp_1
moneromooo: Ah okay thanks
-
rbrunner
Triptych :)
-
moneromooo
Right :D
-
moneromooo
Does seraphis allow such stashage without leakage btw ?
-
sgp_1
I think only Koe, Aaron, or Aram could answer that right now
-
jberman
Moving on to 3? Fee changes
-
monerobull[m]
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.
-
moneromooo
It's ready AFAIK. ukoeHB reviewed it.
-
sgp_1
No it definitely is high priority
-
Rucknium[m]
In my view, its priority has become more urgent due to the tx volume anomaly
-
ArticMine
There is a consensus change here. If current trends continue we could reach the penalty zone in 12 - 18 months
-
ArticMine
The consensus portion needs tp go into the next HF
-
rbrunner
Hmmm ... would that mean more than simply growing blocks?
-
rbrunner
(Reaching the penalty zone)
-
sgp_1
ArticMine you need an agreement on the ringsize to finalize this right?
-
ArticMine
The current formulation allows for a ring size up to 26
-
sgp_1
Ah so no blocker there then re ringsize for now
-
ArticMine
So with the discussion between 15 - 25 there is no blocker
-
monerobull[m]
Anything else on the topic? Maybe someone can tell us how or if this will impact regular users at all?
-
sgp_1
Marginally higher base fees, greater fee downward pressure at large volumes
-
moneromooo
They'll pay peanuts in fees instead of fifts of peanuts.
-
rbrunner
Well, would this be the right time to settle on a number already? If not, what is still missing for doing so?
-
sgp_1
rbrunner: If this is re ringsize wait for 5 pls
-
ArticMine
thanks
-
rbrunner
Oh, ok, separate topic. Sorry.
-
sgp_1
:)
-
monerobull[m]
We still got a lot of headroom so this shouldnt be a problem. Good job ArticMine.
-
ArticMine
Thanks
-
monerobull[m]
Moving on to the next topic: Decoy selection algorithm changes
-
moneromooo
Indeed, the pdf was very detailed/precise.
-
Rucknium[m]
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.
-
moneromooo
Thorough it the word I was looking for :D
-
moneromooo
Yeah! More code, less, er, other things.
-
jberman
Patching integer truncation is still sitting in PR 7798
-
» moneromooo approves of this planned work
-
Rucknium[m]
The following is new public information. Previously I had said publicly that an "applied statistician" was reviewing my HackerOne submission.
-
Rucknium[m]
Now I can say that :
-
Rucknium[m]
Syksy, who holds a Ph.D. in biostatistics, is in the process of examining the HackerOne submission.
-
Rucknium[m]
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.
-
sgp_1
Are there any others besides 7798 that are waiting for merge
-
monerobull[m]
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?
-
binaryFate
I don't think we should even discuss that at the moment at all.
-
jberman
sgp_1 nope, nothing else at the moment in PR stage
-
selsta
sgp_1: any other what?
-
sgp_1
Agreed
-
Rucknium[m]
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
-
ArticMine
<binaryFate> I don't think we should even discuss that at the moment at all <--- agree
-
sgp_1
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
-
jberman
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
-
jberman
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
-
UkoeHB
re: fee PR, I’d like someone else to review as well in case I missed some detail. vtnerd selsta maybe?
-
rbrunner
You mean the code in 7798 does that? Not sure how to understand "recommended"
-
selsta
it's too complicated for me
-
selsta
I doubt I can review much there but I can take a look
-
sgp_1
jberman: Seems reasonable, and luckily this is an edge case
-
UkoeHB
Maybe one of the guys who show up saying ‘let me do something’ could review?
-
jberman
rbrunner The code in 7798 doesn't do that, it's sech1' PR . I'll create a new PR
-
monerobull[m]
Unrelated: is anyone keeping notes or should i do that?
-
moneromooo
Do we stil have a recent spend window ? I thought that was gone with the switch to gamma...
-
vtnerd_
UkoeHB - already put the fee PR review in my todo list ...
-
UkoeHB
monerobull[m]: usually we post all the logs in the issue
-
UkoeHB
Great thanks vtnerd
-
sgp_1
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 :)
-
vtnerd_
the recent spend window is when gamma "selects" blocks 0-10
-
jberman
Right
-
jberman
Wait no sorry
-
moneromooo
Oh a new thing. OK, sorry, don;'t mind me.
-
vtnerd_
tossing that result ruins the intended distribution
-
monerobull[m]
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 ^^
-
UkoeHB
Someone else can get it no worries
-
jberman
vtnerd as in, if the gamma selects an output 5 blocks ago, and then tosses, it ruins the intended distribution youre' saying?
-
vtnerd_
correct, that was the change I saw for monero-lws, no? to _not_ throwaway selections in the locked phase
-
jberman
Yep. Didn't see moo's question
-
vtnerd_
moo was just unclear what recent spend window meant, because it sounded like an older algorithm used a few years back
-
jberman
Idea is to re-select an output at random from the "recent spend window"
-
jberman
Will submit a PR to drop that window from blocks 10-60 (what it is now), to blocks 10-20
-
sgp_1
And this only impacts txs with a lock_time or all txs?
-
jberman
All txs
-
jberman
Next up on that list is "binning"
-
sgp_1
I assume you're choosing 10 because it's a better fit? Can you include data for that in the PR you make?
-
jberman
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
-
UkoeHB
> what it would look like
-
UkoeHB
the integer truncation I assume fix
-
UkoeHB
fix I assume*
-
jberman
shows what fixing integer truncation + modifying the recent spend window look like, with different windows
-
jberman
-
UkoeHB
re: binning, jberman were you hoping to push for binning in the upcoming hard fork?
-
jberman
I think that depends on unlock time
-
jberman
it seems there is a lot of support for deprecating unlock times
-
jberman
is it reasonable to push for deprecation of a feature that soon?
-
Rucknium[m]
I would like to have a statistician look at binning before it is implemented in production code.
-
monerobull[m]
If everyone agrees we can discuss unlock times right now and ringsizes after.
-
UkoeHB
Maybe another question would be, do we want to introduce significant new changes/PRs for the next hard fork?
-
UkoeHB
Or take what we have and wrap it up?
-
Rucknium[m]
I mean, I have "looked at" it, but not really examined it with much scrutiny.
-
sgp_1
I'm definitely somewhat worried about trying to squeeze binning in
-
jberman
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
-
sgp_1
jberman: I just eyeballed it, but 10 or 15 seem the most sensible so I say it looks good
-
rbrunner
Code-wise, binning would basically starting from zero, right?
-
moneromooo
Binning really ought to go in with seraphis/triptych/whatever.
-
sgp_1
moneromooo: I generally agree with this yes
-
UkoeHB
That makes the most sense to me.
-
jberman
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
-
jberman
MRL issue 86
-
binaryFate
I suspect it's pretty easy to prove that a slight increase of the ring + some binning does not degrade situation wrt. now
-
binaryFate
(and of course is very likely to improve it)
-
Rucknium[m]
If binning does what it says it does, then it seems to me that it would reduce the statistical attack surface of ring signatures.
-
Rucknium[m]
I am not certain that it does what it says since I haven't examined it closely.
-
moneromooo
Actually I was thinking of binning including parametric ring description. Binning alone is wallet only so could go in.
-
moneromooo
Though it'd likely mean other wallets would not follow suit, or with a delay, giving isthmus more puddles.
-
sgp_1
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?
-
jberman
I think 2 is realistic for a very short time period, yes
-
jberman
But moo is right it has the issue of more puddles
-
Rucknium[m]
Who has vetted binning?
-
UkoeHB
Yeah with small rings, binning makes sense to be wallet-side.
-
moneromooo
Nobody, since there's no proposed algorithm yet.
-
UkoeHB
You'd probably only get 2-3 ring members per bin
-
Rucknium[m]
Isn't it directly from Moser et al. (2018)? Or have more papers discussed it?
-
Rucknium[m]
moneromooo: Then (2) above seems infeasible.
-
sgp_1
I feel a little lost on tracking the progress of binning, so a clear summary of the situation and desired change would help me
-
binaryFate
not sure everyone has same definition of "very simple binning" in mind
-
UkoeHB
-
ArticMine
The question I have with binning is number of bins and number of ring ring member per ring
-
jberman
I'll write up a PoC for "very simple binning" in the wallet, and that can be vetted/reviewed
-
ArticMine
per bin
-
UkoeHB
Thanks jberman
-
sgp_1
Okay cool, maybe it's best to wait for that
-
binaryFate
thanks
-
Rucknium[m]
UkoeHB: Yeah I saw that paper. Haven't gone line-by-line though.
-
UkoeHB
Their 'partitioning' concept is essentially binning.
-
moneromooo
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.
-
moneromooo
That might be good. Not sure...
-
Rucknium[m]
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?
-
moneromooo
(assuming binning picks contiguous outputs and not outputs in the same general area).
-
jberman
I wasn't thinking of selecting contiguous outputs
-
Rucknium[m]
I mean, that's a research ethics issue
-
sgp_1
rucknium[m]: There have probably been dozens of papers over the years that recommend binning of some form
-
Rucknium[m]
sgp_[m]: Send them my way then
-
monerobull[m]
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?
-
UkoeHB
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).
-
sgp_1
I think unless someone has a strong argument otherwise, we go with ringsize 16
-
moneromooo
lol
-
sgp_1
There's roughly strong support for anywhere 15-19
-
sgp_1
And knaccc made the best argument for 16 in particular imo
-
ArticMine
This is a hard fork. My though here is can we accommodate binning with the choice of ring size
-
monerobull[m]
Ringsize 16 because it would be compatible with the tryptich alternative, right?
-
sgp_1
monerobull[m]: No it would significantly change then
-
jberman
Binning not dependent on ring size, in theory could just have remainder in a separate smaller bin
-
UkoeHB
monerobull[m]: triptych/etc/ would have ring size 64-256
-
jberman
But probably would be nicer to have equal sized bins
-
ArticMine
for example 8 bins 2 ring members per bin 16 or 3 members per bin 24
-
binaryFate
what is the best argument for 16? missed that
-
UkoeHB
I think 16 is good, less than 50% increase in per-ring-member cost.
-
ArticMine
8 bins 2 member per bin
-
ArticMine
also using a per of 2 for the number of bins
-
ArticMine
power
-
sgp_1
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
-
ArticMine
the next I would consider is 24 8 bins 3 members per bin
-
-
binaryFate
Ok I always found this psychologic "1 million" target arbitrary. But nothing against it anyway.
-
binaryFate
Slightly sad we depart from primes :)
-
sgp_1
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
-
sgp_1
binaryFate: I agree it's arbitrary
-
binaryFate
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
-
jberman
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
-
jberman
approach
-
jberman
7 "bins" would be gamma selected, basically, as opposed to the current 10
-
sgp_1
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)?
-
ArticMine
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
-
monerobull[m]
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.
-
vtnerd_
eh I don't know, I keep changing my mind about binning
-
jberman
did MRL issue 86 have any impact on your thoughts, or was that all a wash :)
-
vtnerd_
theres a point where binning is clearly recuding/revealing time windows, otoh it helps when the attacker definitely knows a time window
-
jberman
the argument that it's a backup if the gamma is missing outputs doesn't have much strength you think?
-
vtnerd_
so from 11->8 reduces possible spend timeframes, but still might be a win. its just hard to quantify
-
Rucknium[m]
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?
-
sgp_1
Yeah binning is strictly better for some and strictly worse for others, so it's a balancing act
-
ArticMine
I depends on how well one trusts the the gamma
-
jberman
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
-
Rucknium[m]
ArticMine: It seems there are varying opinions about how well to trust the gamma distribution. hmmm
-
vtnerd_
Rucknium[m]: Im not certain, because I would have to spend more sketching out a potential tracing tool
-
Rucknium[m]
"there is no timing footprint" ... There seems to be some sort of sleep-wake cycle in the data. Not surprising, I suppose.
-
Rucknium[m]
vtnerd_: Seems like binning has not been fully vetted
-
binaryFate
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
-
sgp_1
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
-
vtnerd_
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
-
Rucknium[m]
binaryFate: Understood.
-
binaryFate
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.
-
sgp_1
We could not compromise at all and choose 11 bins, 2 outputs per bin :p
-
ArticMine
Then ring 22
-
sgp_1
Seems wasteful but hey no hard decisions
-
vtnerd_
otoh, I don't know how valuable that is in tracing
-
UkoeHB
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.
-
ArticMine
or increase the gamma to 12v with ring 24
-
binaryFate
Personally I'd wait to see jberman write up to elaborate more, so at least we have a basis for more structured discussion
-
jberman
(y)
-
sgp_1
I think we're all roughly on the same page of understanding
-
vtnerd_
jberman: MRL 86 didn't change my thinking about binning specifically, but helped highlight 2 difficulties in the distribution selection
-
selsta
how would binning affect verification time?
-
jberman
A simple wallet-only approach wouldn't affect it at all
-
vtnerd_
oh no sorry, no jberman it did highlight why binning would be useful
-
vtnerd_
it just didn't change that there may be a downside
-
jberman
Makes sense :)
-
monerobull[m]
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.
-
jberman
Every time it's brought up in these meetings, everyone kind of just repeats no one wants it
-
rbrunner
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?
-
moneromooo
Yes.
-
rbrunner
Any connection with binning, perhaps?
-
moneromooo
Or with range proofs ?
-
UkoeHB
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
-
rbrunner
If old locks stay valid, those HODLers could now lock before the hardfork, and all is good :)
-
moneromooo
Oh, one thing lock time was good at: some people like proof of burn for some reason.
-
ArticMine
Yes the application where the lock time is > age of universe
-
rbrunner
But I think there are other ways to burn?
-
jberman
Can't you send to 0 address and provide the tx key?
-
moneromooo
Yes, presumably sending to a public key that looks not random.
-
vtnerd_
send the funds to point at infinity?
-
moneromooo
I like that. I sent monero to infinity. Actually I dn't like that at all, I just like the sound of it.
-
jberman
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
-
jberman
they used it for smooth to prove unspent funds, and there are alternatives to proving unspent funds
-
jberman
but that's a use case at least
-
jberman
not sure how practical it is and no one seems to be using it for that purpose
-
rbrunner
On the other hand, 200 txs in a million is pretty damning, thinking of it. Maybe just the psychological problem of letting go something.
-
jberman
by damning, you're saying "low", right?
-
rbrunner
Yes, it seems to speak loud and clearly that nobody really wants and nobody really needs
-
rbrunner
Despite some ideas that we may have.
-
jberman
Agree
-
UkoeHB
rbrunner: afaik there has never been a hard fork to remove a consensus feature (just a wallet feature - unencrypted payment ids)
-
rbrunner
Yes, I agree it's worth it to be careful to take something away.
-
rbrunner
But maybe we have done "due diligence" now already.
-
monerobull[m]
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.
-
moneromooo
0-rings got removed I guess.
-
moneromooo
The ability to claim less block reward than you can.
-
» moneromooo unashamed pedant
-
jberman
I think that's a comparable thing, considering it's something no one really uses :)
-
jberman
reddit post sounds good to me
-
ArticMine
It will provide useful feedback
-
monerobull[m]
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
-
rbrunner
A general Reddit post then, not just a few days before deadline, for the HODLers?
-
rbrunner
If yes, I was thinking about doing one, but in the end was too lazy until now ...
-
monerobull[m]
i dont think you need to pin this for another 12 months, would probably lead to peole experimenting and some locking funds forever
-
rbrunner
In any case, just an post to inform about the dropping of a feature
-
rbrunner
Because unused or not, dropping features is special
-
rbrunner
at least to some degree
-
monerobull[m]
Ill make a post asking for feedback
-
rbrunner
Nice
-
monerobull[m]
Alright, last specifically named topic for today: integrated addresses
-
rbrunner
Seems quite a big topic, given that time is quite advanced already. Maybe next meeting?
-
monerobull[m]
do the exchanges already use subadresses?
-
monerobull[m]
everyone ok with that?
-
rbrunner
Well, maybe not big, but potentially controversal and multi-faceted
-
monerobull[m]
Any other business?
-
selsta
A lot of exchanges / merchants still use integrated addresses. It would be a controversial change.
-
binaryFate
let's push to next meeting, not sure everyone is still around with enough time. Large enough topic indeed
-
selsta
yep
-
jberman
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?
-
jberman
or still too early to say
-
monerobull[m]
Not specifically on the list but unless there is more on the tryptic / alternatives front, i dont think any time soon?
-
monerobull[m]
s/tryptic/tryptich/
-
ArticMine
The idea for this HF is before tryptic / alternatives
-
binaryFate
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
-
rbrunner
Yes, seems to me with BP+ ready, and no binning "adventures" we could be ready pretty soon
-
jberman
sounds good to me
-
ArticMine
binning does not need a HF
-
ArticMine
once ring size is chosen
-
rbrunner
Ah, yes
-
monerobull[m]
Would it be possible to aim for something like a saturday? I hated having to watch the eth london fork at work lol
-
jberman
it would be nice to do in a HF I think, to try and get wallets to conform selection algos at the same time
-
UkoeHB
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
-
ArticMine
Time for next meeting?
-
UkoeHB
Oct 10 or 17 at 1700 UTC?
-
jberman
In for that
-
monerobull[m]
1 or two weeks, what do you guys think
-
rbrunner
2 weeks seems fine to me
-
ArticMine
October 17
-
monerobull[m]
Sounds good, ill gather feedback for the removal of timelocks till then.
-
monerobull[m]
Thanks for taking the time everyone, have a nice day. Next meeting in 2 weeks.
-
ArticMine
Thanks
-
utxobr[m]
<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
-
rottenstonks
15-17 ring size bump, bp+ and what else? temporary hardfork wen sir?
-
UkoeHB
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
-
UkoeHB
looks like stoffu did most of the review for the original implementation
-
ArticMine
<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
-
monerobull[m]
-
monerobull[m]
should i edit anything?
-
ArticMine
I would add a link to the meeting logs
-
ArticMine
This can be done in a comment anyway
-
jberman[m]
Also link to the original github issue:
monero-project/research-lab #78
-
rottenstonks
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.
-
rottenstonks
any consensus on ring size bump number? 15, 17, 22, 24?
-
rottenstonks
wownero runs fixed 22 ring size since inception, no issue, fwiw.
-
dEBRUYNE
<monerobull[m]> Would it be possible to aim for something like a saturday?
-
dEBRUYNE
Preferably the date is during the week, as services have less staff available on weekends typically
-
rottenstonks
<dEBRUYNE> Preferably the date is during the week, as services have less staff available on weekends typically
-
rottenstonks
+1
-
monerobull[m]
Yeah i guess that's true.
-
carrington[m]
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.
-
carrington[m]
-
carrington[m]
I'll add more links if I spot anything relevant in the next 2 weeks
-
rottenstonks
tks carrington[m].
-
binaryFate
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 :)
-
moneromooo
Thanks :)
-
rottenstonks
niiiice.
-
» rottenstonks gets selsta a beer
-
selsta
yay
-
rottenstonks
selsta: IPA or light beer?
-
» rottenstonks creates #monero-beer channel
-
escapethe3ra[m]1
-
sethsimmons
<binaryFate> "The core team together with..." <- Great to hear it!
-
escapethe3ra[m]1
<binaryFate> "The core team together with..." <- Besides this good news, anything else worth reporting from today's dev meeting? I'm very tired today.
-
gingeropolous
looks like an awesome meeting! i like the ringsize 22 / binning solution
-
rottenstonks
gingeropolous!
-
rottenstonks
-
rottenstonks
escapethe3ra[m]1: some links on the bottom are clickable and some others are not. 11, 12, 13 are... fyi.