You will DO what Monero tells you to do. You will JUMP when you are told to jump. And most importantly you will DISCONNECT whoever Scientology^H^H^H^H^H I mean Mnero tells you to disconnect. Otherwise you WILL end up like lh1008 here:

monerologs.net/monero-community/20210114#c181614 And you will do it all for FREE. Because Monero is open souce :D Just like Linux is there to pay for $700k watches that Torvalds wears.

Hello all, I noticed that when trying to configure monero in one of my servers, I was getting a message about a public IP aqddress being blocked by my firewall

I wonder if that is something I must enable for monero mining?

This message came up during the syncing process

blockchain syncing process

Check your firewall documentation. Opening 18080 is a good idea if you can, but not strictly necessary.

Hi all! I'm trying to build a local network music discovery 'app' where musicians upload songs to a server on their local network, and then other people access that server and can listen to a radio of the songs (random order). In order to like a song and then play it back at any time you need to 'tip' the artist using monero. I took a look at getmonero.org/get-started/accepting

and monero-python.readthedocs.io/en/latest/transactions.html but can't quite figure out how to verify that a tip was sent to the artist's Monero wallet.

Is there some type of proof the tipper can provide which will demonstrate they paid some amount to the artist's address? And if so, how can I generate such a proof for any old person (i.e they don't have their own node with RPC enabled)

I've talked with moneromooo in #monero about some possible solutions but haven't arrived at one that would work the way I'd like. Ideally as a user sending a tip I would just scan a QR code with cake wallet (or even have it opened up via a link) choose my amount and then click send. Trying to find a way to make that experience possible

Depends on which wallet, IIRC this is doable on the CLI one.

I think most people would be using their phone so probably cake wallet, the possiblity of using the shorter encrypted payment ids monerodocs.org/public-address/integrated-address was thrown around

(perfect solution I think)

I don't think I understand how the integrated addresses work, are the public spend/view keys listed in the table at monerodocs.org the recievers or the senders?

ah it's the destination looking at getmonero.org/resources/developer-g…et-rpc.html#make_integrated_address

Integrated addresses are just your (receiver's) address, with a 64 bit number appended.

awesome thank you, I think I have enough to give making it a go. Flow will be: users clicks 'tip' -> UI comes up and makes a request to /get-payment-address on the server -> server makes JSON rpc call to the node's make_integrated_address endpoint -> create payment QR code/link using the integrated address -> server scans for incoming txs -> invokes split_integrated_address via rpc call

-> uses the userid/songid which made the 8 bytes of the integrated address

Yes, except "server makes JSON rpc call to the node's make_integrated_address endpoint" -> the wallet's endpoint. The node does not have your address.

awesome thank you, I think I have enough to give making it a go. Flow will be: users clicks 'tip' -> UI comes up and makes a request to /get-payment-address on the server -> server makes JSON rpc call to the node's make_integrated_address endpoint -> create payment QR code/link using the integrated address -> server scans for incoming txs -> invokes split_integrated_address via rpc call

-> uses the userid/songid which made the 8 bytes of the integrated address -> records song as owned -> ui updates

For such low amounts, you'll probably want to check the txpool to check for txes, not wait till mined.

You could use tx-notify

(triggers a program to run on your shell when a tx is received to the wallet)

ah yes sorry I meant check the txpool

oh wow tx-notify that will be very useful

thank you everyone! I'll let you all know how it goes (and if I get stuck again) :)

Good luck :)

<hennyh "Hi all! I'm trying to build a lo"> sick! good luck on it! 💯

Look on the bright side. At least you don't need to obsess over signs of life from FUK now.

<hennyh "thank you everyone! I'll let you"> It's such a coincidence that your writing this.

* It's such a coincidence that you're writing this.

Written two days ago

It's a poor mans version of what you want.

No user accounts, just an mp3 radio stream using mpd / icecast

Users can't select which music to play, and a cron pauses the music after a certain period of time. Another tx has to be sent to start it again

<anon_82641[m] "Users can't select which music t"> lol

so, I've got the portable storage serialization & deserialization working great, being now able to essentially do any req & response to the p2p network (handshake working well, able to get the whole local_peerlist_new, etc)

but I couldn't find in the source code anything for command 1005 (network_state) and 1004 (stat_info) - is that because Monero indeed doesn't implement it, or, am I missing something?

(perhaps `docs/LEVIN_PROTOCOL.md` is an antique doc from pre-monero times?)

When SpotXMR?

read the code and ignore that doc

wfaressuissia[m]: yep, just double checking if I'm not missing anything (new to the codebase)

It's current. Those are in src/*/*defs.h

Oh, they are debug calls, might have been removed actually...

They were defined out for ages anyway.

<moneromooo "They were defined out for ages a"> coooll, thx for confirming! 👍️

They were removed last year, I just checked.

aren't integrated addresses on the way out?

Unclear.

Would be nice to (1) kick them out and (2) add an always on fixed size per output encrypted field. Could be used for that and other things.

Starting from 6th May, I'd like to try to abstract the wallet2 class a bit, using an interface. Does anybody have something against it? vtnerd ?

Of course.

its already abstracted once

in wallet/api

<mj-xmr_ "Starting from 6th May, I'd like "> What were you looking to abstract?

vtnerd, What is the reason why wallet2 class inherits no interface? Is there a relationship between wallet2 and api/wallet?

virgildante[m], I'd like wallet2 to inherit from something, so that the clients don't have to include wallet2.h directly.

wallet2 doesnt need to inherit from something for other code to use its contents

as we discusssed

its functions have been factored out while largely keeping existing interfaces

those factorizations can simply be PR'd to monero

inheriting wallet2 from something would be fine iff what it inherits from is an object so designed as to be truly more general

but what is wallet2 a specific case of?

it wouldnt help much at the moment to go in that direction immediately IMO since no one has need of a more general case - what they need are the contents

nor would it help to chuck another interface on top of wallet2 as vtnerd noted

From the design point of view, at the first iteration it would be enough if wallet2 just inherited from an interface which contained all of the wallet2's methods. It doesn't mean that that iwallet2 would be the generic case. This means that iwallet2 could in future inherit from a truly general wallet interface, as you design it.

mymonero-core-cpp shows, as we discussed, those factorizations.. so that work is already done and needs to be PR'd to monero

that doesnt sound useful mj

wallet2 already has an interface. it actually has two now

its header's entire point is to be an interface

and all instantiators of it consume that interface

Depends on the point of view. Generally no user should have to include the header, where there are any private members. wallet2 is not an interface. It's an implementation already.

And this is especially true for a large class like this.

sigh

endogenic: no you don't get it, we need to change it for the sake of changing it ;D

sounds like youre not asking for anyone's differing opinion

lol :))

i have been promised funding to do this work

$120k

That attitude is the reason why it takes bloody 50 minutes to compile the project (and not only this one)

but we'd need someone who has enough experience with growing and maintaining codebases and building objects

no mj

it's not the cause

it is exactly the cause. Here's the proof

search for"

wallet2.h

endogenic> sounds like youre not asking for anyone's differing opinion <-- the only differing opinion I could extract from this is "DONT DO IT"

correct

dont do what you suggested

But OK. As you can see from the above report, there are many other files like this, which make the project compile for so long because of the same attitude, so I'm fine avoiding it, until somebody asks me to do it or I run out of ideas.

if i'm not mistaken mj-xmr_, you used my name and referenced my talk in 2019 in order to raise money for this task

meanwhile you told me you never looked at the work i did on it

you never saw mymonero-core-cpp

that effort isnt just my own

it include's ndorf and even some of vtnerd's work

For this task alone I arranged about 4 XMR. I'm fine to redistribute it. Gee. It's yours.

there's a reason we didnt just make a iwallet

well if you insist it would be the second donation i've ever received

Honestly with such raising prices in USD terms, I will defo ask the team to redistribute a big chunk of that funding.

but you should keep the money and review existing work and try to absorb the wisdom behind it as you have skill in c++ and can benefit monero

<endogenic> meanwhile you told me you never looked at the work i did on it <-- and this is kind of crappy public shaming. Not a gentlemen's way of dealing with differences in opinions.

fwiw I agree, there's still far too much actual implementations in header files

which is definitely a burden on compile times

you're projecting, mj-xmr_

and you're upset that i didnt let you walk all over me

Not at all :)

I'm a lone wolf.

oh yeah you actually like that then

mudslinging

I'll just leave it there.

And do some real work.

So wallet2.h would inherit from the new interface?

yes dont waste your time

virgildante[m], yes.

wallet2 already has an interface that changes on a regular basis

Triptych prioritization meeting in ~20 minutes

Hello

Hi

cc rehrar, binaryFate

Hi there

Hu

hi

hi

Who wishes to lead this meeting?

hello

binaryFate: Would you mind leading?

Unfortunately I cannot. Sorry.

So we leave it to somebody.

I'll probably have to leave early. Sarang do you want to have a go?

OK

I am interested to know what Triptych research priorities should be, to determine if I should work on it as part of a CCS submitted by rehrar

Note that I would be working as a researcher employed by rehrar's company

I had previously understood that multisig was not considered a very high priority, but now it sounds like it should be, for example

I vote (1) correctness, (2) security, (3) multisig, (4) speedups.

So it seems best to identify priorities more directly; hence this meeting

Hi

proposal: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/222

For people reading, sarang submitted a CCS proposal -> reddit.com/r/Monero/comments/mn3irk…esearch_and_optimizations_a_new_ccs

No, rehrar did

Just to be very clear

To be even more clear, Cypher Stack did.

There was much discussion about the nature of that arrangement, but I'd specifically like to determine the priorities to know if I am the best person to do that work

But I, the individual, submitted it in behalf of the company because companies don't have typing hands.

mj-xmr_ : if the goal is compile-time reduction, then no doubt much could be moved using the pimpl method

would it be appropriate to add ring selection to mooo's list? AIUI increasing the rind # would require a new selection algo

but I'm not sure why at a glance an vtable interface is needed

Here are some things that I had considered useful research?

s/?/:

- Output selection and binning algorithms

- Batching optimizations

- Verifier optimizations relating to scalar computations

- Updates to security model

As far as multisig goes, I had initial work on this but it's more complex than the current multisig solutions and would require much more coding using something like OpenSSL for RSA groups

Hey. I'm one of the xmr.to team. Multisig is definitely be an important enabler for at least one of our upcoming projects. And quite a major bummer if we lost it :-). So I would like to add my vote for multisig.

I do _not_ know how much complexity this would add to things like mobile wallets or hardware wallets

To be absolutely clear, this requires curve arithmetic that is not 25519-based

and is multi-round

I'd say it's an acceptable drawback if you have to use monero-wallet-cli to use multisig.

I will add a vote for multisig support with the recent announcement and impetus behind Haveno. That's a high priority for me, personally, now.

I am not very familiar with OpenSSL or its alternatives when it comes to functionality required for this RSA group support, so the implementation side is something I'm much less confident in

sounds fine if it's only in wallet-cli for now. someone else can adapt it for mobile wallets at a future time

I'm thinkinf of people with large amounts of monero and mandated DD. Those would have to use multisig, most likely. Kind of a must have for those.

I am more confident in the underlying construction and algorithms

sarang: appart from significant additional coding, would the security model be fundamentally different for multisig than for singlesig?

I can help with openssl if needed. I'm not familiar with it, but I can become :)

A vague hope, but would it help anything if only 2/3 was supported? Because that's basically where almost all the shows take place.

binaryFate: the existing security model holds, since it doesn't care how you compute keys or linking tags as long as they're correct

I see backwards compatibility with existing multisig as a requirement

ArticMine: key image format changes

why would only wallet-cli have access to the implementation?

for us "backwards compatibility with existing multisig as a requirement" would be a nice to have, but not a have to have

Assumes facts not in evidence. AFAIK the issue is processing power (for hw wallets) and more code to use the wallet2 impl.

or was that just 'it might be too much to add to a hwdevice scheme for now'

I'll throw my support for openssl rsa groups too, man

ty

I've worked pretty extensively with OpenSSL, am available to help on that front

So what happen to existing multisig outputs? there needs to be a pathway

endogenic: hardware wallets would need to be able to do arbitrary RSA group computations, and I don't know enough about their capabilities

yeah

Old outputs would continue to use the old key image format, and need to be "transitioned" to new outputs... this would likely just be a height cutoff

Are there any HW wallets that support *current* multisig? Don't think so.

This means a partitioning of the output set, which has important implications

They should be able to be spent normally. When spent, they'll generate triptych outputs. Whether those are multisig or not is unknown to the sender. The recipient can then send them normally.

However, I do not know of a way to avoid such a partitioning

this doesn't sound any different from transition to ringct, or transition to BP

As for optimizations, there's a neat optimization that was used in Beam and Firo's implementation of Lelantus (disclaimer: I do research on Lelantus as part of my role at Cypher Stack)

Similar to the ringct change, BP did not need such a change.

Correct

^ moneromooo correct, not hyc

The transition like the ringCT model should not be an issue as far as I can see

reference to Lelantus doesn't give warm fuzzies, given Firo's recent problems

It means an initially limited anonymity set, which will cause initial chain reaction deanonymization

hyc: Triptych and Lelantus share the same "proving system ancestor"

as does Arcturus

and this optimization applies to part of the protocol that happens to be common among them

I have yet to determine the precise timing differences

sarang: To be clear, in that case multisig should be able to 'hold' funds past the fork date right?

A output conversion subsequently takes place when the 'old' outputs are consumed in a transaction

That generates new Triptych outputs

Output conversion means that a transaction can include either _only_ pre-Triptych anonymity set elements or _only_ post-Triptych anonymity set elements

and the linking tag pool used for checking double-spends is specific to that cutoff

The output format itself isn't actually changed, but that's not really important here

Doesn't sound like a reason to fully kill multisig to me

More like "issues"

IMO if there is a known Triptych optimization it is worth exploring, even if the exact speedups are not known yet

Or "things to consider"

<selsta "IMO if there is a known Triptych"> agreed

Yeah, there's a separate optimization that affects proof format (using `n`-ary Gray codes)

The other optimization is not consensus, but it could be important for setting network parameters for the proofs

we want to consider and explore all known optimizations before deploying triptych

to avoid multiple forks

yeah that makes sense

Anyway, it does sound like multisig _at fork time_ should be considered a blocker now?

sarang: Is this conversion only needed for multisig, or for all outputs?

All outputs

Very similar to the RingCT transition

I don't see the issue then, at least for that aspect

Multisig outputs look identical (by design)

Well, the conversion is important because it _will_ initially lead to chain reaction analysis

The issue is lots of new code using RSA groups has to be done.

This should dissipate quickly

moneromooo: yes

sounds like a flag day. tell everyone to churn after the hardfork.

sarang: What time frame would you estimate to get multisig properly working?

Any rough estimate possible already about how many person month we talk here?

For the implementation

That's the thing... I don't have a solid understanding of what full multisig implementation will take, since it's multi-round and uses a lot of new group arithmetic that we currently don't use anywhere

I can maybe add some wallet code to prefer spending pre-triptych outs. This means that there'll be fewer trpitych txes right after the fork, allowing for more new triptych outs to be created before the first ones get spent.

We also have to support old non-ringct -> triptych transactions no?

No, IIRC those go pre-rct -> rct.

This would make a chain pre-CT -> CT -> Triptych easy to detect, FWIW

ah, so someone with pre-rct would have to do: pre-rct -> rct -> triptych?

Similar to how 'unmixable' outputs are first transformed non-ringCT outputs I guess

Of course, spend patterns for CT -> Triptych may be easy to detect as well based on known distributions

They don't have to. The outputs are created in the type that matches consensus rules. They're always all spendable.

Anyway, I think a lot of this transition needs careful consideration since it's a big change

Yes I agree

The work I did previously was on the proving system and a _bit_ of the multisig stuff

But there's a lot to consider about the migration, and any side cases that might arise

But still enough for moneromooo to implement a POC, right?

as well as the practical implementation of multisig due to its RSA group requirements and round structure

rbrunner: my initial multisig work is almost certainly not enough for a proof of concept yet

But I can write it up in much more detail

No, I meant Triptych in general

The initial stuff was just to determine if such a thing was possible

Oh, I have working Triptych prover and verifier code already, with limited batch support

That was done earlier to get timing data

Well, the patch to add triptych to monero is done.

Yes, that's what I meant :)

I did that a couple months ago.

Big caveat that while the preprint has undergone review for publication, the code has undergone no such formal review

And, as always, the quality of peer review can vary greatly compared to a paid review

^ for the preprint, I mean

I know people are excited for the big ring sizes, but this shouldn't be rushed in any way. I would be shocked if we wanted to get this in before year's end.

sarang, you mentioned " - Updates to security model" as possible themes. What's that, in general?

We can release with BP+ in the meantime.

<sarang> Big caveat that while the preprint has undergone review for publication, the code has undergone no such formal review <= We would have to get multiple audits for Triptych anyway

rbrunner: the current security model focuses primarily on the proving system itself as a zkp system

rehrar: I'd still be in favor to postpone BP+ until Triptych is ready, even if that means we have to postpone it to, say, early 2022

But less so on the resulting transaction model that you get by using our commitment-offset-based approach to amount balancing

FWIW the CLSAG security model is similar, as was MLSAG

Arcturus is a little different since it handles balance inside the zkp, whereas Triptych (and its predecessors) do not

would triptych multisig require specific paper peer review?

It would be nice if it did

Working up a separate security model for that would be a _lot_ more work (think about the previous multisig preprint!)

The most one could hope for without that would be a thorough description and proof of concept, but this is a very different review process

Also, multisig security models were really suraeNoether's expertise

The idea behind multisig is that to compute the linking tag between players requires a type of known MPC

and then this is worked into the rest of the proof construction, which is much more straightforward

The RSA group stuff only comes into play for this linking tag MPC

and there only because you need to jointly compute an inversion of the output secret key

(multiplied by a fixed curve group element, that is)

Hello everyone! Sorry I am late to the party... Is there a live transcript/log somewhere so that I can see was has been said till now?

arnuschky: I'll send the logs in PM

awesome, thanks

And solutions like allowing a mix of transaction formats for the foreseeable future fully out of question?

No.

How do you mean?

We freely allow people to produce the current tx format even after hardfork. People sneak in their multisig transactions that way.

That would imply multisig holders performing current transactions, whereas the rest of the network performs Triptych transactions

Not necessarily. I mean crazy things would be possible, like random decision what to produce for *every* tx :)

Consensus rules cannot distinguished between outputs that were spent from a multisig wallet from outputs that were not.

sarang: Given the potential volume of the multisig work, would it be prudent to start with that aspect of Triptych?

dEBRUYNE: certainly could do this

if there is general agreement that lack of multisig is not acceptable, doesn't that define an apparently large enough (listening to sarang) research direction already?

binaryFate: Right

moneromooo: I meant in case of a fork without multisig support for Triptych

If multisig is a blocker for deployment, that could be the initial scope; if it turns out not to work in practice for whatever reason, that minimizes any wasted effort

Then multisig holders can only transact in the old format basically

just curious: does arcturus lend itself to a better / easier multisig? or is it the same?

To be clear about any kind of mixing of transactions... outputs need to be separated by what transaction type can consume them

If we fork without MS, and if Alice has a MS wallet, and Bob sends Alice an output after the fork, then Alice cannot spend. That is bad.

Arcturus multisig requires this as well, as would Omniring, RingCT 3.0

You could not prevent that sending, right, because multisig is not visible in the address

So how would a transition from Triptych to Arcturus look like for example?

ArticMine: output pool stays the same

yeah it sounds like multisig is the primary at this point

Proof format changes

No transition needed for outputs between Triptych and Arcturus

In that case, should the initial scope of work be multisig only?

Yes

Maybe, given how far along the "other" stuff is already ...

If we cannot deploy without multisig, it is basically imperative to find out as soon as possible whether proper multisig can be implemented / achieved

Output binning/selection is important as well, but seems less important based on this discussion

binning sounds like a matter of refinement, MS sounds like a harder works/won't work

I mean we don't even have any graceful way out of multisig on the table if we really should drop support, right?

hyc: binning would likely need to be consensus to avoid miner shenanigans

If multisig is in such high demand, but seems conceptually not really an issue but much more a coding problem - would it be sensible to turn this into a separate CCS and fund that alongside the more theoretical Triptych work?

I agree with dEBRUYNE. Nice to see all the support for multisig and haveno :)

Other than "People, please empty all those multisig wallets"

true arnuschky . sarang, at this point, is multisig more a theoretical problem or an implementation problem?

or is it in that wonderful gray area .....

Mostly implementation, but I think the transition should be reviewed in more specificity to ensure that existing multisig wallets are not affected

Loss of funds seems like the obvious blocker

We'll all agree on that

As would having to move to a separate multisig arrangement?

i.e. if multisig players need to collaborate to migrate to a new address

well, theoretically, they can migrate whenever

I suppose that is not necessarily a blocker as long as there is no time limit on it

I think migration is fine as long as it's not time-constrained

Certainly unfortunate

Bit inconvenient, but still

ie if I want to recover my wallet two years from now, it should still be possible

Should it be considered a blocker if multisig players need to change addresses?

2/3 looses sense, opens blackmail possibilities that were not there otherwise

rather than resulting in loss of funds due to a missed window

Or just a super duper annoyance

Same answer I'd say

Just inconvenient

for us that would be acceptable

sarang: would be defintely be problematic. I'm not sure of how that would effect active trades on Haveno.

sarang: I think it should be fine as long as a proper migration guide is provided

Better than no multisig in any case :)

That lays out all necessary steps

Anyway, this is good to know. So the general consensus seems to be that limited scope initially to multisig is the best use of effort?

I'd say so

inconvenience can always be softed by good software support / processes

but if the price to pay for multisig support, i guess could be workable :)

I'd be hesitant to expand scope if one outcome could be "sorry, multisig doesn't work, so it's all canceled!"

yeah

"limited scope initially to multisig is the best use of effort" +1

So what say we leave the existing proposal as is, and just not merge. It'll just chill in Ideas. Make a new proposal for multisig work with the scope and price. Get discussion on that. Merge that one first once approved.

Why not close it?

Then the Triptych optimizations can be merged after multisig is sorted out.

Any further work would need a more defined scope than existed in that CCS

Why not change the existing one?

Up to rehrar I suppose

dEBRUYNE: all of the comments will be for the old version, wouldn't be obvious

We are not short in possible proposals, aren't we. Cleaner certainly to make a new one, IMHO

and there's a lot of comments. I think it's important for the transparency. A new lurker will see all of the comments and think they are in support of the multisig stuff. Which those people may very well be in support. But I think it's best to be clear?

I guess, but most of the discussion relates to the way sarang is contracted

Not to the specifics of the proposal itself

I will do what the community thinks is the best course of action for the proposal itself.

I'd change the scope, cite this meeting as source

And then simply merge it

Also think no reason to open a new proposal.

Would be a bit of shame to lose another week here just for redundant administrative purposes

One issue is that I don't have a good sense of the time commitment required for this

Multisig, that is

As noted earlier

sarang: I'd just work out the current hours and see how far you get?

Sounds reasonable.

We could hold another meeting afterwards I suppose

Not much choice, given all the unknowns and uncertainties

I agree. And since the time is on the smallish side (one month's worth of work hours) then we can reassess at the end of that. We're underestimating rather than over, so no risk to the community on unused funds.

+1 I'm quite comfortable with letting Sarang work on it and revisiting status and progress once we know more.

agreed

Yeah I want to avoid the case where it takes much less time than expected, and funds were raised in excess

Buy a lambo then :)

oof

Depending on the status of multisig, I presume those hours can simply be used to work on other aspects

If it takes less time, and multi-sig is found to be likely to have solutions with Triptych, I would also be quite comfortable with sarang spending excess time on any of the other proposed tasks :P

I'm sure core would be fine with any excess funds (if it were to ever happen) to be rolled into any next research project we do.

The worst-case scenario would be discovering that it won't work early on

making the other work moot

sarang: I think the community is perfectly fine with letting you churn away on Triptych

<sarang> The worst-case scenario would be discovering that it won't work early on <= Which is basically why multisig has to be prioritized

dEBRUYNE: well, what he's saying is it seems multisig is a showstopper. So if we realize it's not workable, then Triptych is a no-go altogether.

Sorry, was afk for a bit, just reading this: "Should it be considered a blocker if multisig players need to change addresses?"

Meaning excess hours can't be poured into Triptych.

I think it would be a massive problem, because you can't stop people from sending to the old address, where the outputs would apparently be burnt ?

In what kind of scenario does a multisig wallet receive a lot of transactions though?

Without flagging the output type, yes

Hot wallets (from services) are typically not multisig as far as I know

Again, need to carefully consider the transition and existing addresses

<rehrar> Meaning excess hours can't be poured into Triptych. <= Right, but then we could discuss with the community what to do with the remaining funds

I believe we'd be ok provided keys are additive

why not put in the proposal: Excess hour can be used on Tryptich, provided that a proof of concept of multisig is established" (or something like that)

+1

What should happen in the case that multisig is shown not to be viable?

I also need to adjust for new prices.

A good problem to have :)

sarang: dEBRUYNE suggested we discuss with the community how to spend.

Given my position with core, I would say rolling into the GF isn't an option so there can be no COI. Whether it's put into other existing CCS proposals or something else can be for discussion.

In advance, I hope

But in a sense, that's not your problem as a researcher. It's your problem to consider as a member of the Monero community though.

I mean, I would still (as a researcher) consider the other Triptych research areas to be of independent interest

But if it couldn't possibly lead to deployment, that's problematic as you say

Are any of the alternatives to Triptych more likely candidates to be able to support multi-sig?

If not viable, then I guess we'd need to tag outputs, rather than use the fork height to determine their type.

I thought it was pretty much worked out in theory though ?

Most other options I've looked at (Omniring, RCT3, Arcturus) have the same key image format, and therefore the same challenges

Lelantus does not, but it has other problems relating to recipient addresses that I think are non-starters here

moneromooo: I want to write out a much more comprehensive analysis that accounts for these cases

To ensure that these are all considered properly and in a unified way

So basically we forge ahead, with multi-sig and the other research areas, and assume that human ingenuity will eventually prevail over the "impossible"?

Other non-multisig work would be placed aside

Since those aren't blockers

Any idea yet whether wallet construction and transacting, as seen *by the user*, will be different (if it works)?

Not different.

Different order of commands, more key exchange rounds, stuff like that?

(For Multisig specifically)

Oh, for multisig itself ? If so, I dunno ^_^

This'll be a new multi-round MPC

I need to review my notes to see how many rounds :/

And there's been additional literature on similar constructions that I will need to review carefully

Alright. As I said, if 2/3 works out reasonable, we are (almost) set.

This particular construction (the author names escape me) has been studied pretty extensively because of its use in other signature MPCs

Yeah, I need to look over the threshold stuff again too

Most work initially starts with `n`-of-`n` and then builds threshold using additional round(s)

Unfortunately I don't know a way to reduce the rounds too far without sacrificing security expectations

Everything else pales in comparison with 2/3, I would say.

as far as practical importance goes

Sure, but if you have threshold, it's pretty much guaranteed you have arbitrary `n`-of-`n` in the math already

and `n-1`-of-`n` too

All the better then. I just remember we did not bother to implement that for quite some time.

I got to go sorry. Feels like it was very useful, thanks sarang and all. rehrar: I suggest we double-check with luigi1111 the phrasing for potential excess funds before you post updated proposal

The implementation differences exist, of course, no doubt

Thanks to everyone for the information on priorities; this was very helpful

I assume the meeting is now adjourned?

nobody feels like an issue was left out?

Not me. In any case relieved that multisig support is accepted as important.

i mean, i think there are more, but the go/nogo of multisig seems like the primary

Yeah, I'm glad to know of its priority. From much earlier discussion I was under the impression it was not

Pailler ?

Or Paillier.

That's what is used for the MPC, yes

well, i think that was before multisig was being used maybe. I mean, i still feel like its niche and beyond the scope of money, but the can of worms has been opened

In any case right now would probably the last decent point where to announce that we kill it for good.

It's not consensus though, and not detectable anyway

Anyone could be doing multisig in any number of ways

If you end up with a valid transaction, it's a valid transaction

Well, I am quite sure from the lack of feedback for and questions about "my" MMS that it probably *is* niche :)

At least until now.

Wouldn't be surprised if some exchanges use it for cold wallets though

The story will change of course as soon as software like Haveno will start to use it under the hood, automatically

Would anyone mind posting the logs on the Github meta ticket by the way?

i think and hope that Haveno will make people use multisig more tbh

rbrunner: idk if you saw but I updated my GUI PR for basic multisig too

Yes, will certainly have a look when I have time.

ty

dEBRUYNE: Posted the meeting logs. Without further comment, should be clear what it is :)

ty

Howard Chu is a high IQ scholar, he has more Google images with a violin than Sting with a guitar, he singlehandely saved NASA from doom. Why can't the saviour of NASA save Monero?

Theoretical question.... would two VPS nodes sharing the same storage, but different IP addresses, work in practice?

We’re trying to figure out the most economical way to run a basic node and an RPC node

It'll work in theory. But in theory, practice matches theory, where in practice, they don't.

whereas

xmrhaelan[m], why do you need two separate nodes?

the same node can serve both types - an unrestricted RPC port and a restricted RPC port

endogenic's Lemma: "with the exception of this theory itself"

.merges

mj-xmr_: i apologize for how i responded earlier. i became emotional partially bc i was tired 😅