MRL meeting in this channel in 1.5 hours. I hope the monero.social Matrix server is fixed in time for the meeting. Thanks, admins :)

<a​lex:agoradesk.com> Ready.

<a​lex:agoradesk.com> Sending from Matrix. Message visible? Please confirm.

Pong

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

<d​angerousfreedom:matrix.org> Alex | LocalMonero | AgoraDesk: Yes

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

<d​angerousfreedom:matrix.org> Hi

<a​lex:agoradesk.com> hi

<j​effro256:monero.social> Howdy

Hello

hi everybody

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

<r​ucknium:monero.social> me: OSPEAD. And some empirical analysis of unlock time...posting....now

<j​effro256:monero.social> Working on seraphis tx serialization

me: locking mechanism for blockchain.cpp

<r​ucknium:monero.social> Discuss: Removing/Fixing/Encrypting monero's timelocks monero-project/research-lab #78

I can give a short report about my contribution, a Reddit post: old.reddit.com/r/Monero/comments/1a…us_finally_retire_a_rarely_used_and

<r​ucknium:monero.social> We don't have to decide on time locks today. I hope we can finish discussion by 18:00, but if we really need it we can extend the time to 18:30 at teh most.

Thanks for current usage stats Rucknium

The post got a fair share of attention and comments. Noteworthy are the 99% upvotes

I didn't actually count, but I would guess 8 or even 9 out of every 10 comments are pro removal

IMHO nothing really surprising surfaced, e.g. a novel use of timelocks that so far nobody ever thought of

<r​ucknium:monero.social> Here are the usage stats and some estimates of the privacy impact on users who are creating txs with custom lock times: monero-project/research-lab #78#issuecomment-1944249619

Well, that's not a guess, more of an estimate about reading everything

<a​lex:agoradesk.com> If I may, I'd like to point out how we use timelocks occasionally and how to us it's a good feature.

<a​lex:agoradesk.com> Sometimes, we ban a certain user permanently from our platform. Sometimes, that user tries to return to the platform. We catch them and warn them not to return again or there will be consequences.

<r​ucknium:monero.social> On usage, I have findings that are similar to what TheCharlatan found many years ago. 95% of custom unlock times have no effect since the wallet developer(s) do not understand that block height is absolute. And I have new findings on the privacy impact. The real spend can be correctly guessed in 34-91% of the custom unlock times that I evaluated.

<a​lex:agoradesk.com> They ignore us and return to our platform. In these cases, we take the XMR that they placed in the arbitration bond and send it to them in a timelocked transaction to disincentivize them from trying to return again.

<a​lex:agoradesk.com> It's quite effective.

<j​effro256:monero.social> It could be that the developers DO understand that the height is absolute, but they're putting other meta information in that field

USDT can even close accounts. Also effective lol

The fact that you can punish people (deserving or not) is terrible

<r​ucknium:monero.social> So this is a "light punishment" use of custom unlock time. Instead of extreme punishment of not sending them any XMR at all.

Well, that does have a novel edge, as far as I am concerned

<r​ucknium:monero.social> Could there be a compromise? Maybe wallet2 can consider custom-locked outputs as "not received" by default. Depends on how much other wallets follow wallet2 I guess.

But anyway, I think we should be careful, it's not only the question whether those timelocks have uses - they have - but whether they are net positive

<a​lex:agoradesk.com> Additionally, I can think of cases where a person might know ahead of time that they will be entering a dangerous situation (travel, jail, mandatory conscription, etc) and want to ensure that their coins will not be spent until they are out of the situation, so they send themselves a timelocked tx.

<j​effro256:monero.social> localMonero's use case can be replicated by choosing to send the funds later or sending to a time lock puzzle

<j​effro256:monero.social> That use case too can also be solved with a time lock puzzle

Yeah, and like the use case with rents, subscriptions and similar pay-ahead things: Very dangerous if circumstances change, and the XMR absolutely can't

<a​lex:agoradesk.com> Choosing to send the funds later is quite problematic as the person might start to claim that we never intend to send them and start some sort of reputation damaging action. A timelocked tx prevents that.

<j​effro256:monero.social> You could send the funds to them in a time lock puzzle and prove that thr y will be able to access the funds after s bounded amount of computation

<a​lex:agoradesk.com> The main concern with timelocks is that it's tx-based and not output-based, which, I agree, can lead to serious problems if the person utilizing them is not aware of this and doesn't send the desired timelock to a separate wallet first to ensure separation.

Well, can't they claim coercion, which also can be an offense, and damage your reputation nevertheless?

<a​lex:agoradesk.com> Their claim won't have credit since there are records of them being banned and warned not to return.

<a​lex:agoradesk.com> You'll have to PM me with the details about the time lock puzzle, not sure how to implement it.

You have the same records if you just send them later ... but whatever.

Wheres the sense of power/control in that?

<a​lex:agoradesk.com> We have the same records, but while the coins are with us the person can still claim we're just keeping them. With a timelocked tx they can't.

<d​angerousfreedom:matrix.org> Are you aware of someone applying it in Monero?

Fair enough.

The way I see the matter after reading the comments on Reddit and on jeffro256's PR monero-project/monero #9151: Yes, there are certainly usecases, but for me they in no way outweigh the negatives

<j​effro256:monero.social> The main concerns with time locks for 99.9% users is that 1) receiving time locked funds leads to confusion why it isnt spendable 2) you can't pick locked decoys which degrades on chain privacy and makes making non fingerprint able decoy selection harder 3) you cant pick locked decoys which can open you up to privacy attacks from an untrusted daemon 4) it makes transactions less u<clipped messag

<j​effro256:monero.social> niform which degrades on chain privacy

By the way, I reviewed that PR, looks good, it would probably no problem to activate it

(technically)

<a​lex:agoradesk.com> I also disagree over the notion that this is especially unintuitive for developers. Even bitcoin has timelocks. It may be a question of a lack of documentation, but to me it seems rather weird that a developer scanning for deposits to the wallet using the JSON-RPC would just completely ignore the "unlock_time" parameter staring right at him. Perhaps the dev is very inexperienced.

<r​ucknium:monero.social> jeffro256: Isn't (2) and (3) true for coinbase txs, which have a 60 block lock? I checked a few block heights. The share of the probability mass of the decoy selection algorithm "blocked" by coinbase lock time is 0.2% to 2.0%

<j​effro256:monero.social> No but you could do this completely off-chain, no hacky consensus rules required

<a​lex:agoradesk.com> The unintuitive part is that the lock is per TX as opposed to per output.

<r​ucknium:monero.social> ^ At least one Monero payment channel proposed protocol uses time lock puzzles. Did they write the code to implement it? I don't think so.

Some devs use monero libraries which may not unlock_time aware

<j​effro256:monero.social> Yes

"unintuitive" is a very mild name for a completely braindead and borderline-unusable design, IMHO

The problem with this PR not disabling with a hardfork is that devs are more likely to not care about unlock_time

Well, that's probably a separate discussion, should be reach consensus to remove the feature at all

*should we

<j​effro256:monero.social> However, if you were going to use a feature which picks non-coinbase anyways like that PR I wrote, you would be able to tell where an output is coinbase unlocked before you even request it based on its height

<a​lex:agoradesk.com> I'm not here to say that timelocks are essential, I'm merely offering our usecase for it, as it seems that nobody else could come up with usecases.

<a​lex:agoradesk.com> If jeffro256 could explain to me how to implement the time lock puzzle then our usecase won't be relevant anymore.

Mochi101 recently found many big instant swap sites unaware of unlock time. We then added a red warning to the rpc docs

<r​ucknium:monero.social> FWIW, the privacy problem scales up with usage. Right now usage of custom unlock time is very low. Nonstandard txs fees, which about 5% of txs use now I think, are a much bigger problem.

Nobody indeed came up with that, as far as I could see. But earlier discussions are full of mentions of "self discipline" approaches, for example

Or as already mentioned subscriptions, regular "payouts" (unlocking in waves, so to say) cases

But that's about it.

For me localmonero being able to punish people is precisely a reason to remove it

lol

<r​ucknium:monero.social> The ability to punish can promote good outcomes. That's about half of game theory.

<a​lex:agoradesk.com> With respect to big instant swap sites, their devs are probably subpar. Seeing the unlock_time in the API is trivial and given that timelocks are present most cryptos it's not something that they'd never think about. Sounds like a bad library or something.

The best use case for unlockntime.isnt going to "save" it if its provably broken and bad for privacy

Sure. If all were roses with timelocks except that subpar devs don't understand them, then yeah, let's start an education push. But that's not the case.

<j​effro256:monero.social> If I find a library that does it already I will send it to you. The general idea behind the math is pretty simple tho: you basically just make a small RSA ring and then try to brute force the secret key. It can be provable before you do it that there is 1 solution because of the way RSA is structured

<a​lex:agoradesk.com> Yeah it's not like we're out to get people. We just want various types of exploiters to stay away from our platform. This is a minimally invasive and soft way of effectively doing it.

<a​lex:agoradesk.com> Our devs were aware of timelocks in XMR from the getgo, way back in 2017. So are most devs I feel. Again, I'm not here to judge people, and I agree that simpler is better. I'm just saying that timelocks are not weird in crypto.

<r​ucknium:monero.social> It sounds like we may have a viable compromise if a time lock puzzle protocol is implemented for Monero. (But that costs labor time.)

<a​lex:agoradesk.com> Now, just because something is not weird in crypto doesn't mean it's desireble in XMR

Maybe it turns out like with those "Mordinals": On our own we couldn't reach consensus about removing or limiting tx_extra. It took an actual attack to move us.

Even the argument that subpar devs are unaware of it doesnt matter.. it is broken and bad for privacy

Maybe somebody should send around thousands of timelocked dust transactions to all ecosystem players ...

<r​ucknium:monero.social> Does Bitcoin or its cousins have the same type of time lock as Monero? They have a different type, I know. But they also have one like Monero?

<a​lex:agoradesk.com> That's fine. I'm cool with the removal. The simplicty and privacy of the XMR protocol is more important than our use case. I just wanted to mention it.

I don't know, but you would think there must be stories like locking for thousands of years by accident then, which I *never* heard

<r​ucknium:monero.social> rbrunner: I don't think dust amounts will matter much. The problem happens when you think you have a legitimate large payment for something and take action based on that false belief.

<a​lex:agoradesk.com> There's a per-address timelock. Meaning you send BTC to a p2sh address where the script says you can only spend the coins at this address after a certain time.

<r​ucknium:monero.social> rbrunner IIRC, you can only lock for 4 years maximum without re-compiling the binaries. So, it's hard to do accidentally

Yes, it would need a dedicated attacker, just any script kiddie won't do

Anyway, I surely hope that we will reach consensus on our own this time, without anything bad happening first of course

<r​ucknium:monero.social> Maybe a year ago someone said they were paid 10's of XMR in a locked tx. In #monero I think. It's not just a theoretical risk.

I think that non-consensus on tx_extra limits are forever in the blockchain in the form of a few gigabytes of Mordinals rubbish :)

<r​ucknium:monero.social> plowsof, do you remember?

It was an owner of a swap site iirc .. basically a competitor draining their reserves

<a​lex:agoradesk.com> This exact exploit was an immediate consideration for us when we were originally developing our platform. It's trivial to sidestep - just read `unlock_time`.

<r​ucknium:monero.social> libera.monerologs.net/monero/20230119#c191161 "Hello everyone, I have an exchanger connected to a Monero server. 2 days ago, I saw that 133 Moneros were blocked in my account for a period of 4 years. How is this possible?"

Was btcpaysever unlock time unaware

<r​ucknium:monero.social> AFAIK, we have no guides about how to make a Monero wallet.

<r​ucknium:monero.social> From what I have seen, I would guess that most "third-party" code that receives XMR isn't aware of lock time. Or at least that was the state a year+ ago.

Well, as I said, even with perfect documentation and no more subpar devs around ever timelocks *still* have grave problems

<a​lex:agoradesk.com> Yeah, a unified guide of "what to worry about when integrating XMR" would solve most of this I think.

<a​lex:agoradesk.com> However, rbrunner is right. If it's a hazard to privacy it should be removed, just like tx_extra.

The use cases are motivation for a fixed/real solution

<d​angerousfreedom:matrix.org> I never used timelocks so my opinion is irrelevant but I would be in favor of disabling it (for the sake of privacy) for future transactions but not void the current ones that uses it. I think a robust and easy to use multisig would fix many of the timelock issues. One could simply trust a 3rd party (which could be himself) to relay his tx when the time comes. Another example woul<clipped me

<d​angerousfreedom:matrix.org> d be using google that offers the possibility to send messages after some inactivity time in your account. So basically there are many ways to handle when to send a transaction in the future that dont need to be on-chain.

That discussion with the victim of the locked XMR on monerologs.net is gold ...

Maybe we should use the remaining regular 10 minutes of meeting time for an attempt to find out where we stand, and where we go from here, i.e. after this meeting?

<r​ucknium:monero.social> One or both of Trezor and Ledger had an unlock time "vulnerability".

<a​lex:agoradesk.com> I think that existing timelocks should be honored, but for the sake of simplifying XMR and strengthening privacy they should be removed, assuming that time lock puzzles are a practical solutions as jeffro256 says.

In any case, as mentioned, at least coding is almost done. A second review would probably be good.

<j​effro256:monero.social> I'm of the same opinion: no more new non-zero tx unlock times, but honor the old unlock times.

<r​ucknium:monero.social> I don't think we should ask jeffro to implement time lock puzzles because he is working on tasks with higher priority. But if we could have the off-chain time lock puzzles working, that would be a good compromise.

Ditto

<a​lex:agoradesk.com> Not honoring the existing timelocks will lead to a crisis of confidence. If the XMR protocol won't honor one contract, why would it honor others?

Yes. I don't think anybody voted for removing all locks, period.

The "Free the locked XMR" movement :)

<j​effro256:monero.social> I wanted to talk about a slight change to the unix-time-based unlock times: Secondly, I want to toss up the idea of a small modification to the consensus rules also related to the unlock time. In short, I want to make Blockchain::get_adjusted_time() monotonic (barring reorgs) on the next network upgrade. The reason for this is that if you have time-locked outputs in your input rin<clipped messag

<j​effro256:monero.social> gs, decoy or true-spend, and you send a transaction into the mempool, it may be accepted now but actually be invalid for several blocks based on the timestamps of the new blocks on top of the chain pushing the value of Blockchain::get_adjusted_time() into the past. This is because of these lines: github.com/monero-project/monero/bl…28a30a8ae9752338a7897329fe8012a310d<clipped messag

<j​effro256:monero.social> 5/src/cryptonote_core/blockchain.cpp#L4029-L4035. They take into account the latest block timestamp instead of only the median timestamp, and take the minimum between them. If we only make the adjusted time a function only of the median timestamp, we will have a monotonic clock since the median timestamp increases monotonically. This means that if any transaction output is unlocke<clipped messag

<j​effro256:monero.social> d now, it will always be unlocked in the future if there isn't a reorg.

<j​effro256:monero.social> From this comment: monero-project/meta #966#issuecomment-1936243293

<j​effro256:monero.social> It might not be worth the effort, but it make the behavior of the like 8 locked transfers more reliable

Maybe xFFFC0000 would be ready to look into these puzzles? So jeffro256 can continue with his indeed essential things.

Sure. I can take a look. But keep in mind mooo asked me to take a look at locking for blockchain.cpp and I am right now working on fixing locking mechanism on blockchain.cpp. Right after than I can jump into the puzzle thing. which should not take long.

Nice.

<a​lex:agoradesk.com> Thanks for taking care of our usecase guys <3

All in all, things look a lot less controversial than back then with tx_extra. Maybe we will succeed this time.

<r​ucknium:monero.social> Would monotonic block time help anything else besides unlock time? And "Median timestamp increases monotonically" is that because of consensus rules on how much mined blocks' timestamps can differ from neighboring blocks?

<j​effro256:monero.social> No. Yes

<r​ucknium:monero.social> AFAIK, the downside of time lock puzzles is that time-to-solution depends on CPU speed, so it's not as precise as depending on block height. But for a "punishment" use case, that is probably not a problem.

<j​effro256:monero.social> new incoming block timestamps cannot be less than the median of the last 60, which increases median of the next 60

<j​effro256:monero.social> Yes for punishment and self-control use cases, which is most, the time doesn't have to be exact IMO

<r​ucknium:monero.social> I think we don't have to extend the meeting time. The result is that xFFFC0000 will evaluate implementing an off-chain time lock puzzle as a compromise, when he has time.

<j​effro256:monero.social> There's another couple of things id like to discuss if people are willing

<j​effro256:monero.social> From that same comment I linked: Thirdly, I'd like to discuss disallowing v1 transactions for "unmixable" input amounts in the next network upgrade. The reason for this is that the output amounts of v1 transactions obviously aren't confidential, which reduces overall network privacy. And since CLSAG signatures can still work on a ring of size 1, this shouldn't lead to anyone havin<clipped messag

<j​effro256:monero.social> g their dust locked like with MLSAG signatures. There have only ever been 462 v1 transactions since Hardfork v6 in September 2017 as of the time of this writing.

<r​ucknium:monero.social> Ok we can continue

Looks like stuff for a handful of meetings, if done carefully, IMHO.

<j​effro256:monero.social> We can end the meeting officially and discuss this laster

<r​ucknium:monero.social> Ok. --- Meeting end ---

<j​effro256:monero.social> Thanks everyone

For the record, I did not ask xFFFC0000 to look at locking. xFFFC0000 asked for ideas I thought would be good to work on. I'm perfectly ok if something else is done instead.

I confirm.

<v​tnerd:monero.social> Sorry for missing the meeting today - I've been working on "hardening" the ZMQ message handling in LWS. I put the trust-on-first use in the wallet off for now (until another PR gets merged)

thanks for doing that zmq stuff

<v​tnerd:monero.social> the hardening hit a blocker on it not really being completely feasible either, without some more painful changes

i notice crashes

<v​tnerd:monero.social> in LWS?

yep

I mentioned them on GitHub

been happening for a couple years now

i'm not sure if it's my OS configuration .. but I saw others reported the same issue

<v​tnerd:monero.social> ok lets keep that discussion to github, and not in this research room (slightly off topic)

then why mention it lol

you often talk about lws here

do you know what I would really be curious about as far as research goes is investigating an actual solution for some of the spend patterns that are not safe yet quite justified in Monero

i've also talked about those on GitHub

I mentioned it years and years ago that this would be an issue and we also have issues with time locks

Yeah, when I brought up things like the dlsag and paymo research before

the founder of a competing scriptable privacy coin replied to me with a bunch of bs then ghosted

sadly others bought it i think

it was odd timing, all of that. i wonder why we dont get excited hearing about that research

i think the demand is clear

i also think it's likely the next step for any privacy coin to be able to handle some of the unsafe justified spend patterns

yet quite -> yet but quite

a bunch of bs , that is, discouraging monero from pursuing that line of development

like, what a surprise

he claimed it wasnt something monero ought to try to solve

clearly, private partial scriptability on some order *is* the solution

it's amazing how people claim that they're not trying to dictate the direction of the technology when the facts clearly disagree

we can take the slow way there by ignoring emerging new techniques and generate even more metadata to analyze later - or we can wake up

personally i dont like having the project stolen away from the actual people by those who actually have conflicts

not that anyone here gives a sh anymore

those people running some competitor ICO aren't gonna show back up here and say oh sorry guys we were just kidding, we just said that to delay you, so that our shit would seem more initially competitive

and that's all it takes to kill a project unfortunately sometimes

probably too late anyway