I just opened monero-project/research-lab #102, which proposes to investigate the possibility of reducing the lock to <10 blocks. While i think that the best outcome would be to remove the lock entirely, worth exploring in parallel the possibility of reducing the lock to a lower numbers of blocks, since that should be easier to achieve. Please let me know your thoughs

Meeting in < 5 hours.

Before we go on the record, I have to make everybody aware, that there's a parasite looking for a host, after I excreted him. He feels cold and is currently trying to attach to Rucknium and Endor.

Don't take his comments very seriously. He's just trying to annoy and compromise you. That's what he gets paid for - to hinder Monero's progress.

He's been making a bunch of noise in -dev in the last few days

Probably it's his reporting week.

Every parasite's gotta make a living.

The person in question certainly has some issues, but it seems inappropriate and just incorrect to say he has ulterior motives.

I'd like to see a confirmation of lack of the ulterior motives by constructive reviews and criticism. So far I only see trashing others.

With that said, I welcome people who hold others accountable by reminding the promises made.

reminder that if you don't want to interact with someone that there is always /ignore, conspiracy theories that someone is paid to hinder progress are neither helpful nor true

UkoeHB: Please tell me how you see this conversation:

selsta: I already did. And it felt so bad to him, that he had to setup many other accounts. Next advice?

And how do you know for sure, that it's not true that he's getting paid?

objection your honour, hearsay, leading the witness

selsta: Also, as I already said, he's starting to suck other people's blood, not mine.

He should go to -social with this trash, rather than -dev or -mrl.

selsta: I'm not the only conspiracy theorist, it seems: reddit.com/r/Monero/comments/ts5fgg…e=reddit&utm_medium=web2x&context=3

"The Monero community has been on the receiving end of paid attacks. This sub has been attacked relentlessly by paid accounts. Many other contributors have been singled out and attacked personally - which seems to be an increasingly common tactic.

With regards to reddit, DM me at any time about suspected bad actors. I love troll hunting."

Ignorance of this will only lead the leave of many other developers, which is exactly the point that you were making. Now you know why you had to make the point.

mj-xmr[m]: oh maybe we're talking about different ppl lol

I see exactly the same behavioral patterns.

There's no one other that slutty here.

Anyway, 20 minutes until the meeting. If you prefer, you may:

🙈🙉🙊

Ah yeah same person, but ulterior motive is still accurate - more like a very narrow perspective on what objectives are worthwhile, very ineffective ways of interacting with people, and a fantasy about how the world should be that he thinks he needs to crusade for (when in reality, the things any one person can affect are much more limited, so that attitude is just super unproductive).

not accurate*

I'd accept that view.

But still, it suggests that the parents finance this :)

Anyway. I'm STFU now.

meeting time: monero-project/meta #706

1. greetings

hello

Hi

Hello

hello

hi

Hi :)

Hello

2. updates; what has everyone been working on/planning to work on?

I delivered the first working Python implementation of the Gamma Picker algo (part of the Decoy Algorithm) and was able to simulate the same behavior, that I did for the original C++ implementation. There are some visible differences, at least due to differences of the random number generator (Python's `... (full message at libera.ems.host/_matrix/media/r0/do…e67b6adb21a1a6986e7ede4c8af57381fe0)

C++ version for reference:

for comparison purposes you should be able to write your own PRNG and use it in both impls

Yep. Point.

me: Implemented a robust input selection solver for seraphis, pushed multisig PRs forward a bit, and updated jamtis to support self-spends better (e.g. churn). Next I will finally implement the full enote scanning workflow that I have been really looking forward to.

Working on the statistical model to estimate the effect of minexmr dot com's fee increase. I think I'll go with Vector Autoregression, treating the fee increase as an exogenous shock and fiat/XMR exchange rate and hashing difficulty as endogenous. Any input appreciated, especially from mj-xmr .

Im learning and implement in Python Bulletproofs and CLSAG as it is in the C++ code. I am also continuing scanning the blockchain with the LibSodium library.

I'll chat you after I finalize the decoy (very soon)

finished up patching relatively trivial tor/i2p daemon connectivity bugs (my outgoing tor connections stay alive much longer now and I don't see tx submissions warnings nearly as often), I left the final one on the back-burner for now (see comment in 6938 for what that remaining one is), reviewed/provided guide to rbrunner on completing 8076, and for now moving back over to reviewing 7760

Thanks for that, will start to work on 8076 this evening, let's see I will be able to get in before the branch or not

thanks for the updates

3. discussion, anything to discuss?

aside from compilation errors/that reorg issue moneromoo submitted a patch for, anyone pick up on issues during testnet fork?

Do we want to discuss reducing the 10 block lock (MRL issue #102)?

Rucknium[m]: sure

my perspective is it will be difficult to evaluate whether changing the block limit is a good idea

FWIW, smooth had a strong opinion against lowering it, and is a clever one (and yes, it's argument from authority)

With higher network hash rate though, that argument feels maybe lessened a smidgen.

why does magnitude of hashrate change things?

Law of large numbers.

The more hash rate, the less likely someone to have a huge part of it, and so the less likely to have large reorgs. I think.

I guess with pools, that doesn't apply as much as it should though.

Yeah especially pools like minexmr

yeah prob not a good argument with current pool situation

If there is a network problem/attack, the current stable situation could be disrupted quite a bit.

Also, referencing outputs by pubkey helps the issue with invalidating lots of txes.

we've discussed that before. did we decide to do that?

Just thinking out loud here and revisiting the active attacker scenario in UkoeHB 's MRL issue #95: If someone is spamming lots of transactions, don't they already have a good idea of which recently-referenced ring members are decoys since transactions that reference recent outputs would be referencing the attacker's own outputs?

I don't think so.

doesn't help tx size though, and wouldn't be forward compatible with any deterministic reference solution

How will Seraphis referencing outputs?

Rucknium[m]: yes that's the decoy set poisoning attack

For tx size, we can have hybrid pubkey/index. New outputs by pubkey (non deterministic), older outs by index (deterministic).

tx size presumably is only an issue for network bandwidth, as we would still store only output index on-disk

rbrunner: right now I have deterministic bins. Manually define a set of locations (indices) in the enote set, then deterministically select ring members from around those locations.

UkoeHB Maybe we could create pubkey-IDs which are hashed and/or truncated pubkeys to a certain length and which must also unique as well as the pubkeys themselves

Assuming lots more older ones (ie, > 10 blocks or whatever), tx size doesn't increase much.

Rucknium: yes, but if the attacker gets an honest user's tx that had made into the chain to invalidate, the honest user has a previously successful tx now fail, and then must re-construct that tx with even *more* decoys that everyone knows are decoys

UkoeHB You would get the benefit of reorg protection and hopefully they wouldn't take up too much more space than the (64-bit I think it is) current way of indexing outputs

Though the "how to have deterministic while plugging N non deterministic outs" problem is not obvious, but doesn't seem insurmountable...

moneromooo: for me, deterministic means generating multiple locations from a single seed; it's hard to map a set of indeterminite locations into a deterministic representation

Well, if your deterministic algorithm picks a locatoin that's too recent, then pubkeys are listed there (as many as needed to fill the bin).

If only the bins are deterministic but not the actual outputs selected, then where's the advantage? Any wallet who doesn't conform to that will stick out

endor00 If they didn't conform I feel like it would be hard to create a valid ring sig

And if your implement the wallet such that it remembers which out it picked from that bin in case of a reorg/resubmit, then you might as well have deterministic inputs

jeffro256[m]: the reason I don't think supporting unique onetime addresses can work is it creates problems for 'tx engineering' things like atomic swaps. If you can block a tx-being-constructed from the chain by publishing one of its enotes, that would break any protocol that relies on the tx-being-constructed from being publishable.

merope: the outputs selected are deterministic, the bin locations are not

@Ukoe How would you be able to block? Just from virtue of smaller brute force space ?

Oooh ok, so random bin location but deterministic output within that bin

That seems like it could be tuned

jeffro256[m]: "and which must also unique as well as the pubkeys themselves " If you can't submit a tx because it contains some duplicate thing with another tx in the chain (other than key images).

All these annoying complexities are why I recommended 'floating outputs' last year (which wasn't received well...).

moneromooo: it's hard for me to imagine how it would work, although I'm open to suggestions

UkoeHB Except you can choose your own pubkey which means you could control your own "pubkeyID" cause it would be determinsitically generated from the pubkey. It would add some overhead for sure (checking uniqueness), but a hash is involved, it could be hard for a bad actor to reverse engineer a value to conflict

jeffro256[m]: anyone who is party to an off-chain tx engineering protocol (like atomic swaps) can see all the in-progress txs, so all they need to do is copy-paste the onetime address into a dummy output in another tx (with 0 amount); any duplicate check on onetime addresses will block the engineered tx from submission

I prefer binning though

prefer over what?

UkoeHB: I was thinking somethig like: for (i in 0..N-1) { O=deterministic_pick(); if (age(O) > 10 && tx.outputs[i] != O) return false; return true; }

Then the sender writes a pubkey, not an int, in any tx.outputs[i] which is young enough.

A bit handwavy for sure.

Basically when your deterministic_pick funciton returns something young enough, you allow anything.

referencing by pub key still doesn't fully negate the issue if decoys that are referenced are non-honest users' decoys which get reorged away (presumably whoever is triggering a deep reorg is also spamming to inflict max damage for this too). I think the root issue is still there

jberman[m]: +1

UkoeHB Oh yeah you're right, but what's stopping that from happening currently ? Pubkeys can only be sent to once, correct? Or is it just spent once ?

Pubkeys are not forced unique.

moneromooo: I think that's floating outputs (what we have now). So you'd have a bunch of ring members deterministic, then optionally any number of additional members as 'floating' (not deterministic) pubkey references.

They arguable should be. It was deemed not worth the bother (Extra db, extra lookup).

jeffro256[m]: right now the wallet will only try to spend the highest amount among outputs with the same onetime address

I originally wanted to enforce unique onetime addresses in my seraphis poc, until I realized the issue with off-chain tx engineering stuff.

Does "I think that's floating outputs" imply a flaw with those ? I do not have the background knowledge to map it to the implied thing you refer to.

UkoeHB: That's devious. I legitimately never considered that as an angle. ... new proposal for the RPC to allow checking if a one time key exists on chain so wallets can easily check that way?

moneromooo: not really, it's just an easier way to think about it imo

moneromooo Interesting. I had the misconception from somewhere a long time ago that pubkeys were completely unique but now it makes sense why they would not be. I guess you could "sort-of" patch that problem with relay rules, but its not a very strong guarantee

We have /is_key_image_spent but AFAIK, not /is_key_onchain to check against burning attacks

kayabaNerve: it's not like a wallet will make a duplicate onetime address on purpose (so idk what an RPC endpoint will gain you); you need a custom wallet

My frustration is the only way a wallet can securely receive funds is if it knows the entire wallet history for all of time. An RPC route, against a trusted daemon, would allow it to only sync the relevant tail blocks of its existence and then simply check for each input it receives if it's malicious.

It's not about sending such outputs. It's about extra certainty when receiving funds.

ah I suppose that would be useful (although then you also need to get all enotes with the same onetime address and figure out which one has the highest amount)

As a side note, while I know we have trolls, I really hope our community doesn't devolve into commentary on paid trolls existing unless we have literal evidence of that. It tears the community apart while making us look insane. Another coin's community recently went down that path and it's... hell.

UkoeHB: To optimize, sure, yet I personally care more about dropping the latter inputs as invalid and moving on.

It's a simpler flow and the malicious sender burns funds you consider not received. Same as if they never sent.

that would open another vector for breaking tx engineering protocols

How so?

Send 0.0001 XMR, then send 1 XMR, yet it only considers 0.0001?

yes

The malicious sender is definitively malicious though. It's perfectly fine to say they only sent 0.0001 and walk away accordingly.

With the atomic swap proposal, it'd be a wrong amount lock. Sure, they had an offer for a valid amount lock... but who cares? They're actively malicious. Walk away.

no, the problem is assumptions that are made off-chain before anything is even submitted to the ledger

... oh

Right, this is still a DoS

... got it

yep

And that's why we have is_key_image_spent because it's actually cryptographically secure

👍

we are approaching the hour, anyone have other comments/questions to address? we didn't get too far on our 10-block-lock discussion lol

Still a hard problem, but I think we could sort of fix that with a robust zero-conf wallet

how so?

the main issue is funds in the lock can't be spent at all

you could make a tx spending those funds and queue it up I guess

Yeah I think there's a wallet (cant remeber the name) that is working specifically on that problem

Or maybe it was just an idea thrown out there. If your wallet can guess (or you tell it) roughly how much money you're gonna spend and when, it can break it up into appropriate amounts

ah yeah I heard about that project, not sure the status

And on the other side, accepting zero-conf txs as a small merchant in Monero is still pretty dang safe

Actually, there is a roundabout way :D Technically, Townforge is a fork of monero, and you can freely move money between output based and balance based, and when transacting between balance based, you have no lock period :D

I think that's Monerujo with "pocket change". It doesn't help the issues that Haveno and similar services will encounter, however.

OK, it's cheeky because no ring sigs.

(in the balance based section, there are ring sings in hte out based section of course)

moneromooo: If it still has amount privacy, and you only ever fund new balance accounts (so you have a dedicated account to receive, and then you can create new accounts with deposits to send)... that's actually pretty qual

alrighty, that's the end of the hour; thanks for attending everyone

But it could be considered like a side chain. Move money to the "fast" side, make easy transfers back and forth. Move money back to "main chain" when done.

The balance based one has no privacy. Only when you jump back to output based.

:(

Almost like there's no free lunch...

Except you could still do commitments and bps :(

*but that may have implications for townforge not viable :p

Not under 100 bytes.

I haven't looked it at all. I just kinda like this idea.

True

Sorry. In fact, visibility is kinda on purpose on the balance based side.

Yep

jeffro256[m]: you could at least let your identifier be a hash of onetime address and amount commitment. If there are duplicates of those pairs, it will be irrelevant because the amounts will be the same.

UkoeHB: I wonder if we even need a two key system? Amount commitments should be unique.

I don't dare to suggest linkability proofs under a one key system, though I do know we're doing squashed membership...

kayabanerve[m]: how would you do balance proofs?

UkoeHB: For an account system or for a one key system?

For a one key system, the initial premise I don't dare to claim is fleshed out or even notably thought about, is using the blinding factor as the one time key.