16:14:49 <m-relay> <r​ucknium:monero.social> MRL meeting in this channel in 45 minutes
17:00:51 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/970
17:00:57 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:01:02 <m-relay> <v​tnerd:monero.social> Hi
17:01:07 <rbrunner> Hello
17:01:42 <m-relay> <h​into.janaiyo:matrix.org> hello
17:03:27 <m-relay> <r​ucknium:monero.social> jeffro256: Ping because you have items on the agenda
17:03:33 <m-relay> <j​effro256:monero.social> Howdy
17:03:37 <m-relay> <j​effro256:monero.social> Thanks 4 ping
17:03:50 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:05:09 <m-relay> <r​ucknium:monero.social> me: OSPEAD. I did some preliminary calculations of the privacy impact of a transition period to a new decoy selection algorithm without a hard fork. The numbers do not look as bad as I expected.
17:05:34 <m-relay> <v​tnerd:monero.social> Me: finished some zmq hardening stuff in lws, and switched to updating an old Dane/TSLA branch for wallet verification. Not sure if anyone will use it, but it allows tls cert verification via dnssec instead of root ca
17:07:37 <m-relay> <j​effro256:monero.social> me: working on changes to seraphis lib that would make the new transaction class more non-malleable, and combining serialization processes of old and new txs
17:08:51 <m-relay> <h​into.janaiyo:matrix.org> working on cuprate's db still - i believe i've found a potential data race in `monerod`'s db code and wanted some opinions
17:08:56 <m-relay> <r​ucknium:monero.social> jeffro256: Are Seraphis txs more or less malleable than current Monero txs?
17:09:03 <m-relay> <0​xfffc:matrix.org> me: done with the rw lock. I am starting to look at lmdb backend for wallet.
17:10:22 <m-relay> <h​into.janaiyo:matrix.org> i will create a more clear issue on it in the core repo later today - i'm eating right now :)
17:10:42 <m-relay> <j​effro256:monero.social> Nothing to do with an inherent Seraphis property, just how fields are coded in the Seraphis PoC. I have the same issue with the format that `rctSigsPrunable` has where some fields are redundant and don't effect serialization and identification, which can lead to subtle future bugs
17:12:21 <m-relay> <r​ucknium:monero.social> 3) Discussion
17:12:25 <m-relay> <j​effro256:monero.social> 0xFFFC: I can't tell you what to do, but I personally wouldn't recommend trying to add lmdb to wallet2 since most of that work will be scrapped in the near future with the seraphis wallet
17:14:01 <m-relay> <j​effro256:monero.social> Would anyone like to discuss point 4 about making `get_adjusted_time()` monotonic when there's no reorgs?
17:14:17 <m-relay> <j​effro256:monero.social> It requires a hardfork BTW
17:14:21 <rbrunner> Ah, ok, "wallet" does not yet have an LMDB backend of course. Should probably be discussed further, yeah
17:14:46 <m-relay> <r​ucknium:monero.social> Yes. Any hint why it was set to be non-monotonic in the first place?
17:15:03 <m-relay> <r​ucknium:monero.social> And what do other blockchains do?
17:15:32 <m-relay> <j​effro256:monero.social> There's this comment in the code:
17:15:41 <m-relay> <j​effro256:monero.social> > // return minimum of ~current block time and adjusted median time
17:15:41 <m-relay> <j​effro256:monero.social> > // we do this since it's better to report a time in the past than a time in the future
17:17:10 <m-relay> <j​effro256:monero.social> Sounds like their rational was that it would be better that unlock_time'ed outputs stay locked for longer? I don't really understand the motivation behind it
17:17:30 <m-relay> <j​effro256:monero.social> Other blockchains don't have an unlock_time like we do ;)
17:18:04 <rbrunner> Maybe a dumb question, but is anything of your proposal still revelant after unlock_time is gone?
17:18:10 <m-relay> <r​ucknium:monero.social> But don't they use median timestamps for things? And Alex said last week that bitcoin has them
17:18:18 <m-relay> <0​xfffc:matrix.org> I use your advice actually. Thanks. I will contact you to talk about this in detail.
17:18:47 <rbrunner> IMHO chances look good that we can get rid of that feature after all
17:19:23 <m-relay> <j​effro256:monero.social> No, `get_adjusted_time()` only affects unlock_time'ed txs
17:19:53 <m-relay> <r​ucknium:monero.social> Is it irrelevant for the 60 block lock on coinbase outputs since that lock uses block height, not timestamps?
17:20:23 <m-relay> <j​effro256:monero.social> Yes we use median timestamps for bounding new timestamps and calculating difficulty, but we use a separate algorithm (`get_adjusted_time()`) for unlocking outputs
17:21:13 <m-relay> <j​effro256:monero.social> Yes it is irrelevant for coinbase outputs since their unlock_time is always less than 500 million, so it gets interpreted as a block height, not a timestamp
17:21:23 <m-relay> <j​effro256:monero.social> Original PR is here btw: https://github.com/monero-project/monero/pull/6745
17:21:59 <rbrunner> Ah, it's not even for *all* such timelocks, only really for the timestamp based ones? That looks pretty unimportant, then, IMHO
17:21:59 <m-relay> <v​tnerd:monero.social> 0xFFFC: the wallet was never converted to lmdb because of lack of encryption. I know hyc mentioned adding encryption support to lmdb, but I don't know what happened to that
17:22:38 <rbrunner> And as as said, let's nuke those locks anyway :)
17:23:04 <m-relay> <0​xfffc:matrix.org> Yes. I talked to him. He actually added encryption capability just to address this I believe.
17:23:36 <m-relay> <a​lex:agoradesk.com> Here's the BIP for OP_CHECKLOCKTIMEVERIFY if y'all need it
17:23:43 <m-relay> <a​lex:agoradesk.com> https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
17:24:11 <m-relay> <j​effro256:monero.social> Yes, only for timestamp-interpreted unlock_times. However, we are still honoring the time locks, even if we remove them from further transactions. This change would make it easier for seraphis wallet implementors to confidently provide support for timestamped unlocking of legacy outputs without as much logic
17:25:16 <m-relay> <0​xfffc:matrix.org> jeffro256: what about adding lmdb storage directly to seraphis wallet?
17:25:17 <m-relay> <j​effro256:monero.social> The change itself would be pretty tiny in scope, but it would  make the behavior of the small existing timestamp locked outputs more standard
17:25:44 <rbrunner> I thought you can count existing timestamp based lock on the blockchain on a single hand? Don't have a link ready however
17:25:46 <hyc> LMDB encryption support was added ~4 years ago
17:25:56 <m-relay> <j​effro256:monero.social> I'm certainly in favor of adding LMDB support to the seraphis wallet, especially the enote store at some point in the future (as long as it can be encrypted)
17:26:05 <hyc> all that was left was to find someone to do the wallet code rewrite
17:26:25 <m-relay> <0​xfffc:matrix.org> hyc thanks \o/
17:26:57 <m-relay> <r​ucknium:monero.social> If I understand the unlock time behavior, about 14 txs have used the unix timestamp lock method since the Aug 2022 hard fork: https://github.com/monero-project/research-lab/issues/78#issuecomment-1944249619
17:27:20 <hyc> ah, I'm wrong. added it in 2017. 7 years ago.
17:27:29 <m-relay> <r​ucknium:monero.social> rbrunner: You will need 3 hands
17:27:37 <rbrunner> I see, yes :)
17:27:44 <m-relay> <0​xfffc:matrix.org> Great. Let catch up about this in detail in private discussion. I am done with rwlock. And looking for this to start working on.
17:28:18 <ofrnxmr> Rwlock is 9181?
17:28:21 <rbrunner> I humble propose to not loose another minute of jeffro256's precious time on those then. No problem if they unlock a day too early, if you ask me ...
17:28:54 <m-relay> <0​xfffc:matrix.org> ofrnxmr yes
17:28:55 <m-relay> <j​effro256:monero.social> Just want to point out, since I haven't yet, that the monotonic change would be a -2, +1 line change
17:29:24 <m-relay> <j​effro256:monero.social> Actually a little more since we need to check HF version, so it would be like 5 lines total changed
17:30:00 <rbrunner> And no "shooting into foot" during the 1 day hardfork transition period?
17:31:12 <m-relay> <j​effro256:monero.social> Shouldn't be, since we aren't asserting rules about txs coming into the mempool, just changing how we interpret already on-chain txs, it shouldn't even need a transition period. But I'll double-check that
17:32:04 <rbrunner> Those 14 txs do get a lot of attention :)
17:36:24 <m-relay> <j​effro256:monero.social> lol yeah edge cases tend to do that. IMO tho, it should be a very targeted and non-controversial change. The absolute delta in unlock time in terms of real-life time should be very small (~10 minutes in worst case), but it helps weird mempool behavior where a transaction is valid and then it temporarily isn't, with no control by user spending those funds or using them as decoys
17:37:34 <m-relay> <j​effro256:monero.social> Also, if we choose to move forward and ban future transactions from having non-zero unlock_time, you can bet that new people will construct just to say that they did for fun
17:38:39 <rbrunner> May be yes.
17:39:40 <rbrunner> Work is done, or almost so, we may well pull it through ...
17:41:18 <m-relay> <r​ucknium:monero.social> The decoy issue is a good point. The recipients of the timelocked txs might not try to spend in that narrow problem window, but other users may the outputs as decoys.
17:42:30 <rbrunner> So the "waiting for next hardfork" queue will get 1 entry more
17:43:48 <m-relay> <r​ucknium:monero.social> jeffro256: You had two other issues to discuss.
17:44:32 <m-relay> <j​effro256:monero.social> Another edge case! Disallowing any and all v1 transactions
17:44:59 <rbrunner> Sounds a bit heavier as an issue then
17:45:57 <rbrunner> That would not lead to any enotes unspendable? Just spendable in a different way?
17:47:18 <m-relay> <j​effro256:monero.social> v1 transactions are still allowed when one is spending "dust" amounts and the number of total global outputs with that amount is less than the ring size. This was a good exception when MLSAGs needed at least 2 ring members, but we don't need this rule with CLSAGs, since you can make a ring with 1 member (correct me if wrong). The problem with allowing v1 transactions is that the t<clipped messag
17:47:19 <m-relay> <j​effro256:monero.social> ransaction outputs aren't hidden amounts, so the sender privacy chaining from those transactions is bad
17:49:26 <rbrunner> So you get as many rings as dust enotes to spend?
17:49:39 <rbrunner> Just rings of size 1?
17:49:45 <m-relay> <j​effro256:monero.social> Yes
17:50:45 <rbrunner> Don't know enough to really assess, but doesn't sound too bad to me
17:51:54 <rbrunner> But again, if there are so few such transactions now, the privacy degredation also is nothing wild, I guess
17:51:56 <m-relay> <a​lex:agoradesk.com> By the way, jeffro256 , would the timelock puzzle you proposed last week be trustless? In the sense of, how would the recipient of the timelock puzzle not be able to claim that we solved the puzzle ourselves and took the coins back?
17:52:49 <m-relay> <r​ucknium:monero.social> This is a privacy improvement for those txs? Would those txs eventually be all spent (if the users did not lose the keys), so the issue slowly disappaers?
17:55:42 <m-relay> <j​effro256:monero.social> Alex | LocalMonero | AgoraDesk: I would have to look more carefully, but I assume you would do it the same way coins are transferred to someone's stealth address and they can't claim that you stole them: by adding one of their public keys to the destination point. If only they know their private key to that address, if you add that point to the on-chain destination, you need to al<clipped messag
17:55:42 <m-relay> <j​effro256:monero.social> so know the private key of the address to know the private key of the on-chain destination
17:56:22 <m-relay> <a​lex:agoradesk.com> Got it.
17:56:52 <m-relay> <j​effro256:monero.social> Those txs will eventually all be spent, yes
17:58:41 <rbrunner> Hmmm ... I guess that would take considerably more than 5 lines to change and add
17:59:02 <m-relay> <r​ucknium:monero.social> I don't know if the risk is worth the reward. Privacy benefit for a very small number of txs, but a possible protocol risk of making them unspendable.
17:59:07 <rbrunner> And more time for testing
17:59:09 <plowsof> sigh 
18:00:26 <m-relay> <j​effro256:monero.social> Even if we don't change the consensus rules, it would probably be a good idea to refactor `wallet2::create_unmixable_sweep_transactions()` so that it doesn't create v1 transactions by default for users who are just using that command
18:01:00 <m-relay> <j​effro256:monero.social> The consensus code changes would also probably be about 5 lines tho
18:01:06 <rbrunner> :)
18:02:15 <rbrunner> I just hope that very soon you will run out of such edge cases to unearth. A mountain of coding for Seraphis and Jamtis is waiting
18:02:56 <rbrunner> Certainly worth to have a good look at any of them, but not to automatically act and remove then, IMHO
18:04:14 <rbrunner> Not sure who would feel tempted to use a method called `reate_unmixable_sweep_transactions`, but well, strange things happen
18:04:16 <m-relay> <j​effro256:monero.social> Well okay we can move onto the third topic then: changing the condition under which we switch to alternative chains
18:04:26 <m-relay> <r​ucknium:monero.social> We'll end the meeting here. jeffro256 's third item can go into next meeting.
18:04:34 <m-relay> <j​effro256:monero.social> kk
18:04:45 <m-relay> <0​xfffc:matrix.org> Thanks everyone
18:05:10 <rbrunner> +1
18:05:25 <m-relay> <j​effro256:monero.social> rbrunner7: It's accessible by running the `sweep_unmixable` command
18:05:28 <m-relay> <j​effro256:monero.social> Thanks everyone
18:05:39 <m-relay> <j​effro256:monero.social> I appreciate the time and discussion
19:38:45 <m-relay> <h​into.janaiyo:matrix.org> `monerod` db data race I mentioned earlier, comments appreciated - I assume I'm missing outer context that makes this impossible https://github.com/monero-project/monero/issues/9193