<r​ucknium:monero.social> MRL meeting in this channel in 45 minutes

<r​ucknium:monero.social> Meeting time! monero-project/meta #970

<r​ucknium:monero.social> 1) Greetings

<v​tnerd:monero.social> Hi

Hello

<h​into.janaiyo:matrix.org> hello

<r​ucknium:monero.social> jeffro256: Ping because you have items on the agenda

<j​effro256:monero.social> Howdy

<j​effro256:monero.social> Thanks 4 ping

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

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

<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

<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

<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

<r​ucknium:monero.social> jeffro256: Are Seraphis txs more or less malleable than current Monero txs?

<0​xfffc:matrix.org> me: done with the rw lock. I am starting to look at lmdb backend for wallet.

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

<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

<r​ucknium:monero.social> 3) Discussion

<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

<j​effro256:monero.social> Would anyone like to discuss point 4 about making `get_adjusted_time()` monotonic when there's no reorgs?

<j​effro256:monero.social> It requires a hardfork BTW

Ah, ok, "wallet" does not yet have an LMDB backend of course. Should probably be discussed further, yeah

<r​ucknium:monero.social> Yes. Any hint why it was set to be non-monotonic in the first place?

<r​ucknium:monero.social> And what do other blockchains do?

<j​effro256:monero.social> There's this comment in the code:

<j​effro256:monero.social> > // return minimum of ~current block time and adjusted median time

<j​effro256:monero.social> > // we do this since it's better to report a time in the past than a time in the future

<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

<j​effro256:monero.social> Other blockchains don't have an unlock_time like we do ;)

Maybe a dumb question, but is anything of your proposal still revelant after unlock_time is gone?

<r​ucknium:monero.social> But don't they use median timestamps for things? And Alex said last week that bitcoin has them

<0​xfffc:matrix.org> I use your advice actually. Thanks. I will contact you to talk about this in detail.

IMHO chances look good that we can get rid of that feature after all

<j​effro256:monero.social> No, `get_adjusted_time()` only affects unlock_time'ed txs

<r​ucknium:monero.social> Is it irrelevant for the 60 block lock on coinbase outputs since that lock uses block height, not timestamps?

<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

<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

<j​effro256:monero.social> Original PR is here btw: monero-project/monero #6745

Ah, it's not even for *all* such timelocks, only really for the timestamp based ones? That looks pretty unimportant, then, IMHO

<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

And as as said, let's nuke those locks anyway :)

<0​xfffc:matrix.org> Yes. I talked to him. He actually added encryption capability just to address this I believe.

<a​lex:agoradesk.com> Here's the BIP for OP_CHECKLOCKTIMEVERIFY if y'all need it

<a​lex:agoradesk.com> github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

<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

<0​xfffc:matrix.org> jeffro256: what about adding lmdb storage directly to seraphis wallet?

<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

I thought you can count existing timestamp based lock on the blockchain on a single hand? Don't have a link ready however

LMDB encryption support was added ~4 years ago

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

all that was left was to find someone to do the wallet code rewrite

<0​xfffc:matrix.org> hyc thanks \o/

<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: monero-project/research-lab #78#issuecomment-1944249619

ah, I'm wrong. added it in 2017. 7 years ago.

<r​ucknium:monero.social> rbrunner: You will need 3 hands

I see, yes :)

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

Rwlock is 9181?

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

<0​xfffc:matrix.org> ofrnxmr yes

<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

<j​effro256:monero.social> Actually a little more since we need to check HF version, so it would be like 5 lines total changed

And no "shooting into foot" during the 1 day hardfork transition period?

<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

Those 14 txs do get a lot of attention :)

<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

<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

May be yes.

Work is done, or almost so, we may well pull it through ...

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

So the "waiting for next hardfork" queue will get 1 entry more

<r​ucknium:monero.social> jeffro256: You had two other issues to discuss.

<j​effro256:monero.social> Another edge case! Disallowing any and all v1 transactions

Sounds a bit heavier as an issue then

That would not lead to any enotes unspendable? Just spendable in a different way?

<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

<j​effro256:monero.social> ransaction outputs aren't hidden amounts, so the sender privacy chaining from those transactions is bad

So you get as many rings as dust enotes to spend?

Just rings of size 1?

<j​effro256:monero.social> Yes

Don't know enough to really assess, but doesn't sound too bad to me

But again, if there are so few such transactions now, the privacy degredation also is nothing wild, I guess

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

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

<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

<j​effro256:monero.social> so know the private key of the address to know the private key of the on-chain destination

<a​lex:agoradesk.com> Got it.

<j​effro256:monero.social> Those txs will eventually all be spent, yes

Hmmm ... I guess that would take considerably more than 5 lines to change and add

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

And more time for testing

sigh

<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

<j​effro256:monero.social> The consensus code changes would also probably be about 5 lines tho

:)

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

Certainly worth to have a good look at any of them, but not to automatically act and remove then, IMHO

Not sure who would feel tempted to use a method called `reate_unmixable_sweep_transactions`, but well, strange things happen

<j​effro256:monero.social> Well okay we can move onto the third topic then: changing the condition under which we switch to alternative chains

<r​ucknium:monero.social> We'll end the meeting here. jeffro256 's third item can go into next meeting.

<j​effro256:monero.social> kk

<0​xfffc:matrix.org> Thanks everyone

+1

<j​effro256:monero.social> rbrunner7: It's accessible by running the `sweep_unmixable` command

<j​effro256:monero.social> Thanks everyone

<j​effro256:monero.social> I appreciate the time and discussion

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