sech1: is this something you could answer? monero-project/monero #8233

"sender , receiver address and amount" - Sir, this is Monero

and I answered it on IRC already a couple days ago

do you know which channel this was? then I can copy it into the issue

it was #monero-community paste.debian.net/hidden/36eb0d46

thanks

has anyone written any code that can interface with monero locally via a python API?

looks like i pretty quickly found the answer to my own question: github.com/monero-ecosystem/monero-python

this might be a stupid question, but is there a way to interface with monero without using the daemon? like can it be initiated in the runtime for a more light-weight development experience?

nollied[m]: in the library you linked there is a class (/backends/offline.py) for offline creation of a wallet, private keys, secret phrase etc.

However you need a node for anything else. What else would you (even conceptually) like to do without the knowledge of the status of the blockchain?

yeah but pretty much all of the functions raise exceptions

All the functional tests do just that.

mak_noob[m]: i'm wondering if you can run the blockchain but not in the daemon

(interfacing locally with monero)

To avoid using the daemon, either (1) code everything again or (2) link with the monero libs, if that counts as "without monero" for yo.

nollied[m]: no I do not thing the python library can be used to build a "minimal daemon" from scratch if that is what you are asking. I think the python library is basically a RPC interface.

2 is going to be a large amount of work though.

linking with the monero libs makes sense, but yeah that would be really hard and unnecessary

The blockchain is just data, it does not run. The monerod daemon is what processes it.

is there a live testnet? why do we need to download the testnet data just to be able to develop

separate question

There is. You don't.

See for instance, again, the python tests.

oh, from that repo it mentioned it was necessary

Maybe it's necessary for what they do. I meant in general.

ok cool, is that what offline mode is?

maybe you should try to read a bit the code and understand what it does.

Offline will not connect to other peers, and thus not try to get their chain nor try to upload yours to them.

You can then have your own local chain, parallel to the "main" one.

there is no magic: github.com/monero-ecosystem/monero-…b/master/monero/backends/offline.py

Oh. Again, I was talking of monero, not that particular python lib. I guess I should stop talking since concepts may be different between both :)

mak_noob[m]: i read that. it literally raises exceptions for all functions

moneromooo: you answered my question very well

Meeting here in 1 hour?

yes

If I am correct Dandellion++ protects node from other nodes on the network from finding tx originating IP

MajesticBank: Yes

what protects light wallet users from clearnet nodes correlating tx size of mempool and traffic analysis?

or when attacker own both wallet / have access to exchange wallet and have ability to see traffic on that clearnet nodes

MajesticBank: Light wallets use remote nodes ?

it's specially dangerous when mobile wallet is using only one clearnet node for 10k/20k users

ya, mean mobile wallets

MajesticBank: Ideally all tx broadcasts should be over tor/i2p by default, maybe someday we will have it

both timing and traffic correlation attack would be very easy to perform

MajesticBank: Yes if there is a mitm attack on remote nodes ?

nikg83[m]: what could it achieve

There is no need for mitm for nodes hosted in US

By the way, how to set up my public node with TLS support

do I need to bind it to a domain name or somethin

Don't use strangers' nodes and then wonder why it's dangerous.

moneromooo: Using Cake wallet nodes would be dangerous?

moneromooo: It's by default in mobile wallets

Are they your nodes ?

MajesticBank: are you assuming default settings in software are the secure settings ? If so, it's incorrect in general.

moneromooo: I can’t run my own node, as I am behind nat

nikg83[m]: use frp

* > <@moneromooo:libera.chat> Are they your nodes ?

I can’t run my own remote node, as I am behind nat

that is what i did

moneromooo: No, just addressing average user issue

Run daemon on your machine then use FRP to map it to public

WinslowEric[m]: I built xmr.winslow.cloud with that

Most of the time, it's fine. Like when leaving a loaded handgun near your toddler.

Was thinking there is some solution at protocol level that could enforce it, traffic noise or making transaction look same for traffic observer

lol, that analogy moneromooo.

Well, my usual one: don't use a stranger's node. You wouldn't use a stranger's dildo, would you ?

nikg83: you can run a node from behind nat just fine. You won't have any incoming connections, but you will be able to open outgoing ones - and data flows both ways

MajesticBank: maybe muse about it over in #monero-research-lab, or #monero-research-lounge? I don't know. Stackexchange, reddit?

moneromooo: lol ffs.

I'd hope it'd make people pay attention, but it hasn't. Such sad.

merope: Yes I mean when I am outside and need to use mobile wallet, can’t connect to my node; I might try tor setup and see if it helps

If your ISP prevents you from connecting to the connection you pay for, you can always complain and see if that helps.

It might not help right away, but the more people do it, the more it helps over time.

moneromooo: They don’t have public IPs, IPv6 is not common here

Meeting here in 10 minutes

Same as monero. Making privacy enabled software might not help right now, but the more exist, the likelier we end up at a critical mass at some point.

Like voting. A vote ain't changing much. But if you don't vote...

Yeah ask ISP for public IP address

at least give it a shot

You mean, the same IP address is used by many people ?

If so, yes, that sucks, I hope you get it cheap at least.

no exclusive one

some might provide you free bouncy address

If exclusive, then you should be able to connect to it or your ISP is a steaming pile of asshole.

Some ISP here in China does that

moneromooo: Yes, a billion ppl here & they can’t provide IPs to everyone 😅

WinslowEric[m]: *Means they sometimes alter but you can monitor it with a script

You can get your own ipv6 /64 block for free

Oh. I think I merged two people's lines thinking they were from one.

For example

Set it up on your router, and then you will be able to reach your home network via ipv6

How can you do that if your ISP does not support IPv6 (which I think was implied by "They don’t have public IPs, IPv6 is not common here") ?

Tunneled over ipv4

If you can get to your server via ipv4, why do you then need ipv6 ?

(I know not much of modern networking, so if I'm being dumb, tell me)

Because you can't reach it via ipv4, because it's behind a nat

Your router opens an ipv4 connection with the broker, which then routes the ipv6 packets destined for you through that tunnel

Ah, if your router does this, then you don't need ipv6 in the first place, no ?

ie, it's a reverse proxy.

But you need something on the other side for that reverse proxy

So either you buy your own server/vps/public ipv4 address, or you get this tunneled ipv6

And you get a nice massive /64 ipv6 subnet all for you

Ready for the meeting?

Yes

Hope so :)

Have fun!

let's start

Hello folks! This meeting, like the last one, will be focused on the next network upgrade (hard fork)

Logs of the past meeting: monero-project/meta #655#issuecomment-1024960649

Meeting agenda: monero-project/meta #680

Quick round of greetings to see who is here:

Hello everyone!

hi

hi

hi

Hello

:waves:

Greetings!

Present

hi

hi

Ok, thanks for being here. I would say we can explore the status of the PRs that need to be merged and the PRs that would be good to have. After we have an idea of the situation, we can decide if makes sense to set a date.

rbrunner made an excellet summary of the situation the we can use as a guide: monero-project/meta #680#issuecomment-1079924577

I would also like to dedicate a bit of time to discuss the status of multisig in relation to the hard fork, because in-progress projects like Haveno and RINO need multisig to be robust, before being able to launch.

The situation in general looks good, most PRs have already been reviewed or are ready to be merged. So, that's a good start

Oh wow, BP+ still not merged. I did that ages ago now...

8149 needs to rebase onto 8061

view tags not merged as well

Maybe a gentle ping for vtnerd, as they are involved in so many important reviews ...

Ok, let's start with the first one i would say, fee changes

that mostly only needs to be merged as far as i can tell

fee changes looked good to me

Including the compromise from the last meeting, right?

yep

I think it can be merged

Good. next one is bulletproof+. What's missing?

I can type that up.

Nothing AFAIK.

A final approval i would say

it doesn't have any approvals

The final signing off of the the review?

0

We have BP+ audited, so in general it should be good to merge. vtnerd reviewed it a while ago but he never approved it.

I asked him for an approval but he kinda started a new review from scratch, and now he is currently unavailable and it's unclear when he will have time again.

maybe jberman[m] and I can do brief reviews (check hard fork mechanics, glance over crypto use)

can do that

The testing on Testnet should also have some value, even if something escaped review

nice. Thanks. We should get word from vtnerd to make sure if we should expect a review from him or not

he's currently unavalaible and I'm not sure how quickly we can expect that word

alright. Next PR is to bump ringsize to 16 monero-project/monero #8178

Pretty simple code, uncontroversial from that point of view

this one shouldn't require any further discussion and only need to be merged

noticed a couple small merge conflicts with tests, will resolve those asap

It looks approved, maybe moneromooo wants to look quickly over it too because I think you are the most experienced with such ring size bump PRs.

Sure.

jberman[m]: (sorry thought this was for view tags)

ty moo

Anything else on #8178? Otherwise we can move to the next one

i'd say move on

Allright. View tags: monero-project/monero #8061

noticed a couple small merge conflicts with tests, will resolve those asap :)

I not only reviewed view tags, but also implemented it in p2pool and tested it on a private testnet. All went smooth - p2pool could mine, monero-wallet-cli could see payouts.

so #8061 looks good to me

Also testet it. Works.

#8061 looks ready

noice

Your chance for eternal fame

Nice. Seems like was reviewed and tested quite extensively. I would say only final approvals are needed after jberman's fixes and then can be merged?

The order in which we should merge things is also something we have to discuss later.

Largest changes first and then the smaller ones I assume.

Merging will probably limit itself with generating conflicts

It will have some conflicts with multisig stuff and bp+

And RPC versions numbers are another source of conflicts

RPC version is easy to resolve since we're doing a hardfork. Just use some new higher number

Seemed like a good idea at the time...

One thing we also mentioned briefly in the last MRL meeting was what the "grace period" should be where tx's with view tags and without are allowed, to allow the pool to clear (ring size bump and bp+ also have this grace period). We settled on 1 day same as in the past from what I remember, so just re-affirming that

IIRC we always had 1 day

cool

#7877 is merged so #8149 next to discuss?

alright. We can go back to this if needed. The next PR in the list is the fixes for multisig: monero-project/monero #8149

I need to rebase that when BP+ and view tags are in

Is the original author of that PR, perfect-daemon, still, well, missing? And does that matter in any way?

it kinda was reviewed by UkoeHB and vtnerd, not only vtnerd

I want to stress the importance of having multisig fixed as soon as possible, so would be good to also have two more PRs merged for the hf: monero-project/monero #8220 and monero-project/monero #8220

That's two times 8220? :)

8203 is the other one

lol sorry: the other one is monero-project/monero #8203, yes

I need a third pr to add force updating. So 8220 -> new PR -> 8203 to get everything in

Yeah, but 8203 is still very much at the beginning, as far as I can see. And does it harmonize with the added control round?

no, I will need to rebase

But not much change in logic or even crypto? I am a bit sceptical about that, time-wise, to be honest

Does Haveno intend to take advantage of the improvements that this would bring?

not too much change, at least compared to the original PR

rbrunner: Haveno sponsored a good portion of the changes 🙂

So, at the ends looks like multisig is the PR that needs the most attention

Oh, reminder that RINO set a bounty as well of $10000 for merging all three PRs, so that should be a good incentive for the community

Do we lack reviews maybe because the vulnerabilities are not really public? I know some background info has been passed to few people only

It's 4 multisig PRs, no?

binaryFate: it's all public in the patch

rbrunner: 1 is already merged

we lack people actually able and willing to review

selsta: yes but I mean some context maybe making reviewing easier

good if not a blocker

I think if we aim to take 8203 in, 8220 should get merged as soon as possible, to make that "interim" PR possible

yeah, we should probably reach to the community asking for reviewers if finding them for those changes is an issue

I can review general patterns and such, but don't think I'm able to do a comprehensive crypto review to spot vulnerabilities yet (I've been studying, but not there yet)

I mean if we need more security then an audit would help, but I'm not sure if we will find another review for it in the community.

Same here as jberman[m] . Even less crypto knowledge sadly.

Certainly not with vtnerd unavailable ..

rbrunner: I mean vtnerd reviewed it, unless we are talking about a different patch now

could/can luigi1111 give it a shot?

I was thinking about 8220, which has no comprehensive review, but only me testing it and moneromoo looking at the code, but not the crypto, if I understood correctly

8220 doesn't have any crypto changes, just key exchange protocol changes

oh ok, I was still mentally at 8149

Yeah, that might be a problem if we think we need a second review

I would be confident enough to merge 8220 ...

Ok. Then we need to find somebody able to review that PR, if you know somebody, maybe ping them on the pr to catch their attention

8203 is the one without any review currently

is h4sh3d around? maybe he could take a look at 8220

Hi!

8203 is on hold anyway until I can rebase onto 8220 + 1

hi h4sh3d :) feeling up for more multisig review?

this guy: monero-project/monero #8220

Should not hurt too much, and the code runs :)

Yeah sure! Time wise it will not be possible for me in the next 2-3 weeks (family getting bigger ;p) but after that for sure! If that’s not too late for you guys?

would it be possible to postpone multisig stuff to a post-fork point release?

Well, looks like timewise, it's on the critical path

While it doesn't need to be part of a HF, I'm worried that many people using Monero but not following closely may not have seen the multisig issue announcement. So having the fix in the HF is ensuring everyone will at least use updated version after that

That would be my proposal for 8203, frankly. I think postponing all would be unfortunate

And the rest is really so close ...

I would really prefer to not postpone it. That could create huge problems for Haveno. Like having to hold off launch

Multisig wallets would usually be used for large amounts, I'm concerned some big entity out there will get hit by the vulnerabilities unless we force them to update basically (via fix being in HF)

I just mean release it separate from the hf, not delay review/merging (which is happening at a snails pace anyway).

Yes but then you lose this force-to-update effect of the HF

Isn't that a contradiction?

well it's up to you guys, not much I can do to speed things up on my end

Maybe if we ask nicely moneromooo can look a bit deeper into 8220 and approve, and we merely move 8203 into a point release

Why not release multi sig with another HF?

Haveno would be delayed for that

Two HFs? Back to back? Seems like a lot of headache...

WinslowEric[m]: fine by me. this is a monero update, not a haveno one

What is the timeline fro multi sig review etc?

ArticMine: IMO too extreme to abuse the HF concept just for this desirable side effect on multisig wallet code

We need to find reviewers, that's the problem. Pushing to another hf seems eccessive

Fair enough but there are problems with a partial implementation of multi sig without a HF

BP+ is not approved yet, then we also have to do changes to Ledger and Trezor for BP+ (which supposedly isn't much work but someone has to look into it), that will also take time. It's not like all other stuff is 100% ready and we are only waiting on multisig.

We will also need time to test everything on testnet.

what HF timeline are we talking about?

For multi sig

Is the loose consensus now that we must have a second review for that heavyweight multisig PR 8149?

8149 had two reviews, I doubt we will get more without an audit.

we will need some kind of review when I rebase

Because if not, 8220 is peanuts in comparison, and IMHO 8203 nice to have, but not critical. Haveno may disagree.

Ah, yes, UkoeHB reviewed the original one.

maybe we can make a clear announcement of what exactly needs more reviews, so that external entities out there can decide to step in to finance/organize an audit?

8203 is not urgent for us iirc

So where's the problem? :)

Ok so, we have 5 minutes left so to wrap it up:

we need somebody to approve BP+, which has been already extensively reviewed

Do we have a timeline for the HF?

what about getting 8149 into the HF, then 8220 + 1 + 8203 into a point release (if necessary)?

we're not discussing HF date in this meeting?

ErCiccione: jberman[m] and I will look at the BP+ PR (probably within 1-2 weeks)

UkoeHB: +1

sech1: if we feel like we already for it sure, but we don't have much time left

usually dev meetings extend past the hour, I don't mind staying

I am ok

shouldn't take long anyway

A date would be nice, even as an attempt ...

The problem with timeline / setting a date is difficult when some things are unclear with how long they will take. I'd like to have BP+ merged first and then someone who can look into Ledger / Trezor changes.

Last time we set a date there were a lot of things unreviewed and then the date came it it became pointless because we can't just merge things unreviewed.

2 months should be enough for everything probably

we have a nice date approaching p2pool.io/tail.html

:)

as a community member, holding back on a major monero upgrade that brings BP+ and higher ring sizes for the sake of an external project doesn't look like the way to go, especially if the PRs mentioned arent critical to multisig. projects should build around monero's progress, not the other way around

personally i find myself in the middle. I would like to set a date, because pushes people to wrap things up, but i also don't want to get to a point where we postpone it again

mining software might need to double check that they won't get uint64 overflow when the total supply exceeds uint64::max; iirc moneromooo fixed Monero's implementation a couple years ago

So maybe someone can do an extra overview issue on multisig, with the current status of each PR and what is remaining. rbrunner something like your comment

Who are the candidates for Ledger and Trezor changes?

well usually the companies do it themselves

but last time I needed a small change from Ledger they took over a month, so I feel like we will have to do the changes ourselves.

selsta: That would be useful

selsta: I guess I can write that

also Trezor only updates their firmware every couple months, that was an issue the last hardfork

Does all not sound too happy then

it always works out somehow :P

"uint64 overflow when the total supply exceeds uint64::max" <- this is still a few years away. Tail emission starts before 2^64

alright, then i would say setting a date it's premature, but we could set a date for another meeting?

1 or two weeks away?

selsta: ah

sech1: ah

Give it two weeks and look at setting the HF date then?

how about 2 weeks, monerotopia is this week

sounds good to me

Yeah, with 2 weeks there might be a chance to have BP+ fully reviewed until then

yeah and we will ahve the status of multisig more clear

ok then

or at least have a good idea on the timeline

thanks everybody for joining. Have a good rest of the day and see you in a couple of weeks

Thanks

thanks everyone

Thanks for the moderation

feel free to keep discussing 🙂

Thanks!

With respect to reviewing the multisig PRs, would it be worthwhile to hire an audit firm for that?

Would definitely speed up the process

And I am certain the community would be willing to contribute to a CCS that raises funds for an audit firm

JP Aumasson has done a few audits for Monero (related) code if I recall correctly, we could try to contact him

Agree, I'd like to send some monero for that.

cc binaryFate ErCiccione

Would potentially be worthwhile to dedicate the RINO bounty to that, but it is of course up to RINO's discretion where to allocate the bounty

We could put some communication out there describing scope of work, so that external entities could decide to step in and help

Maybe some Kraken grants or something like that, exchanges must hate not having multisig

An external audit might take quite some time

Think it would be faster than finding 'internal' reviewers to be honest

Especially if we actively reach out

Hey debout ne

<dEBRUYNE> "Especially if we actively..." <- Hey debruyne

I have a question

Sethforprivacy says that an exchange could connect your monero with your id, via targeted attacks… is there some truth to what he’s saying ?

* Sethforprivacy says that an exchange could connect your monero with your id if you kyc… True or false ?

you can do anything with targetted attacks

has nothing to do with monero in that case

your devices can get cracked, keyloggers installed. not monero's fault

louipc: But if you withdraw monero from coinbase to your own wallet, you can start using it as normal without them being able to see anything ?

He’s suggesting that if you have KYC’d monero you can be tracked…

if you read it again he's saying you will be safe

unless you get targetted