Cheers everyone

.

Meeting ~2hr

Hello everyone.

Greetings

Hi

Hello

Hey!

oh hi whoops

hi

meeting agenda: monero-project/meta #669

hey

2. we can start with updates, what is everyone up to?

I've just started unofficially my work yesterday and am dealing with IT-related leftovers, that accumulated while I was working on tsqsim. Nothing related to MRL really.

me: I opened a CCS for Seraphis wallet PoC repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290 and did a bit of work in that direction (added tx_extra and fees to my poc).

I've been working on posting papers to MoneroResearch.info (Reminder: if you want an account to be able to upload and annotate papers, please message me and I will get you set up)

Also I have been working on measuring the proportion on the BCH UTXO set that is a descendant of a CashFusion tx, a type of CoinJoin:

I hope to release results in the next few days

UkoeHB: Your CCS asks for funds for 2 months of work. Is that the result of a rough estimate how long implementing the PoC might take?

Relatedly, if anyone has a more-of-less comprehensive list of all CoinJoin transaction on the BTC blockchain, let me know.

Just got started on hyc 's background sync cache so wallets scan for tx's with just view key + address in the background without needing access to the spend key. Also submitted some PR's to MyMonero/monero-lws to tackle some fee issues that could lead to fingerprinting

rbrunner: yes my best guess

3. today I want to bring up timelocks again (my little proposal: monero-project/research-lab #78#issuecomment-1003195804 ); now would be a good time for me to implement it in Seraphis if it's worthwhile

it's timelocks as a range of block heights where a tx may be mined, enforced with two range proofs (or one range proof if we want an open range)

seems reasonable to me

Why range proofs ? To hide them ?

right

Can't they be brute forced rather trivially ?

how? you use pedersen commitments, just like amounts

Not sure I understand how you can hide heights and still check whether the tx is mineable

Verify the tx with all heights between say, now and now + 50k.

How does this compare to how time locks work on BTC? (It seems to me that they would be very similar, which would be good IMHO.)

you state two nominal heights in clear text, then range proof `hidden_height - clear_height`

the workflow would be: 1) define tx with hidden timelocks, 2) when you want to submit the tx, select two heights nearby your submission height and make a timelock proof (consisting of two cleartext heights and two range proofs)

Ah. I see now.

Rucknium[m]: I forget lol

would every tx add one by default? or just users who want to use a timelock?

So one could see that the tx is timelocked, just not how exactly.

I have not looked into the usecases for good timelocks so... this is also a request for people who want timelocks to step forward

In what cases could this be useful ?

jberman[m]: every tx would add it I think

it's open for debate though

What's again the approximate size of such a range proof?

In bytes I mean

rbrunner: they would be aggregated with other tx range proofs, so only a couple extra 32 bytes

depending on bp+ aggregation cutoffs

Plus 64 for the two commitments.

(presumably)

yeah, and 16 bytes for the cleartext heights (or less if using varints)

IMHO still a tough sell for 0.01% or so of tx which will use the feature if *every* tx gets this, for uniformity

I think it's 64 extra range proof bytes if adding the timelock proofs makes you go over a cutoff

Verification time would be bumped a lot more given it's not log increase.

yes, although batching has a substantial effect

Actually, wait. Maybe not, if it's the multiexp ?

seems like a lot to pay for an infrequently used feature

in the*

can it be added later if we decide it's super important?

sure

Anyway, it'd be nice if if were a biulding block for some second layer thing. Otherwise, meh.

in that case sounds like something to leave out for now

i think there are lots of use cases for it

For swaps and such?

people have chimed in about it to some degree

Atomic swaps

To "go first" with XMR which I think now is not possible

rbrunner: I think only tx chaining is required for that

Are not atomic swaps a long way off at this time?

moneromooo: i think for such a use conditional locks would help much more

timelocks are conditional... what do you mean?

No, I think BTC-XMR swaps are already possible on the mainnets

I think it would make it easier to have bi-directional atomic swaps (i.e. both "buy" and "sell" orders on the "order book", which would improve liquidity greatly, I think. However, there is at least one paper that claims bi-directional Monero atomic swaps without Monero time locks.

And then payment channels get easier, I think. Although again there are claims of possible Monero payment channels without such time locks.

yeah conditional locks make sense. timelock, what happens if you just wait out the time interval?

UkoeHB: conditional in the sense of they are locked until time x or until someone shows that he knows secret s

oh i see conditional is not the right word here, sorry

we have the former one now, and it isn't used

the latter one is basically txo signing... what's the difference?

For a proposed method for bidirectional atomic swaps without time locks, see:

DLSAG also uses hidden timelocks but in combination with a refund mechanism to enable payment channels. So timelocks seemed necessary but insufficient

I can certainly see use cases for locking outputs to automatically spend or refund upon another transaction's confirmation

That paper abstract sounds like they find some magic ...

*found

Well, I think unless someone shows up with a clear and specific usecase for timelocks, we can punt it to the future.

agreed

Any other subjects people want to discuss? Perhaps from the agenda.

the timelocks thing is a subset of overall locking though, no?

not to drag this on

subset?

subset.. specific case

a e.g. range proof could be used to prove various things like confirmation

i *think*

i dont quite understand how it remains totally private though

which I suppose veers into DLSAG territory

but there are use cases for locking for sure

i think right now it's ok because we have some sort of rough alternatives for those use cases. so i wouldn't mind if we just bring this up later :)

it's not totally private - you expose a subset of the timelock range

also btw, I removed monero's normal timelocks from my poc (i.e. didn't implement it): monero-project/research-lab #78

So if we can't get up our collective asses to remove them earlier, as originally discussed, you will finally kill them :)

guess so

which i think is fine as long as there's no cost to adding them back if needed

but there may be

the cost is a hard fork and more code

well, privacy cost

and hypothetical migration cost

i mean whether the formats can be migrated

no, it is pointless to migrate the old timelock format to a hidden version

Looks like locks introduced would be strictly additional, no?

*introduced later

that's not what i mean

migrate from no timelocks back to having thenm

I understood it also that way, I think. We want them back, we implement, we hardfork, txs get somewhat larger, done.

The semantics of hidden timelocks in my proposal are very different from current timelocks, so the path is 'remove a feature' then 'implement a different feature'.

With the "remove a feature" proposed already for the very first version of Seraphis, right?

Would want to check in again with atomic swaps people, but AFAIU, hidden timelocks can improve the UX in combination with transaction chaining, so long as the hidden timelock is implemented like "can't include this tx until block N", rather than "this output is locked until block N". Even though the latter would still allow the former with a hack, seems we'd still want the former

Here's what tx chaining enables: thanks to tx chaining, I can submit tx0 and have pre-signed tx1 spending outputs from tx0 back to myself, in the event of an unresponsive counter-party

rbrunner: yes, there are important reasons seraphis can't support it monero-project/research-lab #78#issuecomment-913046076

Without a timelock, I could submit tx1 10 blocks after tx0. But maybe my counter-party wants more time for the atomic swap, e.g. maybe I should give them 24 hours. A timelock on tx1 enables that

i agree with Justin here

I see, it would be good to get confirmation on that

We are approaching the meeting end, are there any other topics to address?

ok guess not, shall we call it here? thanks for attending everyone

ty

thx koe

thanks

timelocks are used in markets i.e. the market can give you a transaction to refund a purchase after date X in the case the market or goes awol or whatever

looks like tx chaining might accomplish the same tho

I doubt tx chaining would work

I wasn't sure how it would but jberman[m] mentioned something that sounded similar with tx chaining

oh they meant with swaps I think

About timelocks. Would allow Haveno to switch to a 2/2 multisig scheme instead of 2/3. It would be an interesting change because the arbitrator won't need one of the keys of the escrow in a trade, making it "purely" P2P. See haveno-dex/haveno-meta #14

ErCiccione: wouldn't that require extra communication rounds? you'd want to set up the refund tx via tx chaining before completing the tx that funds the 2-of-2 wallet, otherwise the vendor could just refuse to make any txs after the wallet is funded, permanently locking those funds

<jberman[m]> "Would want to check in again..." <- Being more precise here on what I meant by "hack" here: in order to get the same functionality as Bitcoin nLockTime's "can't include this output on chain until block N" by using the functionality of a timelock that implements "can't spend this output that already exists on chain until block N", it would require an extra on-chain tx to lock an output which then can't be used as an

input in another tx until block N. If the desired functionality is the nLockTime-equivalent, seems prudent to go for that instead of requiring an additional tx to achieve that functionality. but granted, obviously we want to know which use cases we want to support to have an informed discussion on this

On atomic swaps: the reason why XMR is recommended in COMIT to not go first in a swap versus BTC is because if you're holding BTC and have an outstanding offer to swap with any market taker who comes along who has XMR and wants to swap, you want some assurance from the XMR sender that they will actually do the swap with you (likewise the XMR sender wants assurance the BTC maker will complete the swap, and the idea is still in a

way covered by "trust" and is why you see service uptime as a valuable metric when choosing a swap partner today in their protocol, although the most either party can still lose is tx fees)

As they proposed, requiring the XMR sender to send their XMR first is essentially adding cost to the XMR sender, so that the BTC holder can have some assurance the XMR sender will complete the swap

And AFAIU, a timelock is a way to increase this cost, should the default 10 blocks/XMR tx fees prove insufficient deterrents

And still reaching out to atomic swaps peeps to hear more thoughts. pinging h4sh3d :)

Latest research we saw was around moving the timelock off-chain: say we do some kind of 2-of-2 in XMR for the lock (as we do currently in swaps), you encapsulates one of the key in a cryptographic time locked puzzle that requires around 24 hours to solve and send it to counter party. You achieved an off-chain timelock because in 24 hours counter party know the full key and can refund

It’s an interesting way of bypassing the problem of on-chain timelock but the crypto is for me very new and I don’t know yet what to think about it. There has been discussions on monero swaps the past months on that topic

This would allow XMR go first in a swap an probably more things such as payment channels

This is PayMo right? My initial q is doesn't it advantage people with very large compute power/prove difficult to design around the issue that some have more compute power and some have very little? Perhaps I am too dismissive of it so long as some minimal cost is added. I guess in the case even with an on-chain timelock, in theory someone with a lot of XMR and time to kill could grief all the BTC makers who are offering

smaller amounts of BTC for sale too, so it's not as though that general issue is fully solved with that solution either

which solution would be more robust I think is a key question

Yeah PayMo used that concept but on another level (sigs not keys) IIRC (still requiring tx chaining on-chain), a more recent paper described it a bit differently

And yes I’m not sure it will ever be practical

Another topic that was discussed in monero-swaps was around requiring some proof of work or proof of output ownership to reduce griefing attacks

I believe on-chain timelocks are more robust and have advantages like automatically following the blockchain pace, but it would be damn cool to have fully off-chain primitive for interoperability reasons

off-chain would also be more private (unless every tx implemented locks, which impacts chain syncing). It does sound sweet to me to fully explore. I don't see any harm in waiting until that's fully explored until deciding to move forward on an on-chain timelock for swaps/payment channels UkoeHB

sorry there is the Haveno idea too

sure

UkoeHB: jberman[m]: btw, aiui range proofs can now be aggregated as well to scale space increases logarithmically rather than linearly

I heard it's already being done in bulletproofs

yes

1/2 multisig patches have been merged :)

🙌