Halo - old news probably

for those of you who are writing research papers, please consider submitting to the IEEE Security & Privacy on the Blockchain Workshop. Deadline is March 5, 2020, see ieeesb.org

koe: fyi: paste.debian.net/hidden/5c222de0

ah, testing the coinbase limit? nice; also, that nonce is pretty high, is next release (or current release) starting from a random nonce?

Yes.

Hello all; reminder that there is a research meeting here today at 18:00 UTC (about two hours from now)

Agenda, with some additions from Isthmus: monero-project/meta #430

btw sarang the Janus attack also works on the normal address - subaddress intersection, so checking the shared secret should also be done with outputs owned by normal addresses

but the extra pub key is only required for tx with at least 1 subaddress recipients; only 1 extra pub key for such transactions

yup

Given the space savings already possible with CLSAG signatures, it's minimal

I find it unfortunate that a tx with subaddress is distinct from without, but don't see an alternative that doesn't cost additional 32 bytes per output

Not to mention scope creep, since subaddresses are already two levels outside the protocol (one time addresses are one level outside the protocol)

Yeah, there has been discussion about forcing uniformity in that way

To some extent I like that addressing is outside the tx protocl

It helps to simplify signature/proof constructions a lot

for modularity purposes

koe: will you be available at the research meeting to give a brief update on the status of Zero to Monero updates since the first release?

yeah

Great

I also have a list of future developments, some new others more recently discussed

monero developments (e.g. clsag)

I was going to ask about that, in fact :)

Good morning everybody

good morrow

I'm available this morning, but I've been recovering from a sickness, and I've been thinking deeply about the security models for CLSAG. I've made a couple of pushes to my get hub this week also... I'm just giving everybody a brief update in case I get sick during the meeting again :-(

GitHub* my gawd

Try new GetHub! We bet you can't taste the difference

Sarang I am fairly sure that just our analysis of backes' linkability and unforgeability is already an important contribution to the cryptography community

Yeah, it's more subtle than I had previously appreciated

Fortunately I think that even though it's limiting, it's an improvement on the existing Liu/MLSAG proofs (which make a lot of restrictions on the adversarial players)

Notably that Liu/MLSAG assumed linkability and unframeability players produced correct signatures, which doesn't immediately follow from their unforgeability

Whereas we extend this to allow for corruption and certain oracle access, but under a different framework for unforgeability

Backes is interesting in that linkability doesn't involve any oracle access, simply the adversary's output to the challenger

but tying this back to unforgeability doesn't really work for that

The unforgeability game is stricter in the challenger-player interactions

If we can just show that satisfying the verf equations implies matching across ring indices...

Yeah, that would do it for sure

very comprehensively

It seems like this should be possible, given the way the forking lemma operates

The alternative is to restrict corruption in the unforge game, but that doesn't play nicely with reducing link/unframe back to unforge

I'm going to continue looking at how changes to the unforge definition would affect the types of challenger-player interactions with link/unframe

In particular, linkability

The way that proof currently works is by identifying a signature that has a mismatch between linking tag and ring

(via the pigenhole principle and properties of the linking tag construction)

OK, it's time to get started

"I find it unfortunate that a tx with subaddress is distinct from without, but don't see an alternative that doesn't cost additional 32 bytes per output" Heh, I suppose everybody can guess where I stand on that xD

Agenda: monero-project/meta #430

Logs will be posted there after the meeting

GREETINGS

hi!

hello

Hi

hiya

holla

Let's move to ROUNDTABLE

Isthmus: you posted some data on the agenda; care to discuss?

Link to data: monero-project/meta #430#issuecomment-576455137

Sure

First, glanced at distribution of number of outputs on miner transactions

This is mostly a historical novelty from back in the days of denominated XMR - since RingCT became mandatory at block 1400000 all miner transactions have been 1OTXs.

*single-output coinbase transactions

So that chart is for _all_ miner txns?

Throughout all of time?

From genesis block to last week

Courtesy of n3ptune's magic database xD

Another mostly historic novelty - altruistic transaction selection by miners who would include many/large transactions in their blocks, incurring a coinbase penalty that is not offset by the added fees. (In other words, they would have had a higher total block payout by mining an empty block.)

color is size, starting at blue = small

This seems to not be a very common practice these days

Altruistic mining could be banned at the protocol level, but at the moment I'm not inclined to do so

more advanced altruism based on suboptimal tx inclusion will involve more intensive analysis, which I provided pseudo code for this week, if that path is chosen

Any comparison against partially filled blocks rather than empty blocks?

@koe yea do you want to jump in

Yeah koe please do

koe: if you have a link to the pseudocode can you include it here?

well this week I: made pseudo code for Isthmus blockchain analysis, deep proofreads of several ZtM chapters, talked with cohcho and jtgrassie about uniformity of coinbase tx

more or less improved a roadmap of future monero developments: justpaste.it/5io6e which we can talk about some items

latest ztm2 draft, I have honestly been pushing off multisig edits, but not making no progress pdf-archive.com/2020/01/22/zerotomo…0-20/zerotomoneromaster-v1-0-20.pdf

Enforcement of exact block rewards seems straightforward and a good idea

pseodo code paste.debian.net/1127152

Regarding ZtM, are there topics in progress for which you'd like particular information or assistance?

currently working on multisig, and have already gone through most documentation available, but there are some things that aren't clear despite documents

so if anyone knows about multisig, Id like to discuss with them

otherwise will dive into code base

I'm not super familiar with the code base, but I'm familiar with what it's supposed to abstractly represent

Thanks koe

So if you have questions koe about how things are supposed to work (as compared to how things are currently implemented)

Lmk

ok Ill hit you up

Anything else of interest to share koe? You've clearly been busy!

well there are all the things in the roadmap, in particular enforcing 1 output from coinbase (since Isthmus found literally all coinbase for 4 years have been single output), and possibly enforcing single-type ring membership (only coinbase ring emmbers, only rcttypebulletproof2 ring members) since 99.5% of coinbase are owned by pools who are easy

to fingerprint

Single-type enforcement was brought up a few times by sgp_ in the past as well

see minexmr.com/pools.html where 99.5% of hash is accounted for

My concern was that a full segregation of coinbase outputs means certain heuristics are only moved "down chain" by a single hop

Meaning there's likely improvement for sure, but perhaps more marginal than desired

koe, do you still need proofreading of ZtM or are you good on that?

I'm in favor of enforcing single output coonbase txns by consensus. I'm in favor of enforcing block reward. I'm tentaticely in favor of type-restricted rings.

always need proofreading :) even after it's published lmao, I've received some good emails that are incorporated in v2

I actually was going to re-introduce the topic again here to keep it on everyone's minds, so nice timing

related: medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43

koe, I am have some notes that I need to send you.

I will try to get them to you soon.

ill look forward to them :) (email me)

Enforcing single output coonbase txns would prevent p2pool.

will do :)

Atoc, I believe that my mojojo branch is no longer bugging out, although data isn't being written to file how I want. The actual tracing game script I am running will be pushed soon(tm)

jtgrassie is p2pool your project?

AFAIK nobody is doing it yet.

But simulator is now successfully simulating a monero economy between Alice, Eve, and Bob to model flavors of EABE

cool suraeNoether I have been falling a bit behind and will catch up today and get you my thoughts

good to know the unit tests are working fine

Nice

It's all good, I'll still be plugging away

Any other questions/comments for koe?

no specific questions, but I have a related topic for mining pools besides coinbase outputs when time allows

OK, first, is Isthmus back? He had to step away briefly

Isthmus: care to finish up your data?

Also, it's not "kicking the can down the road" depending on how you implement it

(then we can move to sgp_)

But yea, moving on

Hold on

Discovered that everybody seems to use the miner_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) xmrchain.net/tx/7dfcc4e5d8bd772e337…52121503d9b4f3cb6587251292bf06ced9a

Why would coinbase-only not do this?

If you assume the spend patterns would be sufficiently different, I agree

Uhm, I could get in the weeds with this

On like 4 levels

lol

From an *on chain* perspective, there's two questions we can ask

1) Is this ring spending a coinbase

\me pulls up lawn chair

2) Which coinbase is this ring spending

#1 is hard to hide

#2 can be accomplished

making #2 unanswerable can be accomplished

I'm an evil exchange

With current system, I can fingerprint which pools my users belong to

Aah ha, this person makes monthly deposits that are 4-input transactions each spending from a ring with 62 B null padding, so I know that they have about 3000 H/s attached to minexmr.com

*each spending from a coinbase whose miner tx_extra has...

But with coinbase-only txns, we strip the pool-to-user link

fair

Sure, as an exchange I can look at each user, and their average number of coinbases per ring

And if it's more coinbases per average I could suspect that they're a miner

But that's about all

while there are some concerns with coinbase-only having only a layer of separation, I think the real benefits are being minimized slightly, especially to non-mining users

also, coinbase is currently polluting normal tx rings, since a large proportion are identifiably spent/not spent

koe: the newer weighted selection algorithm does help this to an extent (relative only to tx weight, nothing else)

One thing that is important about privacy is that third parties that have data like this are lawyer magnets. If an exchange couldn't possibly identify their mining user habits, they can't be hacked or subpoenaed to determine one of their customer's hash rates

In my ideal world, we have 13 ring members and two selection algorithms. Precisely 11 of the members are non-coinbase, selected with current algorithm. Precisely 2 of the members are coinbase(/coinbase-only) that are selected independently.

Isthmus: that would not be good for many reasons :)

notably, you need a set of at least 3

Oh, I'm not married to the numbers

Just making an example

(trying to avoid the misconception that adjusting our coinbase ring member selection algorithm will somehow be zero-sum with the rest of the anonymity set or users)

koe: I know that rbrunner (sp) made an implementation of multisig so it might be good to speak with him. I don't see him online now and haven't seen him for a little while but should still be around

on the other hand, I wonder if enforced ring types is too much like reacting to how people use it; although the same could be said for many other protocol rules

Anyway, I derailed Isthmus's discussion of his other data with this topic...

Also, let M be the minimum plausible age between any output and it's temporally closest ancestor coinbase

:- P

That can either be a plotable feature, or fixed for all transactions at zero

nioc ok Ill reach out

I think n3ptune and I may plot this for all outputs just to show the point

Other two things on the agenda - encrypted unlock time, and tx_extra in coinbases

I can get into these if people are interested

Sure, I saw your information about encrypted locks

(I also wish to address timelocks anyway_

)

Cool, lemme copypasta real quick

Oh, and for the encrypted + enforced unlock time, we have to decide on a format. Currently, 3 things are being put in the unlock field:

Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks"

Large integers like "1980000", presumably to be interpreted as block heights

Very large integers like "1578561720", presumably to be interpreted as unix timestamps

While normally I'd be loathe to bring real world time onto the blockchain, I am inclined towards this approach: encrypted unlock time is a future timestamp recorded in unix seconds, and each ring must include a range proof comparing the unlock time to the oldest or youngest ring member (I haven't fully thought this through).

The minimum lock time of 10 is trivial for any outside observer/miner to enforce by delaying (or rejecting) transactions with rings containing members less than 10 blocks old. This requires no mathematical validation within the transaction.

The encrypted unlock time could actually be defined as timestamp - 1500000000 to save a bit of space by removing the offset from some of time between 1970 and deployment, but that could be overengineering.

We have a relatively efficient way to do encrypted timelocks, as introduced in DLSAG

Small integers are block heights. If you put 12 now, it's pointless.

I'm 100% in support of encrypted lock times... I know that sarang has done some work into the requirements on that in addition to isthmus

The method is described here: github.com/SarangNoether/skunkworks/tree/timelock

It works as follows: outputs come equipped with a timelock Pedersen commitment (units aren't relevant for this at the moment)

"<moneromooo> Small integers are block heights. If you put 12 now, it's pointless." Ahhahahaha that's what everybody is doing. Lemme make a plot real quick

Signatures come equipped with an auxiliary plaintext time that's chosen semi-at-random

as well as a particular auxiliary commitment

There is a range proof constructed using all these values, and CLSAG/MLSAG gets a new set of entries too

This maintains signer anonymity, shows the timelock has passed, but does not specifically reveal information about it

The cost for CLSAG is 1 new group element; the plaintext timelock is replaced by a plaintext intermediate value

and the auxiliary per-signature commitment is 1 new group element

does this mean the no-locktime transactions will be indistinguishable from locktime ones? Or just that the locktime ones will have an obfuscated time lock?

The rangeproofs can be worked into the existing bulletproofs, likely for free due to padding

Indistinguishable plz

Depends on how it's implemented

indistinguishable would probably require no-locktime txns to have a dummy encrypted locktime

So the cost is 64 extra bytes per signature, and 32 bytes per extra timelocked output

Yep, you'd include zero locktime

and the rest of the process proceeds the same

So this is not free, but it's not terribly expensive either

Anyway, this information is to supplement what Isthmus brought up about how timelocks are handled now

It's completely offtopic but I personally like the idea that we can embed an arbitratry hash in a transaction in a way that is indistinguishable from other txs, for timestamping purposes.

Would only be half or a quarter of a hash in that case though

(using the encrypted time lock field)

@binaryFate if we add an enforced encrypted memo field, that would be a very good use case

binaryFate: well, you could always pick your txn key as the Hp of some message. is that not what you mean?

it works too, but require you don't lose your local storage.

sure. you want to be able to extract the message also, something like that?

just exhibit the message later on and point out to a past hash in the blockchain that timestamps it, without people taking notice this was a timestamping tx.

but if you have message you can get hash back, so tx key works perfectly I guess

oh neat

anyway, sorry to derail

Isthmus: take it away :)

Derailing conversation is a key part of research! :- D

I think that's where 2/3 of our interesting stuff comes from

*nod* i prefer these lively research meetings for sure

Anyways, last topic I had has been discussed significantly since I initially mentioned it. So I'll intro and then duck out of the way

You had some notes, Isthmus, on how timestamps are represented

I will most likely need to take off, so I'll bring up my other mining pool ring signature proposal (which I mentioned in the past) when I get back

@isthmus agreed, it seems that new ideas fluster that way.

Oh go @sgp_

ah, so very fast

there are special ways we can construct rings for public mining pools to protect the "integrity" of outputs (make it no longer publicly known what transactions they are spent in)

for public mining pools that share transaction histories, it's clear which outputs are change outputs, which are later spent by the pools

to avoid this, public pools can select rings using exclusively decoys that they create as payments to miners

that way, outsiders have no way to distinguish the output from the other outputs given to miners. saves one output per payment, per public pool

this is not a consensus change, but it would require a separate "public pool selection mode" or similar

Isthmus: how? payouts won't be from coinbase outputs

Aah, maybe I was thinking of something slightly different

Carry on :- )

this protects pool change outputs from being known as spent by the pool in specific transactions

that's about it, just wanting to make sure this idea is resurrected, since I introduced it nearly 2 years ago now

Thanks sgp_

In the interest of time, Isthmus please go ahead!

Everybody seems to use the miner_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) xmrchain.net/tx/7dfcc4e5d8bd772e337…52121503d9b4f3cb6587251292bf06ced9a

This has implications for privacy of all users. For example, I have a list of blocks mined by the pool that added 60 B null padding to each miner transaction. When this person creates multiple-input transactions to claim the reward, ring signatures offer them no protection.

(Multi input + miner fingerprint is statistically noisy, so we know when those outputs are really spent, and can rule them out as decoys in other transactions.)

To avoid fingerprinting, it's important that any implementation mimics the full hierarchy on any block. For example, if we accommodate {nonce, pool, proxy}, then every miner (including solo mining core software) should put random data in pool & proxy. Otherwise we've just made a fancier way to leave the same fingerprint. :-P

Anyways, others in this room have made a lot of progress on how to address this, so I'll let them jump in

Anyone have anything to add in particular to this?

nope, but I have to get going

OK, suraeNoether: any brief update before you go?

Otherwise, no worries

sarang is this the encrypted timelock? justpaste.it/2754y

just that sarang and i have been having some extremely deep discussions about unforgeability in CLSAG and the crappiness of linkability models... we are nearing some very valuable improvements to d-CLSAG as written...

i'll let him describe more; i've also gotten my matching simulations (apparently) working correctly on my matching-mojojo branch of mrl-skunkworks

other than that, i have to get going

sorry :(

i'll drop in later today for more of an update

koe: you include the auxiliary timestamp in the signature's extra commitment in the model I worked up

Isthmus: anything else that you hoped to share?

(sorry, trying to ensure everyone gets a chance to finish their presentations)

Thanks, I'm outta new material

OK, thanks Isthmus

I worked up some stuff on timelocks (shared earlier), did a blag post with sgp_ relating to supply auditing (to answer questions that often come up), and got into the weeds on security models relating to linkability

Linkability meaning the formal definition used in linkable ring signatures, not any particular transaction linking

koe: what you have may be algebraically equivalent; I'll take a look shortly

OK, did anyone else have something to share that was missed?

So many things to discuss today!

well does anyone have thoughts on enforced sorted TLV format for the extra field? I have spammed up the channel a bit recently, with that topic

Can you recap the benefits and tradeoffs briefly, for those who didn't see the earlier discussion?

If someone wants to stuff some random data in there, it's as visible as now, no ?

and pursuing coinbase extra field standardization by seeking an inter-pool committe

(note that monerologs.net has logs of this and other channels available)

What's an inter-pool commite ?

committee between pools

composed of

Oh you mean just talk to pool ops ?

lol yeah

these things are called standardization committees in industry

benefits of enforced sorted TLV + guidelines for use: a) makes sure all implementations are using the same essential format for constructing extra fields, since without guidelines or structure each implementation is ad hoc; b) for those who are privacy minded, there will be a clear way to blend in with other like minded implementers (for example,

who knew that the code base sorts field entries, but at least one live implementation does not?); c) leaves extra field almost as open ended as it is now, so those who choose opt-out privacy (choose to stand out from the crowd) for whatever reason, can still do so trivially

In the earlier discussions, were there particular opinions opposed to it?

If so, why?

tradeoffs: a) it may have limited real impact on transaction indistinguishability, especially among coinbase tx if most pool operators aren't on board; b) implies no stricter enforcement of the field will be pursued (which would directly address questions of indistinguishability; c) so far as coinbase tx go, many pools publish their mined blocks

(counter argument is Monero development is focused on on-chain, and can't concern too much off-chain activity)

Noted; thanks

Since you were interested also in the hidden timelock construction, any other thoughts on that as well (from your link above)

actually I just felt inspired, and wanted to confirm my understanding

Keeping in mind that the range proof can be absorbed into the existing one, meaning no effective change in size or verification for that portion of it

Your construction appears algebraically equivalent to what I listed

I dont know enough about CLSAG to make a real judgement

The CLSAG part could apply to MLSAG as well

Perhaps if we knew how much timelock is being used in the wild

The only difference is how the commitment to zero is handled in the signature

In MLSAG it would be _very_ expensive, but in CLSAG it adds only a single auxiliary linking tag, and makes the verification multiexp a bit more expensive

oh nice, I was imagining all those extra mlsag scalars

If people think it's worth seriously considering, I can get more precise timing estimates on those curve operations

Yeah, for CLSAG you don't add scalars

It is in no way worth it for MLSAG

either in size or extra verification

The current CLSAG data has some custom curve-op code for efficiency that wouldn't apply to this new 3-CLSAG timelock construction

(the Python code is not suitable for timing, only to see how it works)

Anyway

We're way over time

Anyone have ACTION ITEMS for this week they want to share?

(I find action items useful for me, to help prioritize and share those priorities)

I will continue working with Surae. Hopefully I can share more next week.

I have several... some additional work writing up comparisons of linkability definitions between a few papers, to get some timelock numbers (if it's seen as useful), and some data analysis relating to sublinear protocols

Oh, and one additional note... the IEEE S&B conference is coming up later this year

Both suraeNoether and I are on the program committee

It's a great event, and is seeking papers

If you have some work that could be worth sharing, consider writing it up formally and submitting

Ok cool

(you should note any conflicts of interest with the program committee if you feel they apply to you)

I went to this event a while back, and it had great presentations (but was not streamed)

Any other comments, questions, or final remarks before we adjourn?

Normally there isn't so much to cover in one meeting; it's a great problem to have :D

Going once...

going twice...

I will be focusing on ZtM2 multisig, which may be done by next meeting in which case Ill start in on bulletproofs; and anything else that comes up, perhaps work on updating the fee priority multipliers for surge situations (emails with ArticMine)

Last thing, I didn't realize IEE had Security and Privacy on Blockchain. That's pretty cool.

I'm happy to help with bulletproofs koe; I have a branch for it in my ZtM repo

atoc: it's a great event

all in good time :)

I'm very happy to be asked to be on the committee :)

OK, thanks to everyone for attending, even though we went over the usual time

Yeah that's awesome!

Logs will be posted shortly to the GitHub issue

It was good. There was a lot of material.

Discussion can of course continue

(I just need a stopping point for the posted logs!)

Ah yes ofcourse

See a source like monerologs.net for all your logging needs =p

(I don't even recall who runs that)

sarang how do you stay logged in all the time for the IRC?

do you leave it open on your computer

who ever it is praise them \o/ great service

Yes I agree

I use IRCCloud, which is a paid service (5 USD per month)

Ah I see

It has a really nice interface on web and mobile

(I'm not paid to say that =p)

I would consider doing it if I there were no Monero backup logs lol

The logs really are great

It's nice if you have a need for ongoing connectivity and don't want to resort to external logs

yeah i'm sure it's especially nice if you get PM's

There's also bridges to this channel, but I don't know much about the details on that

for sure

Yeah I am on mattermost too

I have been checking those logs, but I will now just go to monerologs.net :)

That bridge seems to disconnect a lot

Yeah, the interface on monerologs.net is really good

Oh I didn't realize that

and it seems to update very quickly

that's cool

I should perhaps link to the log site in the topic

Yes indeed

so it's easier for people who want logs

I think I heard about it last week but forgot it until you just reminded me the url again

(y) yeah I'm sure people are interested

It even has a dark colour theme, which is my preference

ah I see what sgp_ was suggesting: pools consume coinbase and spit out miner payments + change payment back to pool; it's apparently obvious when pool consumes the change payment, since it's in a clearly fingerprinted pool tx (bunch of rings with different block coinbase references); so, the pool selects ring members from all the outputs that pool

has ever made, thereby hiding the pool's change output amongst other pool outputs

Meeting logs are now also posted to GitHub: monero-project/meta #430

(I find it convenient to have them available there)

yes looks good sarang

oh nice

It was great to have a meeting with so many interesting topics to discuss

Yes indeed, what is CSLAG btw? I know it is something you and Surae have been working on

what would be a good way to decide if segregating ring member types is good to pursue?

atoc their research papers here web.getmonero.org/resources/research-lab MRL-0011 is CLSAG

CLSAG is a modification to our MLSAG ring signature construction with much better size and time efficiency

intended to substitute MLSAG

Note that the paper is being extensively updated for clarity and a better security model

Ah I see

An average 2-in-2-out transaction would drop in size from 2.5 kB to 1.9 kB

and be around 15% or so faster to verify and generate

If hidden timelocks were included, these numbers change

koe: we'd need a more formal risk/threat model IMO

(regarding ring separation)

Oh nice. Yes I do remember hearing about the transaction size

yup koe :)

lmk if you have questions

atoc: there seems to be general support for including CLSAG in a future network upgrade, but the preprint has not undergone third-party formal review

pool are certainly troublesome

sarang: which is the MLSLAG paper?

MLSAG = RingCT basically

One version of MLSAG is described in MRL-0005

cool I see that, just making sure it's that one

ZtM explanation is more thorough (imho)

But you should read koe's excellent Zero to Monero to see how it's used more safely in multi-input txns

^ heh yup

The cross-input method described in -0005 is not a good idea

Yes koe I have not gotten to that section yet, but I thought I would look at the paper just to get an idea rn lol

CLSAG would operate as essentially a drop-in replacement to either transaction protocol approach

Ok I will just read it in ZtM then

Yeah, please use that atoc

cross-input was used in RCTTypeFull, which ZtM 1st edition includes

now deprecated

Right, but we don't use it anymore

The CLSAG PR doesn't even support it AFAIK

AH I see I see

If we end up moving to something like Omniring or multi-Triptych, cross-input is no longer an issue :D

since the proof applies to multiple signer indices!

Unfortunately we still don't have a great soundness argument for one portion of multi-Triptych (only its single-input variant)

I see. Yeah I really need to read up on these different technologies lol. Unfortunately, I am not familiar with Omniring or multi-Triptych

I suspect the multi-variant is sound in practice, but that's not a proof :)

atoc: they get annoyingly technical very quickly

and the security proofs get pretty far into the weeds

Triptych is described in a recent preprint and was developed by MRL

Oh nice

Omniring was developed by another team of researchers

There are other clever approaches as well from different teams

I see many ring signatures topics in ZtM but not Triptych

Triptych is new and is neither reviewed nor deployed

(nor should it be at this point)

Here's a good question, in a semi-nutshell how does Zcash and Dash differ from Monero?

Triptych (single-input only): eprint.iacr.org/2020/018

I am only familiar with Monero and not those other privacy coins.

Omniring: eprint.iacr.org/2019/580

RingCT 3.0 (one variant): eprint.iacr.org/2019/508

thanks for the links

Those are the ones that most interest me at the moment

So of course Zcash is really two asset types

"Zcash" (shielded) and what I jokingly consider "Tcash" (transparent, basically equivalent to bitcoin)

Nice, I'm reading these abstracts and seems intresting

Spend authorizations for Zcash (not Tcash) are a generalized proof that shows the spent inputs are from a large accumulator set

Like in Monero, this does not remove all transaction metadata, but does assert high anonymity (absent other information!)

Hmm I see

But why is Zcash a privacy coin?

Note that most popular services do _not_ support Zcash, but only Tcash

or considered a privacy coin, it must hide something right?

This requires a "de-shielding" operation that carries risk

Oh I see

I don't like the term "privacy coin" FWIW

Not sure what to call it then, since this seems a popular term. What do you prefer to cal it?

One way to view Zcash (not "Tcash") is similar to Monero but with a "full anonymity set"

I prefer to switch it up... assets like Bitcoin are transparency coins :)

lol

Nice

Panopticoins.

nice term

It would be great to use a protocol similar to Zcash, but this requires a structured and trusted setup process

If that process were sufficiently compromised, you could forge spend proofs

Such a flaw occurred in the original version of Zcash

It is not possible to definitively prove that the flaw was not exploited, but there is no obvious evidence of it (this is a subtle and tricky point)

(note: it wasn't a compromise, but a flaw in the math surrounding the process)

I suspect there would be _very_ little support for doing this in Monero

Doing that kind of generalized proof efficiently is currently not possible with known techniques, unless you have a trusted setup

What is the protocol of Zcash though? shielding

There's a lot of ongoing research to remove that limitation

The protocol is complex and very custom

This is the current specification: github.com/zcash/zips/blob/master/protocol/protocol.pdf

You'll see both the older and newer spec: Sprout (old) and Sapling (new)

There's a newer one (Blossom) that really didn't change anything of cryptographic substance

Are Zcash transaction less costly than Monero?

I imagine it could be

They are about the same size typically

but are fast to verify

Tcash transactions, of course, are more similar to Bitcoin (they include no privacy features)

this is a nice high level view of differences between bitcoin/dash/zcash/monero medium.com/@exantech/methods-of-ano…n-analysis-an-overview-d700e27ea98c

(BTW this "Tcash" terminology is non-standard; I made it up to better clarify the two pools of funds in my head)

I see, but you like parts of Zcash? (it seems, don't know for sure)

thanks koe

I like the privacy protocol in Zcash, but don't particularly like its trust implications

Yes I know Tcash doesn't exist lol

I don't like that it's optional, which carries risk

I see

Ugh, I hate the use of the term "mixing" to describe Monero

that is not what is done

Mixing is an opt-in method that actually spends mixed funds

Monero does not do this

Also, the wallet does not "create random outputs on the blockchain" to hide among

That is a poor description

why do people use mixing to describe then? was that what they did before introducing ringCT?

No

Because the non-interactive nature is hard to distinguish from mixing without some technical thought

FWIW some of the concerns in the listed papers from that article _have_ been addressed to some extent

(I can't speak to the accuracy of that article's discussion of Dash, since I know next to nothing about it)

it's mixing because you have a bunch of decoys, and your real one, and you 'mix them up', and insert to a ring signature

sigh

youll never escape it sarang!

If your output is mixed, you actually participated in the transaction; absent other information, it should not be possible to know if a Monero output participated in any transaction

it's a subtle but very important difference atoc

agree that mixing is the wrong term

I will keep this in mind sarang as I am reading

ah that makes more sense.

that complaint only makes sense if you know something about mixing services, otherwise the word is uncontroversial imo

Eh, maybe uncontroversial, but makes it sounds like "all approaches are basically the same thing"

Which is absolutely not true

I don't like simplifying things to the point where important meaning is lost

well its the nuance. especially as you delve deep

The approach with CoinJoin is not the approach of Monero is not the approach of Zcash etc.

^ basically that

sarang, thanks for your willingness to share btw. I am excited now. I am going to do more reading today and tomorrow and I would love to ask you questions and your thoughts on these topics.

fair enough ^^

Sure. I might suggest joining #monero-research-lounge for not-directly-research topics (it's an off-topic channel)

atoc: any particular interest? For development, the math, just general knowledge?

Oh cool, yeah well basically when I just run into questions. I am going to go through the ring signature stuff today MSLAG and CSLAG)

I'm happy to join the lounge

What's your background? Is it math or CS?

(might help guide the level of discussion)

Currently I am working with Surae and I need to get him some stuff, but I want a good general knowledge of Monero

CS

neat

Mastering Monero is a good starter resource; and ZtM is a good deeper technical resource

Yes I have read Mastering Monero already

I can't think of a good initial Zcash resource

Most seem either way too "glossy" to give real meaning, or too in-the-weeds (like the protocol spec)

It was good. I hope to finish ZtM within the next week

Ah I see. I don't mind reading the protocol spec, but I probably won't read the whole thing

Just enough to get an idea about how it compares to Monero

how the technology compares

That protocol spec is fantastic, but you really need to read it carefully to understand the subtle points of what's happening

Have you read it all?

Nope

Just the parts I needed more information about

Makes sense

It's quite long

At some point I would still like to see how Dash works

but perhaps that will be for later

Can't help you there

There is chat.zcashcommunity.com where there are Zcash dev channels

I'm sure the experts there could answer questions much better than I can

Sure if I want to go deep I will look at that

Zcash is a strange currency, and I am personally not too big of a fan. I know I can like Monero and Zcash both, but I prefer Monero's way of doing things

hence why I am here

Zcash is very interesting as an approach to fungibility, but it seems to get messy because of its optional features, its corporate structure, etc.

It makes tradeoffs. Monero makes tradeoffs. Bitcoin makes tradeoffs. And so on

Nobody's "solved this" yet

Yesh the corporate structure rubs me the wrong way and is it there some sort of founder's fee

or founder allocation

There's a protocol-enforced development fee. There's ongoing discussion about what to do with it in the future

Yes indeed, I agree with you. I think CSLAG will be cool if it rolls out

reducing the transaction size would be nice

Yeah, CLSAG is not a major shift in thinking when it comes to signatures, but it's an improvement

wow that protocol doc is intimidating; monero pure protocol would be half that or less, assuming dense formating like that

It's very complete

Of course, it handles both Sprout and Sapling

Yeah koe lol

and Blossom, I suppose (but that's trivial)

Gotta give them credit for fantastic naming

I personally also like Monero's tail end supply increase. I.e there is no hard cap

(let's head to -lounge to continue this discussion; it's off-topic)

sure

#monero-research-lounge

sarang, a paper just came across my desk that reminds me of our DLSAG woes with basepoints and key images. eprint.iacr.org/2019/202.pdf

Oh yeah, I remember when this came out!

I hadn't considered it in the context of e.g. DLSAG

BTW suraeNoether, have you seen babySNARK?

A fun toy construction for playing around with succinct proofs: github.com/initc3/babySNARK

nerp have not

good documentation

nice busy day here in chat, it's nice :)

does anyone think the separate public pool decoy selection algo has downsides I'm not considering?

the most obvious to me is if someone uses it even if they're not a public pool

maybe it's best described as a "public wallet mode," since it's not limited to just pools theoretically

Has that method been directly compared to the coinbase-only approach?

I don't think Isthmus made a direct comparison (checking logs)

sarang: this is independent of the coinjoin approach

sorry, coinbase approach

lol

in short, mining pools have 2 categories of outputs: coinbase and change

this better protects the latter

does nothing for the former

meanwhile, a coinbase consensus change like I described in my blog post helps the former but not the latter. but they are compatible with each other (not mutually exclusive to implement)

this = which approach

Ah, got it

Your last message clarifies

here's that master deck I made a while back now usercontent.irccloud-cdn.com/file/yogUlQ6W/Mining%20Pool%20Strategies

it's likely that with restricted ring member types, the change output from multiple coinbase-spending tx will be merged in future tx. sgp_ solution in combo with split member types would probably have the best effect to reasonably hope for

merged, and thereby revealed quite clearly ^

1311 is the most similar solution to (special decoy selection) and (coinbase-only rings)

I think that, independently and together, these two changes have more pros than cons

I hope Isthmus can shed some light on the details, alongside surae's matching endeavor

since pool mining seems here to stay, bar any new innovations, it feels reasonable to tailor the protocol to that reality

yeah, there are definitely some cons to the method I describe for input selection. it benefits the network if pools are not malicious only

but if they are malicious, really the only good recourse is to increase the ringsize for everyone

there's no incremental harm with this selection algorithm if pools are malicious, and an incremental good if they are non-malicious as far as I can tell

if they are malicious the change will be neutral to that faction, and honest pools would (plausibly) benefit

lol

I don't know if stealth pool is as big a step up as it seems, since someone can collect and parse a pool's hashing blobs for each block, then compare with published blocks

probably not in practice, I made this well before people started looking at the blobs

would have the same effect as publishing mined block lists, except the attack vector would have complete lack of visibility to common users

fwiw some pools no longer share all the payment information. supportxmr only shows the amount (useless) and number of payees

but even the number of payees is relatively useful information

that's good

the fee is often unique-ish too, and that's shown on the site. people can still likely reliably find pool transactions

thinking about it.. the transaction graph of both miners and pools is horrible; each miner is periodically sweeping his payouts in combination with the outputs from previous sweeps! or the equivalent effect from periodic consumerism. Pools have a very similar heuristic, periodically sweeping their change outputs into tx with the output of previous

sweeps (or creating heuristically significant not-direct input-output loops via consumerism).

sgp_'s modified decoy selector would have to be recommended to serial miners as well

koe: I'm interested in protecting the miners more than pools

Well, actually in this case the selection also will help everyone else since there's another set of outputs (change outputs) that are no longer heuristically dead

I feel like a majority, or vast majority, of funds directly touched by pools (coinbase inputs, and outputs), and many of the outputs of miners (those which get churned in one way or another), have very weak ring protection. Moreover, even if a miner is doing sweep all periodically, by tree-ing off the pools with known roots, they are revealing many

of their own decoy outputs as well (heuristically)

it's only when funds leave miners do they really enter the indistinguishable maze of ring sigs (setting aside other problem childs like exchanges)

a miner's best bet might be a) sgp_ decoy selection, b) periodically segregating funds (stop mining with one address, start mining with new address, and don't let funds from addresses cross over)

fwiw I'm not suggesting that either of these solutions alone does much for specific users. It only matters on an aggregate network scale

Suppose public mining pools create 20% of outputs including coinbase. That's 20% viewable to everyone, and therefore 20% of decoys selected on average are useless

With segregated Coinbase rings, maybe that means only 5% of decoys in other rings (from the change) are useless

Standalone, the actual impact on specific users is hard to quantify even at 20%. Probably zero for most

But if there was a 50% chain split, then it exacerbates the issue to 70%, and then it starts having a greater impact on the network

That's how I view it. Best to increase network resiliency by reducing the baseline condition, so that extreme conditions are less significant

agh I cant wait for surae's matching simulator

^ suraeNoether

:D

koe the simulator is passing tests currently

you can play with it and generate your own blockchains

and study the ground truth of the otherwise obscured monero ledger

yay!

until i break it again

:\

actually better not get involved or ztm2 will die a lonely death

lol

Yup, that research is crucial here

But even really basic stuff by comparison like the Excel sheet I made and MRL-1 show that impacts are exacerbated when the network is already stressed

suraeNoether for multisig I'm wondering a) what are the keys stored in tx_extra for? and b) how does the implementation avoid duplicate signing (e.g. when two people share a key.. they can't both use it to sign)

that has me thinking. Is there technically a maximum to how many signers can be in a ring?

no

Relevant issue to my topic monero-project/monero #5222

well by technically, how much the code can handle, idk

koe can you elaborate on the duplicate signing question?

What do you mean "how many signers" can be in a ring?

the signing key is a merged key, of all the diffie hellman shared keys, each of which (for M > N) is shared between 2+ members. To sign, they each sign with their component keys, then merge the signature with simple sum. But, since each person has keys that other people also have, the signature components would get duplicated

The answer is exactly 1

Insight: no cap technically. moneroblocks.info/search/5e75b4596c…a508afb985748b3066bbfe2923cedb0b81a

How that was derived is not the verifier's business

I was reading "mastering monero" and they were discussing minimum amount of signers for a ring. going from 3 to now 7

koe our construction was originally based on the musig signature scheme, which used multisets of keys, not sets of keys; duplicates allowed.

and wondered the opposite (the max)

current is 11, and it's fixed at 11

Insight: technically it's now fixed at 11

but there's not a cap in the ring signature algorithm or anything like that

oh got it.

any reason why 11 was picked compared to like 13 or 15?

koe so when those shares are passed around and summed, the signers are doing it with an encrypt-then-auth scheme. so they can see the public keys used by the other multiparty computers and detect duplicates. if this is unpalatable for whatever reason, the signer can abort

Insight: because it goes to 11

ah ok; in my original multisig chapter I reduced communication steps by having only the first member of a sorted list sign with a given key; sounds like current scheme is to just pass it around

Insight: we are currently investigating what ring sizes are optimal or preferred, but 11 was selected in part to make sure txn verification could be kept under intolerable thresholds

Insight: the other part of selecting 11 was the spinal tap reference

whats the spinal tap reference? (is there documentation about it)

does that mean they only construct the response after receiving the partial signature from previous guy?

most blokes play on 10.

ohhhh haha got it

<lza_menace> lol

<lza_menace> > is there documentation about it

koe, we have a commit-and-reveal stage.

if i recall correctly (and it's been *months*)

should go watch the movie so i can understand monero on a philosophical level

everyone in their coalition has each other's pubkeys by sidechannel. everyone commits to some random signing data and sends it with enc-then-auth to their coalition members. if everything auths, then they send their openers to their coalition members, again with enc-then-auth. if everything auths, they check that everyone's commitments opened correctly. then a partial signature is computed and sent

back to the coalition with enc-then-auth. if everything auths, everyone sends back the information required to finish the signature, again by enc-then-auth. if everything auths, any one of them can sum up the info to compute the final signature.

but it's very very possible i'm not recalling things in the correct order, or that i inserted steps, or something

i would need to reference the preprint

that i wrote :\

it should be 3 stage signing, for any value of M or N, if communication steps are consolidated using lexicographic sorting of member pub keys

though it requires knowing in advance which M members will sign

that sounds correct, because shorter rounds of communication were shown to be very unlikely to be provably secure under the DL assumption

by preprint do you mean mrl 0009?

this has given me things to think about, thanks; also, do you know what the pub keys stored in tx_extra are for?

(ive heard rumors multisig pub keys are stored there)

i forget numbering. :P i mean "thring signatures"

uhm i believe that moneromooo could answer that

ok ill probably read that tomorrow

It was my understanding that commit-and-reveal is not done

and it's single round-robin

Please correct me if that's not the case

that was the original musig approach that was proven insecure

Right, I'm referring to Monero

yeah, our proof of security relies on the commit-and-reveal

so i hope you are wrong

*i'm also not worried if you aren't*

but yeah

^ moneromooo

I don't think commitment was ever added to the communication complexity

despite being in the security proofs

*due to the communication

(I disagree, but it's not my call)

iirc there were long discussions around musig in the community, the general sentiment was that reduced rounds are extremely unlikely to be exploitable, fwiw....

is at least robust key aggregation?

Right, but key cancellation is different

(depending on the communication mechanism)

I thought robust key aggregation was part of musig

Yes, but we don't use MuSig

MuSig requires 3 rounds

im saying, do we at least use the robust key aggregation part, of musig

yes

afaik

ok good lol

unless the code uses a different key agg mechanism than specified in the security proofs >:(

I know the original version of multisig used naive key aggregation

The pubkeys have the same use as for non multisig txes.

are there extra pub keys? e.g. usually there is only 1

" Monero’s first iteration of multisignature, made available in April 2018, used this naive key aggregation, and required users sign their spend key components." is from my old chapter draft

I'm not 100% sure about the following: there are extra pubkeys where at least one or two outputs are to a subaddress. I always forget the exact rule.

it should be extra when at least 1 output is a subaddress

There's a special case to do with change IIRC, which doesn't trigger an extra pubkey.

unless it's a 1-out tx (pre-2out requirement)

oh makes sense

A signer does not sign with keys that already signed. The set of keys used is kept as metadata. I suppose if a signer signs with a key but does not mark it as used, it'll cause an invalid signature.

sarang how would that interact with janus?

hm multisig with advanced escrow could provide coinjoin-like service within monero! privacy your privacy bb

rbrunner is a good person to ask about current multisig implementations

They've been very active in development IIRC

nvm no need to test janus on a tx where all outputs are to yourself

The key aggregation we use predates musig I believe. So it can't be that unless amazing fortuitousness.

^ suraeNoether

Like I said, I don't recall any changes being made as a result of the paper

[keybase] <surae>: our key agg is a simple sum, then?

well generate_multisig_N_N git blame hasn't changed in 2 years, which is my reference for naive key aggregation

Yes, adding.