There will be a meeting in this room in about 1.5 hours

To all meeting participants: please disclose any potential conflicts of interest.

🤨

meeting time monero-project/meta #627

1. greetings

hello

Hello.

Hi there

disclosure-bot-x: Please define conflict of interest in this context

Hi hi hi

Hi

It's a bot

Rucknium. Did you ever post Document A anywhere so I could read it?

I can send you the working draft

Do you want it now?

hello :)

Let's do updates briefly, then get into the agenda

2. updates - what has everyone been working on lately?

Rucknium[m]: Sure

Finishing up requested changes to the view tag PR (ty to UkoeHB for the review), then will be getting back to decoy selection work

My OSPEAD CCS proposal was funded (Thank you everyone!). I ran some analysis on the blockchain data for PR#8047. Working on Document A and incorporating feedback.

me: I made two MRL issues to discuss the design of a potential seraphis implementation. 1) PoC performance results ( monero-project/research-lab #91 ), 2) Seraphis address schemes ( monero-project/research-lab #92 ). Last week I found and fixed a rare crypto bug ( monero-project/monero #8052 ). My next steps are integrating performance results into the

Seraphis paper, then integrating coinstudent2048['s security modeling work into the Seraphis paper.

one-horse-wagon: Sent. If anyone else wants the draft of Document A, let me know. I'm just not posting it publicly since it's not good to have old versions floating around publicly.

I'm happy to wait unless you need feedback before pub. No shortage of other things here for me to catch up on!

carrington: I mean, it could be nice to have feedback. Mainly, it needs to be more accessible to laypeople. It sort of needs an introduction.

You are not obligated to give feedback just because you receive it.

Well in that case sling it over and hopefully I'll be able to give some meaningful feedback in a few days

wfaressuissia: are you available to give an update on your multisig PR? It is a blocker for people planning to use multisig, so knowing what timeline to expect can be very helpful.

Wait, is there a second multisig PR on the way, beside yours, UkoeHB?

carrington: Sent

rbrunner: yes, multisig is unusable until then. Maybe luigi1111 will make a statement ?

You mean in the sense of "too risky", right?

" It is a blocker for people planning to use multisig ..." soon

I was asking myself whether it makes sense to test again your updated multisig code. So much changed that I would say my previous results are kind of invalid now.

But maybe wait, and test with the second one on top?

Yeah, might as well wait.

wfaressuissia: ok well, sounds like it's closer than last time I asked lol

let's move on to agenda items; looks like a new one was added Rucknium[m]

Yes. I think it would be great to put together a list of open research questions. Grin has this: grin.mw/open-research-problems

" It is a blocker for people planning to use multisig, ..." what's the right place to discuss deeply how it will be used in practice ?

This would help us in a number of ways. First, it would help us determine priorities and maybe uncover low hanging fruit. The view tag idea comes to mind here.

It would help attract researchers, in general, since they would then know what the questions they could work on.

It seems like a good format for collecting what is presently scattered across github issues, papers, reddit posts and various websites.

Hi! Regarding open problems listing, I have some, but more "theoretical". What's the status of moneroresearch.wtf?

And if we have a more formal funding structure for MRL, they could serve as the basis for Requests For Propsals

wfaressuissia: I don't think there is a place right now (other than this channel). You could open an MRL github issue for longer-term discussions github.com/monero-project/research-lab/issues

What's the performance difference (theoretical maximum, practical maximum, actual diff for wallet2 scanning) of view tag in practice ?

That code is so "beautiful", there is non-zero chance that it's far from theoretical maximum of ~50% (?)

coinstudent2048[: Theoretical question are great to add. Status of moneroresearch.wtf is carrington was reaching out to spirobel to work on it I think.

"I don't think there is a place right now (other than this channel). " It makes sense to make usable for any market, not only haveno or something similar

I think the theoretical maximum is closer to 25%, since scalar mult key is so expensive compared to the operations you get to skip.

"I think the theoretical maximum is closer to 25%" is it for asm from external/supercop or without ?

iirc it is the same with or without

I've had a pretty whacky IRL week so haven't made much progress on those ideas sadly. In the meantime I'm rereading ZtM2 and making notes

Ok, I don't think I did a direct comparison with 'unoptimized'. It is 25% using supercop.

Anyway, so it looks like coinstudent2048 has a small list of questions to contribute. I will make a MRL GitHub issue about it. I suppose I can host the working list on cryptpad.sethforprivacy.com

Or maybe coinstudent2048 can make the MRL issue and start the CryptPad doc

> It makes sense to make usable for any market, not only haveno or something similar

Multisig has always been generic, although there is an address-generation optimization that really benefits uses of 2-of-3.

I'm about end user API, current multisig related functions are crap and 1 instance of monero-wallet-rpc per 1 multisig wallet is a crap idea too

I was thinking that if we consider ZtM2 to be the protocol specification, it might make sense to organise research/problems on the basis of the chapters of ZtM2

it's too heavy, there is a need for something more efficient

I think the issue is multisig tx builder code is heavily integrated with wallet2.

Along with all the labor of tracking outputs and recording state.

The distance between ZtM2 and actual code isn't small and getting increased with time

carrington[m]: I wouldn't call ZtM2 a spec... but the organization might be useful. I'd also look at the Seraphis paper introduction for a sense of protocol structure.

Yes I should have said "nearest thing we have to a protocol spec". Points taken. Are any parts of ZtM2 badly outdated already? Or only after the next fork?

Oh, another thing that the list of open questions could be useful for is to tag articles on moneroresearch.wtf according to which questions they may address

"I think the issue is multisig tx builder code is heavily integrated with wallet2." Everything is wallet2 is deeply integrated (due to short term ugly changes without any refactoring or redesign)

* Everything in wallet2 ...

outdated: CLSAG is being used, fee/dynamic-block changes for next fork (monero-project/monero #7819), BP+ for next fork, multisig chapter needs an update, a few minor details I can't remember

Well, that's just progress. Of course ZtM2 is only a snapshot at a certain point in time. I fail to see anyhting special here.

Ah yes CLSAG. Thanks for the summary

Agenda item 7 is: The Science of Blockchain Conference 2022 Jan 24-26. Submission deadline: November 23, 2021 11:59pm PST

If we want to submit something to this, which I think we should, we need to do it very soon

Fingerprinting a Flood would be the obvious choice, as a work in progress

> Everything is wallet2 is deeply integrated (due to short term ugly changes without any refactoring or redesign)

With my Seraphis PoC I am trying to encapsulate as much tx protocol logic as possible, so wallet-level code just has to plug into component library APIs. Hopefully that gets us one step in the right direction.

Similarly, the multisig address PR pulled a lot of logic into the `multisig` component library.

What happened to wallet1? Was it lost in a boating accident?

Rucknium[m]: I suppose the authors of that paper would have to submit it.

I'm an author, so in theory I can submit. isthmus would be the best person to spearhead it, though.

Does anyone have any last-minute questions or things they want to discuss?

Should we discuss the Seraphis performance tests? I suppose my main comment is if there isn't a huge tradeoff, keeping the flavors that allow collaborative funding would be great.

which flavors? concise vs. whatever the other was?

<wfaressuissia[m]> ""I think the issue is multisig..." <- I was thinking of refactoring a bit of wallet2 during view tag stuff. It seems like we're continuously just going to add booleans for new features based on fork version (e.g. `use_rct`, `bulletproof`, `use_view_tags`), and pass the booleans from function to function

UkoeHB: couldn't it be 50% if you tag the first pubkey instead of the correct one?

The cost of collaborative funding is `32 + 96*(num_inputs - 1) bytes`.

(or more)

luigi1111: yeah it's 25% if you have 1:1 matching with outputs and txo pubkeys, there can be more if all outputs share a txo pubkey.

hmm I don't get it

not sharing pubkeys should make it faster in my version

UkoeHB: UkoeHB: Roughly, what's that in percentage terms? I know we haven't yet settled on a tx size yet.

(same speed, faster as a % increase)

The 25% comes from skipping `Ko - H(derivation,t)*G`. The remaining 75% is from computing `derivation = kv * R`. If a tx has one txo pubkey, then you only need to compute one `derivation` for the entire tx. The `Ko - H(derivation,t)*G` steps can be replaced with view-tag checks for all outputs. If you have one txo pubkey per output, then you have to compute `derivation_t` for each output - quite expensive.

Rucknium[m]: ~ 1-10% scaling with the number of inputs.

So a single input would be close to 1% larger tx size?

Yes

~ 5% for a 2-in/2-out tx

Worth it, in my eyes. It is important that we have a breakdown of the tx characteristics of txs in the last year or so, in order to get a better sense of how your performance tests would play out in "production".

I can work on this with neptune

what are we adding for 5%?

gingeropolous: the ability for multiple people to fund the same tx (provide inputs)

Noncustodial crowdfunding where donors can recover their XMR if the funding goal is not met.

ukoe I get that, 25% seems the minimum increase

<UkoeHB> gingeropolous: the ability for multiple people to fund the same tx (provide inputs) <= can't they do this now?

not without interacting, collaborative funding allows 'independent' funding

tx prefix hash is needed to derive signature challenge, that means set of signers should be known in advance

right ^

key images for all inputs should be known in advance

"... You could open an MRL github issue for longer-term discussions github.com/monero-project/research-lab/issues" I need at least 1 human who can dive deeply into problem. I don't see any value in comments from people with shallow knowledge of the problem.

Anyway, we are past the hour so I will call the meeting here. Thanks for attending everyone.

UkoeHB: do you have few clones ? I need 1 for p2p discussion and 1 for cryptography ?

You can msg my matrix account. This IRCCloud account is my original one that I haven't quit using.

wfaressuissia[m]: Is this what is true now, or would this be true with Seraphis collaborative funding?

but matrix has encrypted chat which is nice

> I need at least 1 human who can dive deeply into problem.

I am open to suggestions, or just message me I guess lol.

Rucknium[m]: key images must be known in advance for the current protocol, because they are included (hashed) in input signatures (CLSAG).

UkoeHB: And that would not be the case with some of the Seraphis options, correct?

right

Can the collaborative funding model be explained a bit further - how would the protocol flow?

According to one interpretation, collaborative funding saved BCH from a devtax. It's that important to the ecosystem now.

jberman: Have you read the flipstarter explanation on read.cash?

See

It doesn't go into too technical detail, though

1. define tx outputs (and any memos); send a 'tx proposal' to potential funders with the set of destinations (amounts and recipient addresses)

2. each funder independently decides how much to contribute to the proposal; they make partial inputs and send them to the proposer

3. when the proposer collects enough inputs to cover the output amount sum, they define the tx fee (this probably requires a custom-made output from the proposer, which also covers any remainder between inputs - outputs), complete the balance proof (and optionally, membership proofs); they submit the full tx

Got it

i guess the critical part is the funders get the money back if the goal is not reached

yes, if a funded proposal never gets completed, then nothing happens to your funds

it seems the proposer can finish funding themselves though, yeah?

right

Yes, but that's true for a CCS, too

right but with CCS funds aren't disbursed until goals are met

this seems to disburse funds immediately

And they are still obligated by social convention to do the project.

it just seems niche for 5%

I think it could work but for proposers with less history / trust I guess the CCS is still there

Yes, it does, and a huge amount of BCH development runs on it

It sounds like it may be extensible to a coinjoin-like protocol

can colaboratively funded transactions be distinguished from normal transactions on the blockchain?

Monero has funding problems. I have people coming to me with good ideas, but they are wondering if the funding is really there.

CCS has no undo button

jberman[m]: 🤯

Lyza: there are two variations. In one variation, all funders reveal the output they are spending to the proposer (they delegate making the membership proof to the proposer). This variation is indistinguishable on-chain. In the other variation, funders make their own membership proofs, but since they aren't all made concurrently, this is distinguishable on-chain.

Hmm. Why didn't I think of how it could be used for BCH CoinJoins

the first seems preferable to me. if the funder is worried about revealing the output, they can send the donation to a fresh wallet they control first, no?

<Rucknium[m]> I don't see this being good for people new to the community. like I said, with CCS funds are held in custody until the work is complete. I can't see a lot of people wanting to fund an unknown person with funds they could run off with. for well known contributors, sure, but in that case are the funds ever in doubt? I guess I don't know how much the general fund is pitching in but I've never seen a CCS go unfunded even the

imo kinda silly ones

not to say a decentralized way to fundraise isn't good; it would be

People who are new to Monero may have a previous body of work in another area.

That they can show. These things are repeated games.

for sure

>I don't know how much the general fund is pitching in

Not much, recently. binaryFate said he would indicate whenever the GF contributes

cool good info I forgot

It seems like it definitely can be extensible to a coinjoin-like protocol. Seems like you could have a server functioning as "the proposer"

1. The server collects fixed amount denominations and recipient addresses from a group of users who want to collaborate

2. Each funder re-connects to the server (to sever the link between recipient address and their inputs), and independently sends partial inputs to the server

3. When the server collects enough inputs to cover the output amount sum... they submit the full tx

Could be missing something

How does that compare with CashFusion?

jberman: If you feel that you have a solid idea, for sure post it on bitcoincashresearch.org

There isn't any DDoS protection in what I described. would need to think on it more

But in any case, I'm talking about it in the context of Monero here. A coinjoin-like protocol would offer an additional way to sever linkages across outputs, but seems like either it would be distinguishable on chain from others, or would reveal some spent ouputs to a server. neither are great. and plus it's interactive and won't really be ideal for the average user

How is it interactive?

jberman[m]: have you seen TxTangle, ch11 of ztm2?

oh sweet, no haven't made it that far yet

<Rucknium[m]> Monero has funding problems. I have people coming to me with good ideas, but they are wondering if the funding is really there. >>> well there's only 1 way to find out. i don't see how decentralizing a funding mechanism that costs 5% is necessary. but im just a fuddy duddy when it comes to these things i guess. i never expect the cash in my wallet to start having contracts

decentralizing things just for the sake of decentralizing them is ....... something something

The centralized CCS has lots of problems. I am writing a review essay comparing my experiences with Flipstarter vs CCS. Monerujo wallet tried to go through CCS but was blocked due to its permissioned nature and now uses plowsof 's Wishlist as a Service.

It's not just decentralizing for the sake of decentralizing. Also, people have mentioned that Monero users are already using Monero to circumvent Kickstarter, et al. preventing them from receiving funding.

This would allow them to expand their use of Monero for that purpose.

while we're at it can we discussing establishing a legal structure to protect the liability of independent scholarly funded work on the monero project? I'm working with my counsel on this but they're a bit slammed with the holiday season, though I expect movement on it fairly soon

I'll look forward to reading your post Rucknium!

+

>liability of independent scholarly funded work on the monero project

How could there be liability?

s/discussing/discuss/

Rucknium[m]: there are lots of reasons people might suspect it would cause them direct personal liability

endogenic: I don't understand what you would be liable for?

yeah other mechanisms besides ccs should exist, and now they do

it's often cited as one reason people want to stay behind a corporate shield or why they just want to go totally anonymous

Ok, what are those reasons, then?

<Rucknium[m]> "How is it interactive?" <- what I described requires interaction between participants and a server/other users to successfully construct a tx. Whereas I can construct a publicly verifiable ring signature today without interaction with others

Right. With CashFusion users just set the option to fuse in the background and the wallet (with the server) takes care of everything and does as many fusions as it can over hours or days.

That's interaction at the wallet-to-server level, but not at the user-to-wallet level.

endogenic: I am aware of the ETH dev case (Virgil Griffith), but he literally went to North Korea.

Ethereum is not monero and Virgil is not necessarily going to be an activist for certain topics nor is he going to be advising the same people etc etc

sorry, the question deserves a reply but I'm not prepared to have the convo at the moment

"<Rucknium[m]> I can work on this with neptune" Sounds fun!

neptune: We can go further. We can work on it with mj-xmr since mj has the forecasting model apparatus. Forecast the dynamics and demand for each tx variation.

<endogenic> "sorry, the question deserves a..." <- Ok. Let me know when you have more info.

I will, thank you!

Rucknium[m]: interesting idea

What we're doing here is talking about scaling in the future. It would be good to have some forecasting to pair with UkoeHB 's performance tests.

neptune: So far the Time Series Analysis looks like this:

Plus a lot more, that's still hidden, until I decouple it from the rest of the irrelevant parts.

Does someone want to make an issue on the MRL GitHub?

sounds like we have a volunteer :)

I voluntell mj-xmr to open a MRL GitHub issue. 😉

(trying to find excuses...)

<Rucknium[m]> "endogenic: I am aware of the ETH..." <- That was an extremely unusual case. Griffith comes back from North Korea and proceeds to tell the FBI everything he did. He left nothing out, did so willingly and signed off on it too. So what do you want the FBI to do with information? They proceeded to arrest him and the DA prosecuted him. Personally, I think the guy was not doing well, mentally.

<Rucknium[m]> The centralized CCS has lots of problems. I am writing a review essay comparing my experiences with Flipstarter vs CCS. Monerujo wallet tried to go through CCS but was blocked due to its permissioned nature and now uses plowsof 's Wishlist as a Service.

just to be clear this is untrue, or missing significant context at the very least

also interactive coinjoin us certainly possible now

is*