Greetings,

Oh, thats mostly IRC proxy right ?

monerujo.io/recources/crazy_secure_passphrase.pdf, my android's GUI died, but able to adb shell to get into the console of the phone via twrp recovery. I suppose the whole android keystore system should be intant correct?

I got files, tried restorting on other phone, then just realized about this amazing crazypass thingy )

Since, i also made full backup of the old device, along with - /data/misc/keystore/user_0 (where 10112_USRCERT_MonerujoRSA and 10112_USRPKEY_MonerujoRSA is located).. and copy of /data/media/0/monerujo with 3 files (main main.address.txt main.keys)

koe hmu

endogenic email me ukoe⊙pc (don't pay for irccloud any more)

it sounded like within an input's mixin duplicates are disallowed by the standard output selection algorithm; are duplicates allowed between different rings of the same transaction?

nvm will put to stackexchange

Yes.

moneromooo: You sound like you know what you taking about, any thoughts on my crazypass idea ? )

I mean on my crazypass issue.

can you help dear moneromooo by clearly describing the issue?

Oh, sure thing.

and actually your reddit post is probably enough

I actually have it whooole written

down )

Yea, I thought i would point him out to the reddit page

a bit )

this irc channel not a great place; #monero-dev better

incase he has some thoughts on it :p

oh, apoligies.

probbably not reddit either,

github issue would of been better

))

yeah

I can't it do it twice now, ( Yea, was bit stressfull last 48 hours )

so havent really thought it all tru

afaik monerujo is not related to moneromooo anyway ^.^

ah right, he's monero world guy

right ?

Actually, no.

Probabbly not, cause of mistaken identitty

)

Happens to brightest of us

I see

I have no idea.

Yeah, There probably are just handful guys who actually know without doing the research/reading the code. For some reason i mistaken you that you worked on monerujo code, espcially the crazypass function.

Whole whitepaper thingy about crazypass was written by m2049r, as it was most of the app's code i guess )

Hope will catch his attention.

Thanks, no worries.

sarang, i have a few comments about triptych multi

and a request

sending by PM

Thanks suraeNoether; I'm still working through your IACR version suggestions

Research day!

hello Isthmus

What're thoughts around plugging info leaks from high-precision fees?

Maybe something to discuss at next MRL meeting

If you really want to out yourself, there are plenty of ways we can't fix.

True, it's just our job to stop the ones we can :- )

I think we should first know why those people are using those fes.

I dunno. I'd stop the ones that are our fault.

This was discussed a while back too

IIRC

We discussed it briefly a few months ago, but it was too close to the code freeze so we tabled it to circle back

I think it's good to discuss

Definitely bring it up at Wednesday's meeting, Isthmus

👍

Two apparent reasons are fee sniping (paying 1.1x standard fee to jump ahead of the core software usesrs without paying up to the next fee tier) and some odd implementations that have hardcoded fixed round numbers (0.002500000 XMR)

Eyeballing, those two account for ~80% of the weird fees, and can both be mitigated (e.g. by coarser resolution)

Also, other privacy coins have the same information leak and need to patch it. It'd be cool if Monero was leading the pack on that anti-heuristic design feature.

It's sad. I find myself close to not caring anymore.

People will just find all sorts of ways to make things worse for others for just a tiny benefit to themselves.

Sometimes not even measurable.

Let's not allow 2020 be the year that the R&D team for the world's leading privacy coin gets burned out and gives up.

I'd understand laziness. But here, it's actual effort expended to make things worse.

It's natural to feel defeatist when we're perpetually plauged by 3% of users that will somehow stick out despite some privacy feature (e.g. coarse fees). :- /

I try to remind myself to focus on the 97% of people that we *can* keep safe, who have no clue that their exchange's home-rolled software or phone wallet is [probably unintentionally] marking their transactions.

But it's definitely frustrating.

it is not for you to finish the task but neither are we allowed to lay it down

i figure it's part of the very game of cryptocurrencies that people are trying the break them

That's not even trying to break them. That's the equivalent of pissing over a wall because you didn't even care there could be others below.

Now, if you knew there were others and that was the point, then fair enough.

At least you used your brain.

so just to confirm i understood, this is people sniping to get into blocks rather than them using their own fee code which could be mitigated by factorization?

fingerprintability is definitely mitigated by shared client code

the fee code is trivial to extract too, fwiw. mymonero-core-cpp has it pulled our

our

out

i looked up etymology of "pissing over/on a wall".. after getting past the pornhub results, a bible reference explanation made a point of saying only guys can do so.. i guess that puts them in a fungibility puddle ?

Yeah @endogenic, I think they're calculating the standard fee, then tweaking it up by a hair

Sure it's a greedy maneuver, but to be fair, probably most or all of its practitioners don't realize the privacy implications

It definitely wasn't on my radar until 2019

Likewise for people coding fixed absolute fee (e.g. 0.002 XMR) or fixed fee per weight (e.g. 0.01 XMR / kB).

An exchange dev might have thought it was the correct decision to harcode a fixed fee to push through their users' transactions rather than working with a more complex dynamic algorithm that may be intimidating in a high-stakes production environment.

You don't even have to do anything. The wallet will do it for you.

one potential mitigation of fee sniping would be for the standard wallet to randomize fees a bit

fmpov tech, product interfaces shouldnt allow people to do things that mess up the state or violate assumptions.. i figure randomization could be easy to fake .. sniping could still happen and skew the distribution

but im not sure if consensus to fix fees in brackets makes sense.. *backs out of room slowly*

not sure what you mean by 'fake' randomization. yes sniping would skew the distribution but thats probably less bad than the status quo. probably

People would just cancel and try again. I think Isthmus' suggestion is the best, though it'll likely need to be careful not to break the smooth curves vs block size.

most people would not cancel and try again for a tiny amount of fee randomziation

the existing fees are mostly arbitrary already, and most people dont care

smooth what i meant was not easy or possible to detect randomization on verification side

yes i agree

If I'm a fee sniper currently, I already have custom software that takes the default fee D and adds some extra amount E.

If randomness was added in the core wallet, then I'd just change one line of code and broadcast my transactions with D + E + max_randomness.

you probably wouldn't

Most no, but probably a large portion of those people Isthmus pointed to would.

well, max randomness is wasteful right?

you could get away with a bit less and still be ahead of the crowd, and cheaper

Depends on whether your priority is speed or savings

And your tolerance for the occasional transaction getting stuck for a few blocks

your priority ois clearly both otherwise you wouldn't be doing this

if you want to be 100% sure of not getting stuck you woudln't snipe, you would add a healthy margin

snipe = optimize for both cost and time

Yes, so the fee snipers today must have some tolerance for the occasional transaction delay.

Having hard fee levels will also mean you can't make a tx and broadcast it more than a few minutes later, or the block size might have changed, making your fee a non multiple of the "correct" fee.

IMO fixed fees are ultimately non-viable. we should really expect to abandon it eventually

Doesn't matter now, but would when bllocks are > 300000.

helpful mitigations are okay, but lets not double down on serious effort to preserve the doomed concept

Discrete fee would need to be applied to absolute fee *not* relative fee

once there is a serious fee market, you won't be able to read anything from fees except the urgency of the sender, which is inherent (can't be removed)

If you do that, doesn't it fuck up the dynamic block sizing algorithm ?

The dynamic block size algorithm is *designed* to work with 4 discrete fees

Unless you always highball it I guess. But then it'll be expensive for all

If it's being held together by the few people being outliers, then we have bigger issues :- P

I would definitely want to hear @ArticMine's input

It's designed to work with 4 variable fees.

That's true, but I think as long as the fee bins are on the order of the spacing of the dynamic fees, the same properties carry

The risk of delayed broadcast causing fee to be below other txns in the mempool is the case whether continuous or discrete fees

discrete fees are bad. they will cause higher volume transactors and potentially wallet developers to make deals with pools to get their transactions prioritized independent of fee, which will then also be detectable

(by transactions which don't 'belong' in the block on account of fees, but end up there anyway)

also is centralizing

In that case,🤔 we should start considering other ways to mitigate this

randomized fees can't be enforced. I don't see how anything unenforced can stop outliers. stupidexchange X will still just use 0.2 xmr per tx because mah speed

yes, you can't fix stupid

you can mitigate against the intelligent behavior being harmful though

We gotta watch out for slippery slope, lol.

Why bother building seatbelts when there will always be *somebody* who won't buckle up? :- /

one way would be to introduce a measure of fee sniping into the standard algorithm, thereby removing its advantaage. but that's complicated. small degree of randomization is easy

why are fixed fees nonviable? because the blockchain isn't aware of value?

because of side deals with miners/pools

ah

is tx extra of constant size now btw?

as i said above

No.

to expand a bit, the response of the standard algorithm currently is to increase fee by some big jump (2x or 4x was it?)

it should be obvious that people will find that unattractive and seek ways to bypass it

the root cause of this is the standard algorithm doing something people find worthy of bypassing

Side deals with miners/pools are already an option, and make rational sense for anybody who makes frequent transactions and has an in-house mining algorithm

We might incentivize it slightly more, but it's not like we'd be opening that up as a new attack surface

"the root cause of this is the standard algorithm doing something people find worthy of bypassing" << interesting point

I think right now it's:

Slow = 0.25x

Normal = 1x

Fast = 5x

Fastest = 41.5x

So maybe what we're getting signal on from users is that they desire more intermediate levels

They desire no fees at all.

which is also possible.... or wait, was min fee made part of block consensus? or is it still just relay?

Isthmus: incentivizing it is the attack surface. Right now there is NO incentive for side deals. whatever you would pay to the miner as a side deal you can add as a small fee sniping increment and get the benefit of all miners accepting your txs

But yes, the signal we are getting (I'm ignoring the purely stupid ones, as I don't think they are signalling) is that users dont want discrete fees

I have not read a single complaint about about fees since BPs

selsta: from the observed behavior

OTOH it could be software made a while back that's working so no need to change it from their pov.

also possible, even likely (given price decline, etc.)

but then these same issues would likely return in the future if/when blocks fill up and/or the price goes up

There may or may not be side deals between *different* parties right now, but for companies like exchanges that have mining *in-house*, I think it's probably already rational to use that block space to mine transactions with lower fees than market.

agreed. which isn't good. this will create institutional fingerprints and non-institutional fingerprints

At least "this transaction was mined too early considering what was in the mempool at the time" requires analyzing the blocks against memory pool activity archives with sub-block resolution

Which is already a more complex analysis and less provable link than just leaving ridiculous fees straight on the chain

And there's plausible deniability... Was it "mined too early" or did the miner receive and include the low-fee transaction before receiving higher-fee transactions

Since mempool is not global or provable

im more concerned it will evolve to "institution x uses y fee, institutional n uses m fee"

That's exactly what we have right now

I just haven't done the deanonymizing back to exchange identities

i mean, is it worth revisiting fees? they're primary purpose is to prevent spam. secondary is to create a priority system. tertiary (for monero at least) is mining incentive.

And to allow the block size to grow.

well u know me. i always think PoW is the answer. here, just use PoW with min diff requirements for publishing a transaction to the network. dunno how the rest of the function of fees would work out, but its almost enforcable randomness for data that gets published.

Well, the fee only goes to the miner anyway, so I suppose we could make feeless txes and have pay-for-service to miners. But then you'd get designated miners, which is likely brittle.

And degradres privacy.

yeah i guess that disincentives any tx inclusion at all don't it

disincentivizes

Isthmus: 'this transaction was mined early' doesn't require analyzing the real time mempool, although that could help. But it can be visible from other transactions in blocks

Yes, it can be inferred but not proven (you'd have to make assumptions about what the miner's mempool contained at the time of the block)

Well, nothing can be proven really

Some idiot uses 0.05 as the tx fee. But when you see a tx doing that, it could be ANOTHER idiot doing the same thing

But it is an inference. It's all inferences pretty much

Yeah.

I think of transaction graph matching as a giant inference problem.

Just gotta work incrementally and chip away at information leaks that give the matching algorithm traction for linking transactions or sets of transactions.

Maybe disentangle the issue of fee sniping from stupid fees. I feel they are quite different.

Stupid fees could be addressed by not relaying anything outside of a plausoble range constructed from the last 24 hours of blocks.

People using stupid fees might find their txs no longer propagate and stop doing it

Good idea to separate sniping from stupid

After all there is a real feature that pretty much does exactly what they want (specify elevated priority)

They just need an incentive to use it instead of what they are doing now which still works

Or alternately change the specification of priority to something like N blocks the way bitcoin wallets do

"I want my tx in the next block if possible" is pretty much what we call higher priority now

Lower priority is "hopefuly some time in the next N blocks"

"Stupid fees could be addressed by not relaying anything outside of a plausoble range constructed from the last 24 hours of blocks."

^^ Interesting idea, and I think I have an idea for how this could be formalized and implemented.

Let F(H,P) be the fee in XMR/kB from the official dynamic algorithm at height H with priority P (1,2,3,4). This is a completely deterministic function of height, right?

We pick some heigt window W (e.g. 24 hr, then W = 720). Each node can just keep a rolling buffer with W*(number of priority level) elements and keep track of the allowed fee/weight values over the desired timeframe.

This would not stop fee sniping (unless the fees were ~monotonically decreasing over W) but would block the super obvious outliers

Oh and interestingly, fee sniping would be constrained by the volatility over W

Woah, it would disguise fee sniping as delayed broadcast xD

(well, depending on ages of ring members)

Isthmus: yes the fee algorithm is determinisitic. i'll have some more comments later

Brief update: lots of great updates on Triptych today

Pretty sure the multi-input version is now sound

and therefore we can update the preprint to include it

This is great for size and time optimization

The single-input preprint is also ready too, but is less interesting :)

Sounds as in you worked out the proofs for the fast version ?

Yeah, we're finalizing that now

That is most excellent news, congratulations ^_^

So we can either post the single-input version now and update later for multi-input, or just jump to multi-input right away

Single-input is useful as a multi-input linkable ring signature independently

Multi-input is useful for incorporating balance computations and all spends within a single proof

IACR archive doesn't clearly show updates, FWIW, only the initial posting (but it keeps all versions available for reference)

Based on my earlier analysis, the updated Triptych construction produces transactions 25% smaller than Lelantus (for ring sizes 128 and 1024)

For N=128 verification is 11% faster

For N=1024 it's 5% slower

But it fixes the tracing and one-time addressing issues from Lelantus

I'll send the updated version to Aram and see if he has any notes or suggestions

(Aram came up with Lelantus)

Worth noting that for updated Triptych, you can speed up verification by sacrificing proof size, and vice versa

the numbers I shared were for the space-optimized version

^ suraeNoether

Does Triptych work with multisig?

Yes, using the inversion MPC

Cool, are there any problems left to solve?

Wasn’t there this thing that every one of new schemes had one problem or so

Multisig draft: github.com/SarangNoether/skunkworks…verse-mpc/triptych-aggregate-mpc.md

Requires Paillier encryption, which is less convenient

or some equivalently-functional homomorphic public-key construction

Convenient as in?

It requires many-to-many communication, more general crypto requirements