thanks

slow-hash.c under src/crypto/ has all the hash algorithms from what I can tell

pow algos*

where is this?

which repo?

rx* is randomx, slow-hash.c is Cryptonight.

It's a layer above librandomx, in tevador's repo. See submodules list for the url.

cool - thanks

ah I see

the repo is monero core

cool, I originally thought you were talking about monero core

but wanted to confirm lol

what's your background btw? Math as well?

mechanical engineering

oh nice (y)

good morning ^.

^.^

good morning koe!

Hello

Research meeting is today at 18:00 UTC (a little over 3 hours from now)

have updated my personal roadmap list, if anyone would like to review before the meeting. Some of my ideas have only been mentioned in passing pdf-archive.com/2020/01/29/moneroro…oe012920/moneroroadmapkoe012920.pdf

sarang what about stirring or blending instead of mixing? e.g. "This allows block miners to spend their miner transaction outputs just like a normal transaction's output, stirring them into MLSAG rings with other normal and miner tx outputs."

You mean when discussing the inclusion of decoys in MLSAG/CLSAG rings?

interpenetrate there's another synonym

yeah

I use 'include' in 29 pages already x.x

Good listing of items in your roadmap for ongoing discussion

thanks :)

What do you think of including 32-64 bytes of sender-only data inside Bulletproofs?

I had hoped it could be used for sender-recipient data, but that isn't safe with multiple-output proofs

It's possible to use the rewinding process to brute-force the commitment amounts in the proof, so has to be limited to an entity that's allowed to know those

Im wondering about pruning, as knaccc mentioned

If we used per-output proofs it would be straightforward to set up sender-recipient data hiding, but then you lose all the logarithmic aggregation scaling

I was thinking something like the tx private key, which isn't included anywhere right now

Of course, that key could be generated via an indexed chain instead

At any rate, the data hiding couldn't be consensus-enforced anyway

yeah tx private key would be useful

If you don't know the PRNG seed, the BP data appears random (and has to)

Im guessing nodes would have to store the extra scalar(s) separately, to harmonize with pruning, which hyc may have a perspective on

which actually implies not much space savings

But the sender could also generate tx privkeys deterministically if it's guaranteed they aren't reused

meaning storing them in the BP using a seeded PRNG doesn't do much

You can guarantee that mostly by deriving it from your spend key + key image being spent.

right

it's possible, but necessary :)

Hmm. Actually. I guess if a tx fails somehow and you resend, you might reuse it...

right and I like that idea, as wallets can recover all the private keys by generating a list and scanning the chain for owned output's key images. With janus mitigation the base key is used for all subaddresses, and easy to test.

although with subaddy not much utility unless you know the recipient's address

or really any tx for that matter

moneromooo you could make it an indexed hash of vin (index corresponds with output index, if necessary); how likely is it to reuse vin for a failed tx?

So perhaps the ability to have prunable sender-only data stored in a BP is not as useful as I had initially hoped

At least it's certainly available if a use case were to arise

As part of this analysis, I'm investigating how data inclusion could work in RCT3, which shares an underlying proving system technique with Bulletproofs

Getting sender-only data included inside its proof could work similarly

Sender-recipient data would end up leaking the signing index, though

Reminder: research meeting is at 18:00 UTC (an hour from now)

Very high since they're recorded to be reused.

Good morning everyone. Friendly reminder that our research meeting begins in about 15 minutes (click the link in room topic to see the agenda).

Hi!

Agenda is here: monero-project/meta #432

Logs posted there after the meeting as well

Let's go ahead and get started with GREETINGs

Hello

Hi

v Greetings

Heyo

greetings

hello

Hi

Let's continue with ROUNDTABLE, where anyone is welcome to share research topics of general interest (and discuss any questions arising from them)

Since there was so much to discuss last week, I'll try to keep the discussion focused to the extent possible, for clarity

I have a few brief things to mention

hello

First, I wanted to better understand the effects of including hidden timelocks in CLSAG signatures, and worked up a version of 3-CLSAG in C++ for performance tests

Including timelocks would negate the verification time advantages of an MLSAG-CLSAG transition

but would still give size benefits over MLSAG

A similar approach would work in Triptych, so I extended the Triptych test code to 3-Triptych for this purpose

And, just for completeness, updated the Triptych preprint on IACR to a general d-LRS construction

Here is the 3-CLSAG test code, for those interested: SarangNoether/monero db33d18

And the 3-Triptych concept code: SarangNoether/skunkworks f7581a3

And the updated Triptych preprint: eprint.iacr.org/2020/018

I also found a very minor change to make in the existing CLSAG test code

Finally, suraeNoether and I have been doing more security model stuff

Any questions on these items from anyone?

not directly for sarang, but at Isthmus regarding timelock; what is the prevalence of non-zero timelock for non-coinbase tx?

Absurdly prevelant

whether or not to include encrypted time lock depends in part on how much use it actually gets

used

Yeah, and I'm not formally advocating for it at this point; only curious about the implications

I think our options are to remove the silly timelock field (It's just an arbitrary integer memo field currently) or encrypt it.

I like that it's a straightforward application of concepts already used in Monero

Yeah, conceptually it's really neat

Will we be the first privacy coin to roll it out?

I expect that it will become industry standard

Does Zcash offer such functionality?

(I have not checked)

no clue

I don't think so, but not 100% confident

ZCash has serious scaling issues

Anyway, whether or not Zcash does it should not be the determining factor IMO :)

Merely curious

Oh wait. Zcash inherited nLockTime from Bitcoin

👀

I'mma fish out their information leaks too

And OP_CLTV

If implemented, it would make the most sense to bundle the timelock range proofs with the existing Bulletproofs

So this means the sum of timelock-enabled inputs (all inputs, if mandatory) and outputs is restricted

for Triptych, what are the steps between now and considering it for replacing RingCT?

Formal review, a determination about its effects on multisig (particularly on compute-limited hardware), a decision on Triptych vs something like RCT3

I have not yet examined how easy it would be to include timelocks in RCT3 with their security model

^ ... and estimated recommended tx size for Triptych

Also note that, as I think I mentioned last week, it would not make sense to deploy hidden timelocks with MLSAG due to the poor scaling

agreed

(though technically possible)

Anyway, I want to make sure others have time to speak as well

Who else wishes to share research topics?

Zebra network stack looks interesting, potential applications in Monero?

I saw that yesterday!

Blag post about it: zfnd.org/blog/a-new-network-stack-for-zcash

cool, will check out

And a corresponding forum post (not much activity there yet): forum.zcashcommunity.com/t/a-new-network-stack-for-zcash/35870

It's from Zcash Foundation research

Monero maintains a single state across all the peers, right?

That's a good question, and I don't know the answer

ping vtnerd

I had thought so, but not confident in that

not even sure what that means. single state? what is included in that state?

there is an aggregate state for bandwidth limiting

but sync info is per-connection

Oh so maybe we already take the Zebra approach?

It seems pretty elegant.

Isthmus: did you have other topics you wanted to bring up as well?

"Unlike zcashd, which maintains a fixed number of outbound connections, we attempt to connect to as many peers as possible, subject to resource limits "

this approach will be troublesome for them, since they use levelDB/rocksDB for storage

lvelDB/rocksDB requires thousands of file descriptors for its storage.

that competes with the demand for socket descriptors

Interesting... worth bringing up as a question on the forum?

One of the developers (Henry) opened the thread

not from me. I have no interest in helping zcash project

ok

I'm trying to make the unlock time plot, but my laptop is struggling with the 1.5 GB data set

they should have already known by now that their DB choice is inappropriate for a network service that uses lots of connections, but it seems they haven't discovered that yet

Isthmus: no rush!

In the meantime, koe: did you wish to address anything in particular?

yes muahaha

not technically research, my roadmap has been cleaned up a bit; in particular I want to get opinions on item koe_11, which would enable view-only wallets to know when owned outputs have been spent; also item koe_9 which would allow all wallet implementations to more or less deprecate pre-RingCT transaction versions

koe_11 sounds like a high priority

also, sarang helped me work up a decentralized CoinJoin-esque protocol (temporarily named JoinMo), which is available as chapter 9 of current ZtM2 draft

chapter 10*

I like the JoinMo approach of using per-participant shared secrets to obscure the input-output mapping

also, rbrunner at one time investigated OpenBazaar integration, and ran into some roadblocks, so my 'research' has been engineering solutions to those problems, which should be available next week

I'm giving extra scrutiny to the specifics around SAG/LSAG since the keys are per-output only

I was thinking about the implications of using a separate keyset for inputs as well

(keys = per-join participant keys, I mean)

however, OpenBazaar integration would likely entail a large update to the code-base, to optimize communication rounds

moreover, multisig in general should be updated to comply with suraeNoether's paper on the subject

Yes

Somewhat related to item 10, I'm still concerned about any blockchain observer being able to identify which transactions do not include any outputs to subaddresses.

n3ptune and I will make a plot of subaddress adoption over time : -)

But ideally that should not be possible.3

Also yes :)

It's been suggested before to standardize on some form of per-output keys for this purpose

but it never gained traction

koe: nice list! koe_9 may be controversial since spending pre-rct would stand out more, no?

Yeah looks like a nice list koe

it already stands out like a sore thumb

but that sort of problem will exist for RingCT as well, since spending ancient outputs is always somewhat unusual

and my suggestion is to start using pre-ringct outputs as decoys as well

If we told everyone to sweep them to themselves, would that also be too obvious? you could assume that every txn with pre-RCT inputs is going back to its sender

so gamma select over entire site of outputs

set

koe: do we currently only select rct randomly as decoys?

yes, and coinbase (not sure if pre-ringct coinbase are included)

coinbase are included as decoy in normal tx, which is where this idea comes from

then this actually makes spending pre-rct slightly less suspicious, no?

And the handling of coinbase outputs is by no means solved

This is 80% a joke: We implement Koe_9 and sgp_coinbase_only rings, *but* require each and every one to include N coinbases and M pre-ringCT transactions, for fixed consensus parameters N and M

sgp_: the distribution tail falls fast

sarang: indeed, but it's near-zero better, not near-zero worse I think

Yes, but does provide slightly more information (amount)

^ which is hilarious, because all of these would hypothetically unlock at HEIGHT 2 and HEIGHT 12 back in 2014, IIRC what mooo said

Due to the non-standard handling of that field, you mean?

Isthmus: hmm, I would need to see a lot more info on how many people actually spend pre-rct (suspected) compared to coinbase. My intuition leans no

(which should be standardized anyway)

So include a single pre ring CT fake if the real output is not pre ring ct

@sarang: Yes, currently, 3 things are being put in the unlock field:

Argh sorry

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

yup

I am working on a first version implementation of xmr-btc atomic swap in Rust

more info here: github.com/h4sh3d/xmr-btc-atomic-sw…/blob/master/whitepaper/xmr-btc.pdf

atoc: did you identify a suitable zkp?

Aside from things like the handling of non-compliant participants etc., the zkp of hash/log preimage was not specified

the paper proposes two transactions for each token

yep

is there is a zkp not specified I will look at it. So far I have just gotten some initial stuff implemented

however I have not gotten to the swap part yet

for the implementation, I have read through the paper and it seems sounds

sound*

Yeah, you'll notice there's a requirement for a particular proof that a hash preimage and discrete log preimage are equal in equal knowledge

Something trustless like Bulletproofs could be used for this, with a suitable circuit

I see

The BP paper had data on such a circuit, but I was specifically told it was for testing only and was not yet suitable for any kind of deployment

I will take a look at that

We will need it. Perhaps we can see if that circuit works okay, and if not hopefully we can look at ways to improve.

koe: thanks for that roadmap writeup; it's nice to see many suggestions put together in one place

It might be useful to open research-lab issues for those that require ongoing discussion

I still advocate for those two mining pool-related proposals btw :)

sarang I send you a link to my repo once I push some changes

even though most discussion happens on IRC

I will send*

Thanks atoc

You can take a look and I would like to get your feedback on it

Happy to help

Thanks for taking a look at that

(y)

sure I can put on research github; was just wondering if koe_11 should go on main repo's issues

Np, it seems interesting. This week I was just l familiarizing myself with different atomic swap techniques i.e off-chain and on-chain

And looking at the dalek library in Rust

koe: I'd say anything that requires ongoing unsolved research is definitely suitable for research-lab

But I don't dictate the scope of issues!

OK, we have about 10 minutes left (there's another meeting taking place at 19:00 UTC for the Konferenco)

ok can put them up there

Any research topics that have not yet been brought up, and should be?

sarang btw have you considered publishing your list?

Of topics I am personally working on? Not really, it's more to help organize my own work

The private list that you had of research topics that need attention.

I should open issues for them as well

TBH github issues for research are not used as well as they could be

Yeah I think it would be could to have a public list to look through as important topics for Monero that need attention

Since so much of the discussion happens on IRC in real time

yes indeed

But at least those issues could be used as a central posting location

I currently go back to the logs, but that list was helpful.

I don't want people to have to scour IRC logs

Sure, I'll make some issues

We should clear out old issues as well, or request updates

peanut gallery here. Now that suraeNoether 's matching project is complete (?) or nearly so, what is the plan to use it going forward ?

'scouring IRC logs' - story of my life :')

nioc: good question for suraeNoether!

He has also been working on LRS security models lately

(which are a blocker for CLSAG review)

OK, let's move to ACTION ITEMS for the time being (discussion can of course continue after we formally adjourn)

I am writing up some material on transaction proofs/assertions, and writing up new code for a proposed InProofV2 and OutProofV2

As well as security model updates, some work on proof rewinding for data storage, and some odds and ends

Anyone else?

my action item: mkW my private .git repo (of atomic swap implemntation) public on Githuv

neat

Github*

my action items: multisig and escrowed-marketplace protocol writeup, possibly start bulletproof study if time permits

BPs for the ZtM writeup?

I want to make a website where you can type in a stealth address (or list of them) and see what future transactions have used them as ring members

But need a little bit more backend work before that is ready

at the very least studying it

I think the concerning part will be seeing the outputs that have been used in no subsequent rings, and thus have a known spend state and no plausible deniable for spendedness

Let me know if you have any particular questions that I may be able to answer

of course :)

Any other action items, or final comments before we adjourn?

(from anyone)

actually spoiled my writeup from several months ago in the latest ztm2 draft whoops

It's great to see so much research lately into so many different areas of interest from so many people :D

Gets tough to keep up with everything

Which is a great problem to have, in some sense

Anyway, thanks to everyone for attending; we are now adjourned!

Logs will appear shortly on the github agenda issue

Success problems :)

@sarang yea, can't beat the Monero community :- )

Feel free to continue discussion

Grassroots cypherpunk xD

mebbe more bitcoin researchers will find their way here, since their ideas will actually have a chance of being implemented :P

you mean like confidential transactions

wasn't that originally a bitcoin-focused researcher's paper?

Maxwell

Yep

<hyc> mebbe more bitcoin researchers will find their way here, since their ideas will actually have a chance of being implemented :P >>>> only if those rolling hardforks keep going!

Eventually less often, from what I understand...

To reduce the workload on the ecosystem

once next gen of transaction protocol is live there will likely be diminishing returns on hardforks

koe I was actually reading Maxwell's paper the other day: people.xiph.org/~greg/confidential_values.txt

yeah his paper helped me a lot for chapter on commitments

yes, Maxwell's CT is the most prominent example

but I recall stealth addresses were originally proposed for bitcoin as well

Has bitcoin tried implementing his CT?

the Bitcoin team*

no, Greg's own company forked it

Elements

forked bitcoin?

ah, blockstream

Greg is no longer with Blockstream, FWIW

yes, forked bitcoin

I see, what's his fork called? Elements?

yes

Interesting, I can't seem to find a coin associated with it

sarang where is Greg now?

BTC-specific discussion is probably for #monero-research-lounge

the btc community would never have accepted it with the drastic increase in txn size, old style range proofs

ok, will continue in -lounge

:D

So for Triptych, I think you could store 64 bytes of data per spent input

prunable or non-prunable?

the cost is that anyone with access to the PRNG seed can determine the signing index (but nothing else)

Depends if you want to prune ring signatures :D

The storage is with the ring signature

We'd need new technology to extract a 64 byte chunk of data from it and keep it. Sounds daunting.

To extract data from the ring signature?

Not really; it's pretty straightforward

You can do it easily as you verify the signature

The cost is something like 2 hash-to-scalars and a couple of scalar-only ops

and then bam, you have your data

as per my ping above: with the exception of lmdb, monerod doesn't really have some complex "consistent" state across connections

and already has async requests, although some of the requests are synchronous

and remote node must respond in same order as received

there is potential improvements for cleaning up some blocking code on I/O threads to improve throughput, but I dunno enough about BTC network code to know how it compares to monerod

reads as more marketing madness or an engineer exagerating the problems with the existing code

They were already doing a Rust implementation of the Zcash protocol

(zebra)

monerod can process messages from multiple connections, but there may be some blocking in certain areas

as an example, theres some locks on DB read calls that should be removable if LMDB did its thing. but everything was written with berkleydb initially, so you'd have to re-design some things

there isn't enough information in that post for me to know whether they've properly identified problem/solutions to what bitcoin is doing

but they are certainly going to take another whack at it

hey Isthmus would you happen to have on hand an example tx that was apparently sent to a subaddress? trying to verify number of pub keys..

We're still building the parser for that

And by "we" I mean n3ptune who does all the hard work

ah ok :p

stagenet incoming!

oh my, it created 5 total tx pub keys, and I only have 4 outputs!

sarang janus won't even change current number of pub keys rip!

ah Isthmus, it might be nice to know if any implementations are NOT creating the extra tx pub key (e.g. num_outs == num_pubkeys)

lolwut

community.xmr.to/explorer/stagenet/…4fde8c5ad289d8f25cca808532185039b/1 check transaction details, tx_extra has normal tx pub key (tag = 0x01), and 4 additional pub keys (tag = 0x04 followed by amount of keys = 4)

function is construct_tx_with_tx_key()

only the additional pub keys are actually used by outputs

which makes sense, it's more like a small bug; janus base key should go in additional pub keys as well, to save the 1 byte single-pub-key tag

If extra pubkeys are in, the tx pub key is redundant.

It could be omitted, I dare not touch what's not broke though.

well it's 32 bytes per tx with a subaddress in it (assuming >2 non-change outputs)

>1*

sarang I am looking back at the ZKP in section 4.1 of the paper

remind me again why you feel this does not work

probably ok to leave it alone until sarang is ready for discussion on janus, then fix it in code passthrough if janus gets implemented

Oh I see the hashlock requirement now.

btw suraeNoether I have consumed with this xmr-btc atomic swap implementation project.

however I am still willing to run some tests and contribute to the bipartite matching project

if you still need it

atoc: you mean the zkp for preimage equality

?

They assume you have access to one

koe: I am in favor of the Janus mitigation

especially given that CLSAG implies size savings already

were you doing a writeup about it?

Yes

Along with super-simple code to demo it, for clarity

I would not say there was broad consensus for making it mandatory when it was initially brought up

But if it would only displace existing unnecessary transaction elements, why not

yes sarang

Yeah, they don't actually present an implementation of that zkp

They presuppose it exists

Yeah I noticed that; however, at least Monero will not require timelocks.

iirc not much discussion was had when initially brought up, but the chat scrollback has become quite much since I showed up so who knows

You mean hash timelocks? No, it will not provide those

koe: I think it should be brought up again

in a dev meeting

Well there is a hashlock and a timelock

yes

The protocol won't require timelock

however with hashlocks revealing some data like pre-image

theat may be required

that*

Monero does not support native preimage locks that aren't part of signatures

I see, so does the protocol need to be modified?

Or can we use pre-image locks that are part of signatures (if they exist)?

IIRC that proposal didn't require any kind of non-supported lock

I will need to review tomorrow if you want an answer

Yes you maybe correct.

The DL preimage effectively takes care of that

hence the need for the preimage zkp

I am just trying to confirm as it seemed it may need hashlock, but there is a section that says it does not need timelock or hashlock

In 3.1

Can you link plz?

I hate scrollback

Yes sorry one sec

ty

I have the paper downloaded

but I will get the link

got it, no worries

aren't dev meetings getting deprecated? iirc the last one had low turnout

sorry for delay, but yes in section 3.1 - primitives for Monero

koe: ?

Their frequency tends to increase near releases

Unless something has changed that I am not aware of

What primitive are you questioning atoc?

can make some repo issues for discussion once your writeup is ready

It still mentions that "we need to provide proofs of the correct initialization of the protocol"

Where?

section 3.1

IIRC all the proofs required were off-chain

Ah, those are off-chain

between the two participants of the swap

It assumes a secure channel between them

which is reasonable

I see - also you brought up concerns about the zkp during the research meeting

so I thought I would clarify with you on that

Well, the paper _assumes_ a preimage zkp

it does not define one

You have to supply your own :)

Ah okay

I have seen reference to exactly one such zkp

but it was not deployment-ready, as I was tol

*told

Was it in BP paper?

I remember you mentioned that

yes

Do you have the preprint handy?

Okay cool it's all confirmed then - I will need to go back and read it

Not atm, but it is on my todo list

as per our meeting

BP preprint: eprint.iacr.org/2017/1066.pdf

see e.g. Table 3

page 33

Great

long paper lol

Yes, but very well-written

Nice - thanks for the link. I will read this a little later

righto

btw if anyone intended to use ztm2 draft this week, I updated the one from earlier today with a few things I originally wanted done for the meeting (probably hard to notice, but anyway). Here is this week's official draft pdf-archive.com/2020/01/30/zerotomo…0-22/zerotomoneromaster-v1-0-22.pdf

ah forgot line numbers sry sarang, maybe next week :p

Hehe, no worries =p

Aha, JoinMo is included!

I see you changed the name from MoJoin...

hehe

8)

I don't actually care about the naming, in case that wasn't clear

i cried myself to sleep sarang, tears of pain

lol

it may be an enduring trauma

I think the many-to-many communication is awful, but we do what we can

Maybe go with "Joinero"

I think it can be hosted by a service, post things to the message board and then each person accesses it; actual p2p would be a nightmare I think

big problem is participant discovery.. if not hosted then idk how it can work

KoeJoin

(tm)

im sold

Better claim that domain name, and fast

.in is a TLD...

koejo.in

aw snap, sara.ng is taken :(

damnn

FWIW: mone.ro used to be web.archive.org/web/20170428215936/http://mone.ro

I have many questions

(this is -lounge territory, I know...)