11:32:48 <frr> Cheers everyone 
11:58:18 <frr> .
15:03:19 <UkoeHB> Meeting ~2hr
17:01:20 <one-horse-wagon[> Hello everyone.
17:01:51 <frr> Greetings 
17:01:55 <Rucknium[m]> Hi
17:02:00 <rbrunner> Hello
17:02:04 <mj-xmr[m]> Hey!
17:02:38 <UkoeHB> oh hi whoops
17:02:48 <hyc> hi
17:02:59 <UkoeHB> meeting agenda: https://github.com/monero-project/meta/issues/669
17:03:55 <jberman[m]> hey
17:04:22 <UkoeHB> 2. we can start with updates, what is everyone up to?
17:04:32 <mj-xmr[m]> 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.
17:05:15 <UkoeHB> me: I opened a CCS for Seraphis wallet PoC https://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).
17:08:19 <Rucknium[m]> 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)
17:09:33 <Rucknium[m]> 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:
17:09:33 <Rucknium[m]> https://github.com/Rucknium/misc-research/tree/main/CashFusion-Descendant-Analysis
17:09:42 <Rucknium[m]> I hope to release results in the next few days
17:10:46 <rbrunner> 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?
17:11:00 <Rucknium[m]> Relatedly, if anyone has a more-of-less comprehensive list of all CoinJoin transaction on the BTC blockchain, let me know.
17:11:09 <jberman[m]> 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
17:11:11 <UkoeHB> rbrunner: yes my best guess
17:11:45 <jberman[m]> https://github.com/monero-project/monero/issues/8082
17:13:13 <UkoeHB> 3. today I want to bring up timelocks again (my little proposal: https://github.com/monero-project/research-lab/issues/78#issuecomment-1003195804 ); now would be a good time for me to implement it in Seraphis if it's worthwhile
17:14:13 <UkoeHB> 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)
17:14:43 <endogenic> seems reasonable to me
17:15:35 <moneromooo> Why range proofs ? To hide them ?
17:15:39 <UkoeHB> right
17:16:00 <moneromooo> Can't they be brute forced rather trivially ?
17:16:14 <UkoeHB> how? you use pedersen commitments, just like amounts
17:16:33 <rbrunner> Not sure I understand how you can hide heights and still check whether the tx is mineable
17:16:50 <moneromooo> Verify the tx with all heights between say, now and now + 50k.
17:16:53 <Rucknium[m]> 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.)
17:17:06 <UkoeHB> you state two nominal heights in clear text, then range proof `hidden_height - clear_height`
17:18:31 <UkoeHB> 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)
17:19:33 <moneromooo> Ah. I see now.
17:19:52 <UkoeHB> Rucknium[m]: I forget lol
17:20:38 <jberman[m]> would every tx add one by default? or just users who want to use a timelock?
17:20:41 <rbrunner> So one could see that the tx is timelocked, just not how exactly.
17:20:41 <UkoeHB> I have not looked into the usecases for good timelocks so... this is also a request for people who want timelocks to step forward
17:20:46 <moneromooo> In what cases could this be useful ?
17:21:08 <UkoeHB> jberman[m]: every tx would add it I think
17:21:21 <UkoeHB> it's open for debate though
17:21:57 <rbrunner> What's again the approximate size of such a range proof?
17:22:22 <rbrunner> In bytes I mean
17:22:26 <UkoeHB> rbrunner: they would be aggregated with other tx range proofs, so only a couple extra 32 bytes
17:22:46 <UkoeHB> depending on bp+ aggregation cutoffs
17:22:57 <moneromooo> Plus 64 for the two commitments.
17:23:10 <moneromooo> (presumably)
17:23:31 <UkoeHB> yeah, and 16 bytes for the cleartext heights (or less if using varints)
17:24:25 <rbrunner> IMHO still a tough sell for 0.01% or so of tx which will use the feature if *every* tx gets this, for uniformity
17:24:30 <UkoeHB> I think it's 64 extra range proof bytes if adding the timelock proofs makes you go over a cutoff
17:25:10 <moneromooo> Verification time would be bumped a lot more given it's not log increase.
17:25:42 <UkoeHB> yes, although batching has a substantial effect
17:25:45 <moneromooo> Actually, wait. Maybe not, if it's the multiexp ?
17:25:45 <hyc> seems like a lot to pay for an infrequently used feature
17:25:56 <moneromooo> in the*
17:26:23 <endogenic> can it be added later if we decide it's super important?
17:26:29 <UkoeHB> sure
17:26:42 <moneromooo> Anyway, it'd be nice if if were a biulding block for some second layer thing. Otherwise, meh.
17:26:50 <hyc> in that case sounds like something to leave out for now
17:26:54 <endogenic> i think there are lots of use cases for it
17:26:56 <rbrunner> For swaps and such?
17:26:58 <endogenic> people have chimed in about it to some degree
17:27:01 <rbrunner> Atomic swaps
17:27:24 <rbrunner> To "go first" with XMR which I think now is not possible
17:27:36 <UkoeHB> rbrunner: I think only tx chaining is required for that
17:27:55 <one-horse-wagon[> Are not atomic swaps a long way off at this time?
17:28:12 <atomfried[m]> moneromooo: i think for such a use conditional locks would help much more
17:28:37 <UkoeHB> timelocks are conditional... what do you mean?
17:28:39 <rbrunner> No, I think BTC-XMR swaps are already possible on the mainnets
17:28:41 <Rucknium[m]> 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.
17:29:27 <Rucknium[m]> And then payment channels get easier, I think. Although again there are claims of possible Monero payment channels without such time locks.
17:29:35 <hyc> yeah conditional locks make sense. timelock, what happens if you just wait out the time interval?
17:29:38 <atomfried[m]> UkoeHB: conditional in the sense of they are locked until time x or until someone shows that he knows secret s
17:30:09 <atomfried[m]> oh i see conditional is not the right word here, sorry
17:30:30 <UkoeHB> we have the former one now, and it isn't used
17:30:57 <UkoeHB> the latter one is basically txo signing... what's the difference?
17:32:26 <Rucknium[m]> For a proposed method for bidirectional atomic swaps without time locks, see:
17:32:26 <Rucknium[m]> https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=30
17:32:29 <jberman[m]> DLSAG also uses hidden timelocks but in combination with a refund mechanism to enable payment channels. So timelocks seemed necessary but insufficient
17:33:36 <endogenic> I can certainly see use cases for locking outputs to automatically spend or refund upon another transaction's confirmation
17:35:52 <rbrunner> That paper abstract sounds like they find some magic ...
17:36:10 <rbrunner> *found
17:36:14 <UkoeHB> Well, I think unless someone shows up with a clear and specific usecase for timelocks, we can punt it to the future.
17:36:33 <hyc> agreed
17:36:48 <UkoeHB> Any other subjects people want to discuss? Perhaps from the agenda.
17:36:55 <endogenic> the timelocks thing is a subset of overall locking though, no?
17:37:00 <endogenic> not to drag this on
17:37:05 <UkoeHB> subset?
17:37:09 <endogenic> subset.. specific case
17:37:22 <endogenic> a e.g. range proof could be used to prove various things like confirmation
17:37:24 <endogenic> i *think*
17:37:36 <endogenic> i dont quite understand how it remains totally private though
17:37:43 <endogenic> which I suppose veers into DLSAG territory
17:37:52 <endogenic> but there are use cases for locking for sure
17:38:29 <endogenic> 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 :)
17:38:31 <UkoeHB> it's not totally private - you expose a subset of the timelock range
17:39:03 <UkoeHB> also btw, I removed monero's normal timelocks from my poc (i.e. didn't implement it): https://github.com/monero-project/research-lab/issues/78
17:39:36 <rbrunner> So if we can't get up our collective asses to remove them earlier, as originally discussed, you will finally kill them :)
17:39:55 <UkoeHB> guess so
17:40:22 <endogenic> which i think is fine as long as there's no cost to adding them back if needed
17:40:25 <endogenic> but there may be
17:40:56 <UkoeHB> the cost is a hard fork and more code
17:41:04 <endogenic> well, privacy cost
17:41:24 <endogenic> and hypothetical migration cost
17:41:32 <endogenic> i mean whether the formats can be migrated
17:42:18 <UkoeHB> no, it is pointless to migrate the old timelock format to a hidden version
17:42:30 <rbrunner> Looks like locks introduced would be strictly additional, no?
17:42:38 <rbrunner> *introduced later
17:43:28 <endogenic> that's not what i mean
17:43:33 <endogenic> migrate from no timelocks back to having thenm
17:44:23 <rbrunner> I understood it also that way, I think. We want them back, we implement, we hardfork, txs get somewhat larger, done.
17:45:08 <UkoeHB> 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'.
17:45:59 <rbrunner> With the "remove a feature" proposed already for the very first version of Seraphis, right?
17:46:24 <jberman[m]> 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
17:46:43 <jberman[m]> 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
17:47:04 <UkoeHB> rbrunner: yes, there are important reasons seraphis can't support it https://github.com/monero-project/research-lab/issues/78#issuecomment-913046076
17:47:08 <jberman[m]> 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
17:47:17 <endogenic> i agree with Justin here
17:49:54 <UkoeHB> I see, it would be good to get confirmation on that
17:50:09 <UkoeHB> We are approaching the meeting end, are there any other topics to address?
17:54:16 <UkoeHB> ok guess not, shall we call it here? thanks for attending everyone
17:54:52 <hyc> ty
17:55:45 <jberman[m]> thx koe
17:57:29 <endogenic> thanks
18:49:19 <Lyza> 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
18:50:27 <Lyza> looks like tx chaining might accomplish the same tho
18:51:17 <UkoeHB> I doubt tx chaining would work
18:54:27 <Lyza> I wasn't sure how it would but jberman[m] mentioned something that sounded similar with tx chaining
18:55:01 <Lyza> oh they meant with swaps I think
19:23:40 <ErCiccione> 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 https://github.com/haveno-dex/haveno-meta/issues/14
19:31:23 <UkoeHB> 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
19:57:01 <jberman[m]> <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
19:57:01 <jberman[m]> 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
19:57:56 <jberman[m]> 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
19:57:56 <jberman[m]> 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)
19:58:53 <jberman[m]> 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
19:59:23 <jberman[m]> And AFAIU, a timelock is a way to increase this cost, should the default 10 blocks/XMR tx fees prove insufficient deterrents
19:59:56 <jberman[m]> And still reaching out to atomic swaps peeps to hear more thoughts. pinging h4sh3d :)
20:08:39 <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
20:10:03 <h4sh3d> 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
20:10:44 <h4sh3d> This would allow XMR go first in a swap an probably more things such as payment channels
20:18:31 <jberman[m]> 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
20:18:31 <jberman[m]> smaller amounts of BTC for sale too, so it's not as though that general issue is fully solved with that solution either
20:21:19 <jberman[m]> which solution would be more robust I think is a key question
20:26:33 <h4sh3d> 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
20:26:49 <h4sh3d> And yes I’m not sure it will ever be practical 
20:29:06 <h4sh3d> Another topic that was discussed in monero-swaps was around requiring some proof of work or proof of output ownership to reduce griefing attacks
20:31:36 <h4sh3d> 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 
20:35:18 <jberman[m]> 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 
20:36:31 <jberman[m]> sorry there is the Haveno idea too
20:39:35 <UkoeHB> sure
21:57:14 <endogenic> UkoeHB: jberman[m]: btw, aiui range proofs can now be aggregated as well to scale space increases logarithmically rather than linearly
21:57:52 <endogenic> I heard it's already being done in bulletproofs
22:07:43 <UkoeHB> yes
23:53:17 <selsta> 1/2 multisig patches have been merged :)
23:57:09 <UkoeHB> 🙌