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

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

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

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

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

<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 mrelay.p2pool.observer/e/zNK3-ZYLa1BGS3pM ]

<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 mrelay.p2pool.observer/e/zNK3-ZYLa1BGS3pM ]

<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 mrelay.p2pool.observer/e/zNK3-ZYLa1BGS3pM ]

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

<midipoet:matrix.org> That sounds like a bad idea.

<egalchain_pioneer:matrix.org> Why ?

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

<egalchain_pioneer:matrix.org> Thanks I delete and paste it over there

<rucknium> MRL meeting in this room in two hours.

<neptunian:unredacted.org> Good afternoon, all.

<rucknium> Meeting time! monero-project/meta #1421

Hi

<ravfx:xmr.mx> o/

<rucknium> 1. Greetings

Hello

<boog900> hi

<articmine> Hi

<vtnerd> Hi

<jberman> waves

<rucknium> 2. Updates. What is everyone working on?

<jeffro256> Howdy

<rucknium> me: Keeping stressnet stressed and helping troubleshoot there.

<jeffro256> me: reviewing FCMP++ PRs and upstream bug fixes, reworked my RPC speedup PR , worked on some upstream bug fixes myself

<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

<jberman> me: FCMP++ integration PR's, stressnet debugging followup

<neptunian:unredacted.org> me: Reading some fun things about lattice commitments and various other things.

I have this item for discussion: monero-project/research-lab #161 (apologies for the late submission). Can be done in agenda item 4.

<rucknium> tevador: Ok it can be discussed during item 4. Thanks.

<rucknium> 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed).

<jberman> * Still slowly making progress on getting integration code merged upstream

<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

<jeffro256> As for the task list , since seraphis-migration/monero #424 was merged and reviewed (thanks Ukoe), I can rebase the wallet knowledge proofs PR , and chug along with that

<jberman> * UkoeHB has mentioned for multisig he has 1 last test he's working through

<jberman> I don't have an update on what's next with hw wallets

<ofrnxmr> Also, @plowsof:matrix.org performed wallet sync and cold signing on mobile wallet for stressnet

<jeffro256> I keep getting messages that the companies are looking jnto it, but so far nothing has materialized

<jberman> hot/cold wallet stuff seems pretty close to the finish line as well thanks to @jeffro256:monero.social

<jberman> helioselene audit is still ongoing, and we're still discussing the next steps for another audit round on the circuit + gadget ipml internally

<neptunian:unredacted.org> @jeffro256: Which companies are looking into it if I may ask?

<jeffro256> Ledger, Trezor

ofrnxmr yes , these transactions where all signed offline via DataHoarders stressnet payments explorer stressnet.p2pool.observer/payments?id=cat

and vtnerds lwsf carrot branch

<rucknium> plowsof: Thanks. Does that mean that the code that we know works is Go code?

Yes working on multisig test. wallet2 is quite poorly designed for testing.

<jpk68:matrix.org> Hello

<rucknium> Anything more about this topic?

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

<rucknium> 4. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686). Jamtis (gist.github.com/tevador/639d083c994…32#appendix-c-instant-sync-protocol). Repurposing unlock_time for relative locks with FCMP++ (monero-project/research-lab #161).

The relative lock is a trade off which might be worth the slight leakage it would cause.

<jeffro256> I don't understand how making the unlock time relative does anything to help it support payment channels

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

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.

But I agree we should investigate specific protocols it would allow before implementing it.

<jeffro256> Ah I see. In that case, we would need to move the reference_block field to the signable portion of the transaction

<articmine> tevador: Which works very well if the fees are much lower than the channel value.

<jeffro256> This would break tx chaining and make offline signing weirder

jeffro256: no, it does not need to be signed

only unlock_time = 1 is signed, so Alice cannot change that

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

She can select whatever reference_lock / anchor_height she wants, but if block_height - anchor_height < 720, the transaction won't be relayed.

<jberman> > <tevador> But I agree we should investigate specific protocols it would allow before implementing it.

<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

You need a relative lock to have payment channels that don't expire

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

Ah, the clock starts to tick with the mining of the tx, whenever that will be?

Yes, the block starts ticking when Alice submits the malicious old state transaction.

clock*

<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

<jeffro256> *doesn't

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)

unlock_time = 1 tells the consesus protocol to use an old tree root for the proof

Which proves that the transaction is spending only enotes older than 24 hours.

Are these new locks still per tx and not per output?

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

<neptunian:unredacted.org> I think it's a bit of a UX issue to have random 24-hour locks on ordinary transactions.

neptunian: No, there would be no locks on random transactions.

The enote spent is ALREADY older than 24 hours, so there no wait time.

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

<neptunian:unredacted.org> tevador: Ah. I see. Thanks for clarification.

The repurposed unlock_time doesn't work like the old one. It only affects tx validity, not subsequent spending.

<jeffro256> Yeah that could work. If we can do a gate on some cryptograpgic condition, then that would be pretty similiar to HTLCs

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.

<jeffro256> tevador: *assuming no large changes in hashrate

~24 hours*

<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

I will try to add a protocol sketch to #161

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.

No, it would not work.

<jeffro256> UkoeHB would the main difference here be that this relative lock doesn't put the compute / storage burden on tree builders?

Current unlock_time is unconditional, so it also prevents Bob from spending it with his Punish transaction.

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.

tevador: you can timelock a dummy enote, it doesn't have to be the funds actually transferred by the relatively-locked tx.

jeffro256: yeah, and simplifying the payment channel workflow (if there is one)

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.

I haven't seen any workiable protocol using the current broken unlock_time feature.

tevador: probably easier for you to post a sketch then I can logically disprove it (or fail to).

I will post a sketch

For proving, not disproving

<neptunian:unredacted.org> I'd agree with Tevador about the relative lock being good given the slight leakage.

<neptunian:unredacted.org> It may be best to wait for the full sketch, though.

tevador: what about a 2-of-2 on the dummy so it can't be invalidated by Alice?

UkoeHB: You can try to sketch your protocol using the old locks. I'm strongly suspecting it won't work.

<neptunian:unredacted.org> Ooh. A sketch-off.

<rucknium> Thanks, tevador . Anything more on this topic for now?

<rucknium> 5. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<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

<rucknium> I'm starting to test the proposed fixes.

<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

<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

<jberman> Here's a tracker for beta v2.1 : seraphis-migration/monero #415 , I'll updae that as we get more info on the issue with @rucknium:monero.social 's majorly appreciated help

<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

<rucknium> Anything more on stressnet?

<jberman> nothin from me

<jeffro256> vtnerd how is p2p SSL looking for stressnet?

<rucknium> 5. monerosim (github.com/Fountain5405/monerosim).

<rucknium> @gingeropolous:monero.social seems to be working on improvements: github.com/Fountain5405/monerosim/commits/main

<rucknium> I don't know if there is anything to discuss.

<plowsof:matrix.org> its claimed as being completed now repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589

<rucknium> I think the task described in the CCS is completed.

thanks for looking into this Rucknium 👍

<rucknium> We can end the meeting here. Thanks everyone.

<articmine> Thanks

<jeffro256> Thanks everyone!

<vtnerd> @jeffro256: Sorry phone call came in. It was ready last I looked, I'll double check that before Friday

<vtnerd> The d++ slowdown took precedence

<vtnerd> @vtnerd: I'm in the process of moving, so things are a bit hectic around here for another week or so

19:18:28 <br-m> <rucknium> plowsof: Thanks. Does that mean that the code that we know works is Go code?

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

couldn't have said it better myself, thanks DataHoarder 😅

<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

OK