-
m-relay
<rbrunner7:monero.social> Meeting in 50 minutes
-
m-relay
<rbrunner7:monero.social> Meeting time. Hello!
monero-project/meta #1304
-
m-relay
<jberman:monero.social> *waves*
-
m-relay
<sneedlewoods_xmr:matrix.org> hey
-
m-relay
<rbrunner7:monero.social> Alright, let's start with the reports
-
m-relay
<jeffro256:monero.social> Howdy
-
m-relay
<sneedlewoods_xmr:matrix.org> not much, some small local fixes (e.g. review comment from iamamyth), will push when there is more
-
m-relay
<sneedlewoods_xmr:matrix.org> also noted something related to the issue where the CLI prints `Height x / y` in the case when we create a transaction and wait for confirmation,
-
m-relay
<sneedlewoods_xmr:matrix.org> we use `pauseRefresh()` [src](
github.com/monero-project/monero/bl…c/wallet/api/wallet.cpp#L2472-L2479) in `createTransactionMultDest()` [src](
github.com/monero-project/monero/bl…cbe/src/wallet/api/wallet.cpp#L1622), but `m_refreshEnabled` gets set to `true` after a while. IIUIC this<clipped
-
m-relay
<sneedlewoods_xmr:matrix.org> `LOCK_REFRESH()` [src](
github.com/monero-project/monero/bl…e/src/wallet/api/wallet.cpp#L61-L72) macro from jberman may be a better fit do make sure this doesn't happen, testing at this moment
-
m-relay
<sneedlewoods_xmr:matrix.org> nah, didn't work lol
-
m-relay
<jeffro256:monero.social> Made a tweak to Carrot account derivation in the spec
jeffro256/carrot #6, wrote a concrete PQ turnstile design around it
gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243, and implemented it in the C++ lib
seraphis-migration/monero #250
-
m-relay
<rbrunner7:monero.social> Sounds like quite some edge case
-
m-relay
<jberman:monero.social> me: opened a new CCS proposal, continuing investigating sync issues reported in the stressnet channel (a newly reported connection drop issue [244] & slower than expected sync on one of the stressnet participant's machine [246]), then stressnet release v1.5. I didn't have much availability the last week for thanksgiving, back at 100% availability now
-
m-relay
<jeffro256:monero.social> Also sending out quote requests for a carrot_core code audit, so we can get that audit out of the way
-
m-relay
<sneedlewoods_xmr:matrix.org> I think creating transaction is not the only place where this happens, but it's easy to reproduce for not
-
m-relay
<sneedlewoods_xmr:matrix.org> for now*
-
m-relay
<rbrunner7:monero.social> I see
-
m-relay
<rbrunner7:monero.social> jeffro256: Those turnstiles will get important if/when somebody comes along with a working quantum computer? If yes, isn't it awfully early to program something already now? Or is this to verify / prove the design?
-
m-relay
<jeffro256:monero.social> This issue is that if you don't prepare for it now, you can't use it later. The tweaks were relatively small and provable that hashes didn't bind to anything less than they were currently binding
-
m-relay
<jeffro256:monero.social> took a couple hours at most
-
m-relay
<rbrunner7:monero.social> Ah, ok, imagined this quite a bit bigger then
-
m-relay
<jeffro256:monero.social> It would be nice to validate that the design can do what it claims it can tho
-
m-relay
<rbrunner7:monero.social> Yes
-
m-relay
<rbrunner7:monero.social> I saw from discussions over last week that there are still quite differing opinions about the future design of fees and related issues like block size growth limits. Does that hold up anything right now? Guess not.
-
m-relay
<rbrunner7:monero.social> That goes on for quite a while now, no? :)
-
m-relay
<jeffro256:monero.social> Right now? Probably holding up an accurate beta stressnet
-
m-relay
<jeffro256:monero.social> some of the fee policy can be deciding in relay fees, but the scaling rules as it relates to block subsidy penalty need to be decided in consensus
-
m-relay
<rbrunner7:monero.social> And if you change such growth parameters later, that will invalidate tests that you do now.
-
m-relay
<rbrunner7:monero.social> I guess sometimes reaching consensus takes time, it's in the nature of complex questions. I hope that the dust will soon settle.
-
m-relay
<rbrunner7:monero.social> Alright, is there something to discuss beyond these reports?
-
m-relay
<jeffro256:monero.social> Yes, if we want an accurate view of how mainnet will scale, we need to know the paramaters before starting a new stressnet IMO
-
m-relay
<jberman:monero.social> also going to spend some more time focusing on that discussion soonish
-
m-relay
<rbrunner7:monero.social> That would certainly be useful; seems to me not many people have the necessary background knowledge to take part. I certainly don't.
-
m-relay
<rbrunner7:monero.social> I don't know much more than "It's complicated" :)
-
m-relay
<rbrunner7:monero.social> I think we can close the meeting here. Thanks everybody for attending, read you again next week!
-
m-relay
<sneedlewoods_xmr:matrix.org> thank you