<LiquidSnake007 "im looking for business plans/pr"> monerointegrations.com

I'm inspired to do another Breaking Monero episode on unlock times

Someone can use unlock_time when sending funds to others and better track the spending of these real outputs in theory

Obviously this would be a detectable attack

But imagine a dust poisoned output attack with an unlock time

I hope more wallets will make outputs easier to manage in the future

and such an attack would be easily foiled by the wallet highlighting you got a small input with unlock time and letting you freeze it for example

Hi, saw that sgp_ pinged from the earlier meeting

Huge thanks for the support on BP+

And yes, the new version of Lelantus does require that addresses be public on chain, even for their confidential transaction type

It removes the self-spend requirement and improves the security model, but would require either trivial address linking or single-use addresses (like is typically recommended for transparent assets)

Neither Arcturus nor Triptych have this particular limitation; they support the current Monero-style separation of amount commitments from one-time addresses

And I suppose there is no way to enforce those single-use addresses?

Well, there's no way to enforce them in Monero either =p

Other than to make it some kind of consensus rule

Sure, but they technically lead to a burn if re-used in Monero

Yes, but that's a wallet thing

You could do the same in Lelantus, presumably, if you wanted to

I don't know if this is being done in any implementations

Er no, I spoke too soon

You'd have a key image reuse in Monero

scratch that, d'oh

You could still enforce in Lelantus by a consensus rule

Anyway, just thought I'd confirm what sgp_ had said earlier

I had heard the term "shielded address" used at some point to describe the new Lelantus addressing structure, but it's not the same as, say, Zcash

If we are able to enforce it in Lelantus through consensus rule, what is the downside?

^ sarang

Sender and receiver would need to communicate to provide fresh addresses for each transaction

dEBRUYNE I'm guessing there is also the downside of checking the entire chain for addresses every time, just like with a potential fix for monero's burn bug.

sarang: Ah I see, that would be inconvenient

Yeah, the Monero addressing construction supports non-interactive one-time addressing

Lelantus does not

If you post a Lelantus address somewhere and receive multiple transactions addressed to it, they are immediately linked in the clear

Fortunately, you can get the same logarithmic scaling in Arcturus or Triptych while still supporting Monero-type addressing

Seems either of those are more worthwhile to pursue then

It would be nice to do an updated size/time analysis against the updated Lelantus construction

It changes the transaction structure and adds some new verification requirements

Addresses are also longer, but I don't know if this is really a big deal in practice (maybe for QR codes?)

Oh, and very preliminary tests on BP+ show a nice speed improvement, which folks might be interested to know

so speed and size? nice

indeed

Speed benefits are highly dependent on number of outputs and batch structure though

However, under no test conditions did I find that BP+ is slower

At worst it's marginally faster

At best it's several percent faster

But again, these are very preliminary results

oh i see the convo about bp+ was here

sarang: how much (relatively speaking) tinkering needs to be done to implement bp+?

and will it require both maths and code audits?

It should receive a code audit, most definitely

and is the pretence that transaction size improvements are in the region of ~6-8% correct?

As well as both prover and verifier time improvements

so ~6-8% is a correct estimate?

For the most common transaction types (1-2 and 2-2) the improvement is 6.6% and 4.9%, respectively

It's a decrease of 96 bytes per transaction, regardless of input/output structure

That's the size improvement, to be clear

The time improvement does depend heavily on batching and structure, but in no cases is statistically worse

(there's a lot of variance in test timing, so these are mean and median results over many test runs)

thanks sarang, that's solid info.

np

Once I have the code completed, you'll be able to run the performance tests on any machine you like, of course

FWIW I've initially seen verification improvement between 1% and 8% or so, across different test types and parameters

Proving times are much better overall, and I haven't worked on optimizing that yet

There's still quite a bit to do, of course

there are always things to do; life would be boring otherwise

Heh sure

I mean in terms of documentation, optimization, tests, and other things that will hopefully make auditing much easier

I've already included some optimizations that are extremely useful, but need careful documentation

To your earlier question, stuff like function signatures are the same (up to naming!) as for BP

So I would expect a smooth transition if it's decided to deploy this

Looking back, it's pretty impressive to see how much better tx size and time have gotten over the years

Used to be what, something like 13 kB for a 1/2-2 transaction?

and super slow

If BP+ is deployed, a 1-2 tx will be 1.3 kB

and a 2-2 will be 1.8 kB

that's like a tenth of what it used to be...

I should re-run the old verification numbers at some point and see the overall cumulative improvement too

so basically you are saying you are a transaction size barber?

lol

Not just me!

Lots of great work by a lot of people

We also get better formal security guarantees from some of these new constructions (e.g. CLSAG, BP, BP+)

Plus it's fascinating to see so much ongoing and new research by so many groups

Omniring, Lelantus, RingCT 3.0, some MW work, stuff from Zcash, etc.

Tbh, I don't see a comparison to Lelantus as super useful if we're not going to use it because of the one time address issue

So where do things stand for solutions like Zec with full-txo anonymity set and no trusted setups? still pie-in-the-sky?

sgp_: more of a curiosity than a practical metric in this case

Inge-: ECC (the company behind Zcash) has a recursive proving technique they've worked into an instantiation they call Halo 2

It's in a weird place, TBH

The code is being developed on GitHub, but their commit messages and PRs are basically empty, and the commenting and documentation seem basically nonexistent

sounds typically corporate

I thought ECC was turning everything over to zcash foundation

this doesn't sound like it

This is odd, since the initial Zcash work had extensive development and implementation discussion on GitHub

However, they've also significantly changed the Halo 2 licensing

I wonder if this new development model wasn't a very intentional internal decision

Anyway, to answer the question... it could be that Halo 2 ends up providing useful efficient transactions for Zcash without trust requirements, but frankly they aren't giving enough details to know

sarang: I seem to remember you commenting on Halo 2 quite a few months ago, basically saying the same thing ...

recursion still has to have a starting point.

Some community experts asked for details on their forums, but were not given any practical details by ECC researchers

Inge-: yeah, nothing has changed

And Halo 2 is the only horse in the race currently?

You can see their repo, but all the commits and PRs seem suspiciously devoid of any useful information or detail :/

Inge-: for Zcash? Who knows

Like I said, ECC seems not to be doing forward-looking design stuff openly anymore AFAICT

no I mean in general, things that COULD be a future candidate for Monero

Oh ok

more than "forever increasing ring sizes"

Inge-: ideally, an accumulator-style transaction protocol requiring general trustless proving systems

Right now, no implementations provide this in a way that's practical

not impossible, just impossibly high resource costs?

Halo 2 is not some magic silver bullet... it's a way to do recursive proving, but that doesn't automatically make everything Fast And Small Forever

You need a construction that can actually use this technique, and even then, there are other practical considerations that right now ECC is refusing to discuss

Perhaps they will at some point, and I hope so

Inge-: right

One thing has changed. I've stopped asking about it as ZK proofs or ZK-SNARKS. PROGRESS!

eh

*heh

Yeah, ZERO KNOWLEDGE is not a magic wand that gives you anonymity

It's a useful property of many constructions that can be used as building blocks for transaction protocols that could give useful anonymity (as part of This Balanced Breakfast, as they say)

Arcturus, Triptych, Lelantus, Omniring, RCT3... they all use zk proofs

It's very, very unfortunate that "zero knowledge" has been wielded as a marketing term

I don't think that's helpful for users

<sarang "It's very, very unfortunate that"> I think I’d say in a protocol that zero knowledge is like ketchup. The main course is usually the information theoretical part and the sides being the cryptography

In an argument protocol*

Heh

My point is that an overlying security model might deal with anonymity

and perhaps having a zk proving system makes it straightforward to establish a security proof for that

But maybe in a particular security model, witness indistinguishability suffices

But it's not like plugging in a zk proving system into some random overlying construction magically makes it "anonymous"

So statements like "we use zk proofs" don't inherently have any practical meaning

<sarang "But it's not like plugging in a "> What if I give the protocol a cool name :)

Well, that's another story entirely =p

<sarang "So statements like "we use zk pr"> Yeah it would be interesting to see what protocols are using zk but don’t actually need it

e.g. we never built an extractor for MLSAG/CLSAG that would be needed for zk

But you can still establish anonymity definitions without it

And you can flip that script... you could easily take a zk proving system and build a terrible transaction protocol with awful anonymity guarantees...

so easily in fact, that ...

Note that I say this as someone who renamed Triptych-2 to Arcturus...

Naming does matter

without a doubt

Triptych-2? missed a chance to call it Hextych

lol

I considered "Polyptych"

but realized nobody would ever spell it correctly without looking it u

*up

including me

I jokingly recommended Triptyzk

Just to include zk

-____-

lol

It could have been useful to remove this absurd use of "ring signatures" vs "zk proofs" as a proxy for anonymity set size

I mean, that's how initial implementations' transaction protocols worked, sure

Yeah that's on the ECC for abusive marketing

but I think it can easily become almost misleading if not explained properly

ECC has been misleading at every oppty

I made some fun charts last night twitter.com/JEhrenhofer/status/1332552672185098240?s=19

Including a cumulative one haha

I am still extremely interested to know how much Quesnelle-style pool interaction analysis still applies to Zcash

^ yes, but no one has bothered

I've requested (on Zcash forums, etc.) that someone with access to this kind of analysis tooling examine it

but AFAIK nobody has done so publicly

I think that's a _much_ better metric for the practical safety of their pool approach

"value of the pool" is not useful IMO for individuals

Much like how in Monero, individuals may need to consider repeat poison transactions, network threats, etc.

The whole ecosystem is complex

and reducing security to something like a signature scheme or proving system is useful to a point, and then not useful

FWIW I did try to get some Zcash tooling updated to do this analysis, but it just didn't work

sgp: you decided 0/0 is 100% ?

hyc: FWIW I don't agree that ECC researchers have been misleading... I think they have generally tried to be accurate and correct in their work

That is not to say that they have been transparent about their work, which is different, and likely depends on leadership decisions

*transparent about _all_ their work

I personally would love to dive into the new Halo 2 stuff, but there's nothing out there except code without useful documentation or commit messages

that may be true, but ECC marketing messages prob aren't dictated by their researchers

and "the code is the comments" isn't useful, either in Monero (hint hint) or in Zcash

Maybe, but I don't want to throw researchers under the bus here

that isn't fair

they chose wher eto be employed.

it is 100% fair.

Eh, not really a research discussion at least

ok

I ought not to have deviated to that

I'll classify Halo 2 as "interesting if true in practice"

which has yet to be seen :)

The most interesting possibility about recursive verification might be how it could apply to transaction verification

Their early tests IIRC were only for block verification, which seems inherently recursive

There's other related work being done on things like curve choice and other implementation specifics that I'm very curious about too

Unfortunately, any code they release under their new license (as I understand it) is restricted for a period of like a year

but then appears to be open

Is this common in the FOSS world?

it is becoming common in corporate environments

the rationale is "we need to monetize our work for at least <1 year> before giving it away to everyone"

Hmm, I can see the benefits for the authors, I guess

Sounds like a patent, no?

mebbe, but less than the 17yr patent term

right right

but the same motivation?

I guess yes

I mean, I have no desire to release code under such a license...

a patent without all the lawyers and registration fees

or, a trade secret with a fuse.

I worry that this will also incentivize those who also build the underlying math not to publish their work

yeah it's troubling. but if they keep it to 1 year, I guess it's livable.

Since you can't copyright/patent math

but you can copyright the implementation

One thing that's nice about cryptography is that preprints are typically the way to communicate research quickly

but if the trend is to lock down implementations for a period, and the implementers want to prevent people from doing separate implementations in the meantime from the math, this slows down the openness of the preprint process

makes sense to me. analogous to alpha/beta software releases

Maybe this isn't the case, who knows

ah. yeah

Certainly feels like a big change though

But who knows... if the end effect is to encourage research because of a short period of being the sole benefactor from it, maybe that outweighs these (possibly nonexistent!) risks

Kinda like how patents are supposed to work

it's the same curse of profit motive

Zcash is an interesting petri dish for this stuff, since they have a lot of capital involved

it's a shitty model for research. need to get things like Xerox PARC back.

I disagree with many of their business decisions, but there's a lot of research going on related to that eosystem

*ecosystem

and TBH having a variety of funding models seems like a good way to determine the best ones

At least, overall... certainly not individually

e.g. BP+ was done under a new-to-the-Monero-community funding model

Maybe it works more broadly, and maybe not

meh. when you involve VC funding, you're on the wrong path.

Well, doing BP+ under the MAGIC umbrella seems more akin to how ZF operates

Albeit with different funding sources

they will always prioritize quarterly profits over anything else.

ZF is a promising change from ECC, yes.

FWIW ECC's owners (I don't know who these are) are apparently "donating" (I don't know what this means legally) some kind of control to a nonprofit: electriccoin.co/blog/eccs-owners-to-donate-ecc

So the VC model no longer seems to apply

Having a nonprofit at least ensures that the use of funds is restricted based on purpose

Seems like a good move

agreed

it's not a guarantee. there are plenty of nonprofit CEOs still milking their orgs.

but it's a step in the right direction

I think it's a very interesting experiment to apply this kind of nonprofit model to Monero-related research

Granted, the funding model is very different

but at least the nature of projects and the accountability seem quite similar between ZF and, say, MAGIC

licensing vs not licensing software has interesting market structure implications; if you can't profit from gating access to a service, the driving thought process behind making it must be different; the people who _actually want the service to exist_ must fund its creation instead of those who want to sell it to the users; investment in the service must be directly related to the _consequences of it being

used_ rather than the ability of the service to generate sales; basically, it peels away one layer of complexity in the market process, which would seem to make it inherently more efficient

What do you think the implication is for something like Zcash, where the network itself generates the revenue funding the organizations doing development?

more efficient in terms of providing the means for consumers to meet their ends, not necessarily making it easier for service makers to figure out how to make services that are worthwile

I don't know enough about economics to have a solid grasp over whether/how the incentives appreciably change in this case

there is at least one clear effect; the organizations will be greatly disincentivized to do anything that could reduce exchange rates with fiat

Would that increase overall liquidity, which seems beneficial?

in the extreme case, it could even mean compromising on privacy features in order to comply with increasingly onerous regulatory requirements

Well, their approach seems to be maintaing the pool approach, which seems to work for them so far...

at least in terms of exchange support

As stated before, AFAIK there's no up-to-date research on whether pools are used safely

On a topic actually related to Monero research, I saw some questions about the tradeoffs of BP+ deployment

It is a size and time benefit, but would require an audit, and additional code for a new transaction format

Any thoughts on this?

is it impossible to translate old proofs into the new proof style (spitballing)?

I think most people have reservations about sensitive code being touched for a relatively marginal (evidently, this is a bit subjective) change

^ sarang

I think the new transaction format changes can be mitigated by, for instance, implementing it along side Triptych

UkoeHB__: this is not possible

what would be the point of such a translation?

FWIW transaction format changes have been quite smooth in the past.

As a quick reminder, BP+ reduces typical transactions by 5-7% (a fixed 96 byte reduction per transaction)

hmm I was thinking you could deprecate the old code, but that doesn't work since you always need compatibility

and reduces verification time by maybe 1-8% based on initial tests

Proving time is also much faster, but this is less important in practice

BP+ proofs are a drop-in replacement for BP proofs

and retain the same compatibility with other constructions currently under R&D here and elsewhere (e.g. RCT3, Lelantus, Triptych, Arcturus)

since those constructions simply require range proofs as a black-box construction

(Omniring includes its own range proofs)

it seems worthwhile to me; it may depend on the PR size and complexity to evaluate if it is worthwhile

you don't need to translate the proofs. you know what is being proved, you just need to generate a new proof in the new system.

We already don't verify old Borromean-style range proofs without a flag

This could be done for older BPs as well, if desired

Anyway, for each BP prove/verify function there's a corresponding BP+ prove/verify function

I've tried to keep it fairly modular there

The rest of a deployment is updating the transaction format, consensus rules, etc.

8% here, 8% there... pretty soon monero will be making your processor run faster

Monero makes my computer faster?

Already does. Makes your CPU switch to performance mode after running for a bit.

(not actually tested)

Can we patent this process and sell it to Microsoft

Monero makes computers faster *

*) In participating universes