08:45:27 <br-m> <kayabanerve:matrix.org> I think anything advertised as payment channels should not have any third-party trust assumption. I think you can achieve multisigs as a scaling solution, but they're still multisigs and should be phrased as such.
08:49:32 <br-m> <kayabanerve:matrix.org> My comments on 'using a threshold multisig for a KES' weren't meant to suggest the results would be perfect payment channels, just that it'd mitigate KES risk.
08:51:26 <br-m> <kayabanerve:matrix.org> But when the primary premise is the third-party won't misbehave, then you can just propose wXMR on ICP for very much greater functionality and to underline what the issues/trust assumptions are.
08:51:26 <br-m> <kayabanerve:matrix.org> I understand this also requires the other party in the channel to collude with ICP, and the updates optimistically occur off-chain, but it's still very "ugh" IMO.
09:56:30 <br-m> <kayabanerve:matrix.org> Also, the Monet paper proposed PoW puzzles to about such third-parties, which the Grease paper replaced with a KES, AFAIK. Monet didn't require a 'smart contract' and Grease didn't require PoW puzzles. Instead, those were the issues with the respective designs.
12:09:32 <br-m> <egalchain_pioneer:matrix.org> Hey, I work on EgalChain; is a Monero fork (RandomX, ring sigs, stealth addresses intact) with a consensus-validated state layer on top — signed ops in the coinbase tx.extra, executed each block into an LMDB registry, committed to a Merkle-sum-tree state root. It's testnet-stage, pre-audit. The source code is not yet public; [... too long, see https://mrelay.p2pool.observer/e/zNK3-ZYLa1BGS3pM ]
12:09:32 <br-m> <egalchain_pioneer:matrix.org> Here's the design tension I want your reasoning on. The base-layer txs keep Monero's privacy — but the cooperative-banking layer on top is transparent by construction: ops are ed25519-signed with persistent keys, amounts live in a public registry, and the Merkle-sum-tree exists precisely so balances and conservation are prov [... too long, see https://mrelay.p2pool.observer/e/zNK3-ZYLa1BGS3pM ]
12:09:32 <br-m> <egalchain_pioneer:matrix.org> So my real question isn't just "does the country_code leak" — it's whether it's coherent at all to run a deliberately-transparent, identity-bound ledger inside a chain whose base threat model is unlinkability. Does the pseudonymous state layer already dissolve the privacy guarantees enough that the passport binding is[... more lines follow, see https://mrelay.p2pool.observer/e/zNK3-ZYLa1BGS3pM ]
12:23:04 <br-m> <midipoet:matrix.org> > On top of that I bind a passport-derived nullifier (one persistent per-person id) + an ISO country code for a Sybil-resistant, per-country on-chain poll.
12:23:04 <br-m> <midipoet:matrix.org> That sounds like a bad idea.
12:48:29 <br-m> <egalchain_pioneer:matrix.org> Why ? 
12:55:53 <br-m> <rucknium> @egalchain_pioneer:matrix.org: Unlike #monero-dev:monero.social  , this room does not have "no fork help" in its description, but this conversation is better to have in #monero-research-lounge:monero.social  than here.
13:00:15 <br-m> <egalchain_pioneer:matrix.org> Thanks I delete and paste it over there
15:03:08 <br-m> <rucknium> MRL meeting in this room in two hours.
17:00:04 <br-m> <neptunian:unredacted.org> Good afternoon, all.
17:00:52 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1421
17:00:55 <tevador> Hi
17:00:58 <br-m> <ravfx:xmr.mx> o/
17:01:00 <br-m> <rucknium> 1. Greetings
17:01:02 <rbrunner> Hello
17:01:08 <br-m> <boog900> hi
17:01:10 <br-m> <articmine> Hi
17:01:20 <br-m> <vtnerd> Hi
17:02:25 <br-m> <jberman> waves
17:03:21 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:23 <br-m> <jeffro256> Howdy
17:03:48 <br-m> <rucknium> me: Keeping stressnet stressed and helping troubleshoot there.
17:04:44 <br-m> <jeffro256> me: reviewing FCMP++ PRs and upstream bug fixes, reworked my RPC  speedup PR , worked on some upstream bug fixes myself
17:04:59 <br-m> <vtnerd> Me: still working on getting the serialization pr 100%, getting closer to (hopefully) solving the weak ptr memleak, and lastly fixing the slowdowns on d++/p2p send code
17:05:08 <br-m> <jberman> me: FCMP++ integration PR's, stressnet debugging followup
17:06:07 <br-m> <neptunian:unredacted.org> me: Reading some fun things about lattice commitments and various other things.
17:06:25 <tevador> I have this item for discussion: https://github.com/monero-project/research-lab/issues/161 (apologies for the late submission). Can be done in agenda item 4.
17:08:07 <br-m> <rucknium> tevador: Ok it can be discussed during item 4. Thanks.
17:08:13 <br-m> <rucknium> 3. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/).
17:09:08 <br-m> <jberman> * Still slowly making progress on getting integration code merged upstream
17:10:14 <br-m> <jberman> * Making progress on the major beta stressnet items, however, I would stlil say the beta is in a state where FCMP++/Carrot code doesn't need to be blocked from mainnet aka it seems to be in a good state
17:10:46 <br-m> <jeffro256> As for the task list , since https://github.com/seraphis-migration/monero/pull/424 was merged and reviewed (thanks Ukoe), I can rebase the wallet knowledge proofs PR , and chug along with that 
17:10:57 <br-m> <jberman> * UkoeHB has mentioned for multisig he has 1 last test he's working through
17:12:09 <br-m> <jberman> I don't have an update on what's next with hw wallets
17:12:36 <br-m> <ofrnxmr> Also, @plowsof:matrix.org  performed wallet sync and cold signing on mobile wallet for stressnet
17:12:50 <br-m> <jeffro256> I keep getting messages that the companies are looking jnto it, but so far nothing has materialized 
17:14:00 <br-m> <jberman> hot/cold wallet stuff seems pretty close to the finish line as well thanks to @jeffro256:monero.social
17:15:13 <br-m> <jberman> helioselene audit is still ongoing, and we're still discussing the next steps for another audit round on the circuit + gadget ipml internally
17:15:23 <br-m> <neptunian:unredacted.org> @jeffro256: Which companies are looking into it if I may ask?
17:15:42 <br-m> <jeffro256> Ledger, Trezor 
17:17:21 <plowsof> ofrnxmr yes , these transactions where all signed offline via DataHoarders stressnet payments explorer https://stressnet.p2pool.observer/payments?id=cat
17:18:18 <plowsof> and vtnerds lwsf carrot branch
17:18:29 <br-m> <rucknium> plowsof: Thanks. Does that mean that the code that we know works is Go code?
17:18:45 <UkoeHB> Yes working on multisig test. wallet2 is quite poorly designed for testing.
17:18:59 <br-m> <jpk68:matrix.org> Hello
17:20:15 <br-m> <rucknium> Anything more about this topic?
17:20:16 <plowsof> afaict yes : for the end user - the difference is after you import the signed transaction set - there is another 10-20 seconds of work that is done (building the tree and things jeffro would know about) but thats all. signed/unsigned tx sizes are just as small as wallet2 tx's 
17:21:40 <br-m> <rucknium> 4. Post-quantum encryption (https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686). Jamtis (https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#appendix-c-instant-sync-protocol). Repurposing unlock_time for relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161).
17:23:44 <tevador> The relative lock is a trade off which might be worth the slight leakage it would cause.
17:23:55 <br-m> <jeffro256> I don't understand how making the unlock time relative does anything to help it support payment channels 
17:24:40 <br-m> <neptunian:unredacted.org> @jeffro256: If I'm reading it correctly, I think it's just addressing having a better unlock_time which would preserve the payment channels.
17:25:20 <tevador> It allows the channel to have 2 presigned transactions: Withdraw (time-locked) and Punish (not locked). The Punish is used if Alice attempts to close the channel with an old state.
17:26:26 <tevador> But I agree we should investigate specific protocols it would allow before implementing it.
17:27:03 <br-m> <jeffro256> Ah I see. In that case, we would need to move the reference_block field to the signable portion of the transaction 
17:27:12 <br-m> <articmine> tevador: Which works very well if the fees are much lower than the channel value.
17:27:26 <br-m> <jeffro256> This would break tx chaining and make offline signing weirder 
17:27:42 <tevador> jeffro256: no, it does not need to be signed
17:28:15 <tevador> only unlock_time = 1 is signed, so Alice cannot change that
17:28:59 <rbrunner> I am still a bit confused. Their value does not rest on them being relative now, or does it? I could already lock up to the same block like any relative lock with the "old" locks
17:29:13 <tevador> She can select whatever reference_lock / anchor_height she wants, but if block_height - anchor_height < 720, the transaction won't be relayed.
17:29:19 <br-m> <jberman> > <tevador> But I agree we should investigate specific protocols it would allow before implementing it.
17:29:19 <br-m> <jberman> I agree with this. If there is a specific protocol spec'd that could feasibly work, then it could make sense. FWIW @moneromoo at one point highlighted how there is still a way for someone to hack that kind of unlock time behavior with the current unlock_time: by constructing a tx and putting it on chain with a specific unlock_time, and then pre-signing a tx with that output as an input
17:30:00 <tevador> You need a relative lock to have payment channels that don't expire
17:30:34 <br-m> <neptunian:unredacted.org> I feel like the fake lock fix could be an issue. How many wallets would realistically be randomly setting unlock_time=1 for normal transactions?
17:30:35 <rbrunner> Ah, the clock starts to tick with the mining of the tx, whenever that will be?
17:30:53 <tevador> Yes, the block starts ticking when Alice submits the malicious old state transaction.
17:30:56 <tevador> clock*
17:31:15 <br-m> <jeffro256> But does that leave the door open to fraud by anyone who knows the rerandomizations by setting an arbitrary reference block? > <tevador> only unlock_time = 1 is signed, so Alice cannot change that
17:31:27 <br-m> <jeffro256> *doesn't
17:31:56 <tevador> No, you cannot make a valid membership proof for an enote that's not in the tree yet (it will be added ~700 blocks later)
17:32:36 <tevador> unlock_time = 1 tells the consesus protocol to use an old tree root for the proof
17:33:11 <tevador> Which proves that the transaction is spending only enotes older than 24 hours.
17:34:44 <rbrunner> Are these new locks still per tx and not per output?
17:34:47 <br-m> <rucknium> IIRC, one of the reasons custom unlock time is being eliminated at the deployment of FCMP is that custom unlock time negatively affects the FCMP tree performance.
17:35:04 <br-m> <neptunian:unredacted.org> I think it's a bit of a UX issue to have random 24-hour locks on ordinary transactions.
17:35:40 <tevador> neptunian: No, there would be no locks on random transactions.
17:35:55 <tevador> The enote spent is ALREADY older than 24 hours, so there no wait time.
17:36:07 <br-m> <rucknium> And hasn't the issue with Monero-style locks been that when custom lock time arrives, you have a race in the txpool to spend the tx if multiple people have the right to spend it?
17:36:24 <br-m> <neptunian:unredacted.org> tevador: Ah. I see. Thanks for clarification.
17:36:52 <tevador> The repurposed unlock_time doesn't work like the old one. It only affects tx validity, not subsequent spending.
17:37:26 <br-m> <jeffro256> Yeah that could work. If we can do a gate on some cryptograpgic condition, then that would be pretty similiar to HTLCs
17:37:44 <tevador> Basically, with unlock_time = 1, Alice has a pre-signed transaction that will become valid in 24 hours. After that, only the normal 10 block lock applies.
17:38:06 <br-m> <jeffro256> tevador: *assuming no large changes in hashrate 
17:38:26 <tevador> ~24 hours*
17:39:36 <br-m> <jeffro256> I agree with Berman that it would be nice to have at least 1 sketch of a real, useful payment channel before supporting it, but this version of time locks is much closer to actually supporting payment channels 
17:39:57 <tevador> I will try to add a protocol sketch to #161
17:43:06 <UkoeHB> So it's a tx publish lock, not an enote lock as with the current timelocks. Yeah you can accomplish the same with timelocks by submitting a locked enote then chaining off it. So any protocol using relative locks would presumably already work.
17:43:51 <tevador> No, it would not work.
17:44:20 <br-m> <jeffro256> UkoeHB would the main difference here be that this relative lock doesn't put the compute / storage burden on tree builders?
17:44:25 <tevador> Current unlock_time is unconditional, so it also prevents Bob from spending it with his Punish transaction.
17:45:21 <tevador> The proposed unlock_time functionality would be used to only lock Alice's Withdraw transaction. AFAIK that can't be accomplished with the old locks.
17:45:26 <UkoeHB> tevador: you can timelock a dummy enote, it doesn't have to be the funds actually transferred by the relatively-locked tx.
17:46:26 <UkoeHB> jeffro256: yeah, and simplifying the payment channel workflow (if there is one)
17:46:49 <tevador> OK, so we have a presigned dummy enote. Alice publishes just this dummy, waits 24 hours and then steals the funds from the wrong state transaction.
17:47:44 <tevador> I haven't seen any workiable protocol using the current broken unlock_time feature.
17:47:57 <UkoeHB> tevador: probably easier for you to post a sketch then I can logically disprove it (or fail to).
17:48:36 <tevador> I will post a sketch
17:48:59 <tevador> For proving, not disproving
17:49:21 <br-m> <neptunian:unredacted.org> I'd agree with Tevador about the relative lock being good given the slight leakage. 
17:49:23 <br-m> <neptunian:unredacted.org> It may be best to wait for the full sketch, though.
17:51:51 <UkoeHB> tevador: what about a 2-of-2 on the dummy so it can't be invalidated by Alice?
17:53:24 <tevador> UkoeHB: You can try to sketch your protocol using the old locks. I'm strongly suspecting it won't work.
17:54:10 <br-m> <neptunian:unredacted.org> Ooh. A sketch-off.
17:54:52 <br-m> <rucknium> Thanks, tevador  . Anything more on this topic for now?
17:56:39 <br-m> <rucknium> 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/).
17:58:00 <br-m> <jberman> For v2.1, I'd like to have the elusive wallet tx rejection double spend errors fully solved. It seems there are a few issues it has exposed (also present in the current release monerod) that are leading to this rare edge case issue
18:00:01 <br-m> <rucknium> I'm starting to test the proposed fixes.
18:00:17 <br-m> <jberman> ^I've requested @rucknium:monero.social run all the patches we have for identified issues (1 patch by vtnerd as well) + more detailed logging that would help us be certain we have fully solved it
18:00:58 <br-m> <jberman> And that logging also includes additional logging that would help us get to the bottom of a distinct issue of more frequent bans, seemingly caused by tx relay v2
18:01:52 <br-m> <jberman> Here's a tracker for beta v2.1 : https://github.com/seraphis-migration/monero/pull/415 , I'll updae that as we get more info on the issue with @rucknium:monero.social 's majorly appreciated help
18:02:58 <br-m> <jberman> the code @rucknium:monero.social is running includes the 3 PR's under the "sporadic double spend" bullet, and the "log missing requested pool tx" bullet
18:04:55 <br-m> <rucknium> Anything more on stressnet?
18:05:27 <br-m> <jberman> nothin from me
18:05:52 <br-m> <jeffro256> vtnerd how is p2p SSL looking for stressnet?
18:10:22 <br-m> <rucknium> 5. monerosim (https://github.com/Fountain5405/monerosim).
18:11:08 <br-m> <rucknium> @gingeropolous:monero.social seems to be working on improvements: https://github.com/Fountain5405/monerosim/commits/main/
18:11:15 <br-m> <rucknium> I don't know if there is anything to discuss.
18:12:38 <br-m> <plowsof:matrix.org> its claimed as being completed now https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589
18:13:52 <br-m> <rucknium> I think the task described in the CCS is completed.
18:14:21 <plowsof> thanks for looking into this Rucknium 👍
18:14:29 <br-m> <rucknium> We can end the meeting here. Thanks everyone.
18:15:45 <br-m> <articmine> Thanks 
18:23:29 <br-m> <jeffro256> Thanks everyone!
18:24:31 <br-m> <vtnerd> @jeffro256: Sorry phone call came in. It was ready last I looked, I'll double check that before Friday
18:25:37 <br-m> <vtnerd> The d++ slowdown took precedence 
18:30:42 <br-m> <vtnerd> @vtnerd: I'm in the process of moving, so things are a bit hectic around here for another week or so
18:32:33 <DataHoarder> 19:18:28 <br-m> <rucknium> plowsof: Thanks. Does that mean that the code that we know works is Go code?
18:32:34 <DataHoarder> This is scanning code, not signing code. I can only generate/verify SAL proofs, not FCMP. I can generate/sign full txs pre-FCMP++. I think plowsof just means "here's a list shown via my explorer" :)
19:15:16 <plowsof> couldn't have said it better myself, thanks DataHoarder 😅
19:37:38 <br-m> <jeffro256> @tevador can I ping you again for mx25519 PR review plz ? The carrot_core dependencies are almost all merged, which would leave mx25519, I will PR the unclamped changes soon 
20:10:53 <tevador> OK