would be nice to collapse blockchain_db and blockchain into a single layer, now that we'll nevr use in-memory blockchain ever again

a ton of adapter layering can go away

hyc: I think we talked about this but do you remember what the status of monero-project/monero #7147 is?

I don't think this issue appears anymore. Can we close it?

I think we can close it, we don't have cdrkit as a dependency any more

not sure why it was ever there, prob inherited from btc

sech1: hyc: this fixes an often reported issue, could someone take a look at this patch? monero-project/monero #7084

it looks good to me but want to double check everything rx related

Do we know who makes a lot of transactions on testnet for the last 3 weeks or so already? Right now there are even more txs on testnet than on mainnet.

Not that this is a problem, I am just curious.

Maybe to prepare for some statistical test?

IIRC someone mentioned they want to see if they can trace txes, and I guess didn't realize it was trivial if you have 100% of the traffic.

Was in -lab I believe.

Or maube that's just a pretext to spam. Who knows.

moneromooo: Or maybe testing to see what minimum % of spam can help them analyse

They seem to play around a lot with different fees, and throwing in transactions with gigantic fees if I read that correctly ...

May something useful come out of this :)

That sounds useful then :)

moneromooo what was the fix for monero-project/monero #8120 ?

The one in the comment. I'll make a patch now.

that's not a fix

you still have garbage data in that variable

it only fixes the symptom and hides it from UndefinedBehaviorSanitizer

Why ?

Hmm, the first one's not a load...

compiler implementations are allowed to treat values outside of [0;1] range as both true and false

Can't read, they block tor now.

i.e. uninitialized variables

That's why you !! after read.

screenshots of that page: imgur.com/a/MKjuH6C

if you add !! to uninitialized/garbage data, it doesn't make it less uninitialized/garbage

this is not a fix

Is it uninitialized ?

bool can only be 0 or 1 in binary data

so definitely uninitialized, or memcpy'd from a buffer without checking

Well, feel free to patch it and maybe throw if not 0/1 instead.

I'm not familiar with that code, I don't even see where it's filled in

Stuff read from the network. So attacker controlled.

actually, that variable is only directly initialized to true/false in various places

so it might be a buffer overrun somewhere

wait, it's a message header read from network?

I thought it was.

But hten I'm not familiar wiht this code either so...

std::memcpy(std::addressof(m_current_head), std::addressof(temp[0]), sizeof(bucket_head2));

yep

comes straight from network buffer

I would change "bool m_have_to_return_data;" to "uint8_t m_have_to_return_data;" and make appropriate changes in all places where it's used

since it's can be any data coming from network

I'll make a patch :shrug:

damn, it's worse than I thought :D

we use "bool" in portable_storage to load/store data and sizeof(bool) is implementation-defined

a recipe for a disaster

not that I know any compiler where sizeof(bool) != 1, but it can explode in the future

probably need to add static_assert for this

selsta moneromooo monero-project/monero #8186

Thanks

Hi, do you know which of the 9 options was selected for Jamtis? Is it still in discussion? monero-project/research-lab #92 Thanks for help!

And on this post the author says "New wallet tier allowing fast light wallet syncing with greater privacy than existing solutions" but "Wallets will not synchronize much faster". Will Jamtis and Seraphis improve wallet synching? Thank you very much monero.stackexchange.com/questions/…potential-seraphis-protocol-upgrade

moneromooo: 7084 conflicts, could you rebase?

sech1: thanks, should we also open 8186 against release?

Oooh, that never got merged, totally explains why I still get spam, I had assumed someone had broken it again :D

Oh wait, I'm thinking of the net code weak pointer spam actually...

done

ty

.merge+ 7084

Added

<rbrunner> "Do we know who makes a lot of..." <- Highly likely it is xmr-ack doing some machine learning tests.

selsta are we planning a point release before v0.18 hard fork?

Rucknium is correct, my research includes collecting a large dataset of de-anonymized transactions on test-net to research if ring signatures are susceptible to machine learning attacks. The dataset will eventually be open sourced for peer review.

<kwxmr[m]> "Hi, do you know which of the 9..." <- After analysis it seems Jamtis uses option Janus E. And view tags make scanning faster for new txs. But I'm not sure 100%, it would be nice if someone can confirm, thanks

kwxmr[m]: jamtis is Janus B. View tags will be added in the upcoming hardfork, which will speed up view scanning for new outputs. Jamtis will add some optimizations to view tags for further speedups. Jamtis also has a lot of privacy improvements for third-party scanning (eg mymonero).

fwiw UkoeHB I dont expect users to flock to the higher privacy mode

much more than they flock to client side scanning

endogenic: I imagine anyone using third party scanning will continue to use it

Anyway, the purpose wasn’t to increase/decrease the number of people using third party scanning. Just improve privacy for those that do use it.

the extra option is nice

but it still has considerable clientside overhead aiui

The old option will be dead, so it’s not really ‘extra’.

well, we have tiers now, with the old privacy mode(characterisrics of view key disclosure) still preserved in everything but underlying implementation structure and names, aiui, so how will it be dead?

The clientside overhead is downloading key images and 1/256 outputs.

yup

?

For one, all old view keys (except multisig wallets) will not be used any more. The new view keys gain full-view capability (full balance on all accounts/addresses including change/self-spends), so it is strongly advised to not develop third party scanning services with those keys.

Full-view means recomputing key images *

why not advised any more than a current lws is advised? that's not much worse than what we have now. and some users would like that

and will there not be a mode which is more private tha that

but less private than the "improved" mode?

we could call improved mode tier 1

and client side scanning tier 0

and full view tier 3

i have to go back ans confirm

people are going to build such services as long as it provides any meaningful speed boost

as a side note i also really question how well a migration to a new keyset will go over

will "cost" a lot

There are only three main tiers: spend, view-balance, find-received.

there you go

We can’t stop people from building a view-balance service. This is a basic reality of having a view-balance key, (which is a significant improvement over the current key system). All we can do is provide a privacy-optimized third party scanning option. Adding more tiers isn’t really feasible due to increasing complexity/bloat of the system.

Migrating the keyset (view keys) is necessary since the new view keys have different capabilities than the old view keys. If we updated without migrating, there would be a behavior change that undermines users privacy models.

that's what I said which you said was not true a couple times then..?. it's an additional option

even if the structure is semi novel

migrating the keys is only necessary if we deem the new features necessary

i think the new tier types are cool personally

i think all options should be given to users

in an ideal world anyway with no costs or tradeoffs

so it's not dead

There should only be one migration path, otherwise users that accidentally follow multiple migration paths will encounter lots of issues.

(this is guaranteed to happen)

Preserving old view keys also implies supporting third party full-view scanning. At the very least, I won’t write any code that helps that happen

what multiple migration paths are you talking about...?

and idk where your last reply is coming from - you just kind of admitted your proposed system will support such tiers

? A) new view-balance key derived from base spend key, B) old view key -> new view-balance key.

Path A is specified in the jamtis document.

oh ok gotcha

i dont want full view scanning either

i doubt users would care

bc the alternative is fast enough

but would tier 1 be fast enough? idk

fast including storage, bandwidth etc fwiw

hi all, with everything going on in the world i just wanted to show some appreciation for all the work you do on making monero as amazing as it is

Probably on par with current system, since the bulk of download time is key images.

more and more people will be relying on it for their freedom, so thank you for your service

UkoeHB: seems like an important question to confirm

When I look at the "full view-only wallets" that Jamtis newly offers, I don't primarily think about and see any new scanning services

But much more that we will finally have a system for a fully-functioning voluntary balance disclosure for those cases when its needed or wanted

i agree

well

except for the no new scanning service thing Lol

Not sure what you mean. Of course we can't prevent anybody from building those. Does not mean we must make the impossible, no?

*them

I can't prevent anybody either from typing their seed on a scam site ...

what are you replying to with that question?

the services would be very new

and someone's gonna have to build some tier 1, 2,.. code

To this remark of yours: "except for the no new scanning service thing Lol" I guessed you would not like such new services. Maybe I am wrong.

no i mean "except for" your remark

as in i do think about them as new and see them

or will see them anyway, perhaps one day

i have reservations if this path is the right direction for monero right now, sure

mostly the keys stuff and some other changes

It's good to have people taking a critical look, agreed. I don't fully understand yet those reservations of yours, however.

Do you have doubts about those Jamtis "Full view only wallets"?

hm well i wouldnt want them to be offered by default to users

i am with koe and others who have talked to me about it

in that issue

i dont even think a lws needs to or should implement it

perhaps it can

and then have a user interactively authorize it

or othwrwise confirm

my reservations are a struggle to question what the monero community is focusing on and condoning nowadays

things have changed i think

in some ways

we have higher priorities

and i wonder if this is not only a misdirection of our talent but possibly even a step we'd find it harder to walk back if we need to - mostly around seraphis

increasing ring size is tantalizing

but may be a lure that would prevent ys from prioritizing a real solution

real solution?

and i worry about other points that no one is even debating here

i was told things like dont talk about it

by oddly compromised interests

i also notice a flurry of misinfo and frankly bs from those stakeholders when i brought it up in the past

not talking about koe or rbrunner fyi

that misinfo i think has convinced us to think small

endogenic: Hi endogenic which points are your referring to?

well i will reiterate here

i posted on github and reddit a few times rexently

hard to type it all w my thumbs again

Maybe, as it gets less and less technical, we could move over to #monero to continue this discussion?

and i also have to sort out some life stuff rn - i have little help so i have lots of todos - i'm sure i will be painted as running away but frankly i'm exhausted about repeating myself alone

lol nice one rbrunner

endogenic: Uh ok no need to rewrite again here, going to check Reddit or GitHub

research is both more and less technic

al

anywya

.bbl

You lol already the second time about me today :)

multiply by 10

? twenty times? I don't think I wrote already 20 lines here today ...

* > <@endogenic:libera.chat> i posted on github and reddit a few times rexently

Uh ok I missed them, no need to rewrite again here, going to check Reddit or GitHub

I have a guess what endogenic means with this, based on his posts on Reddit and GitHub: "but may be a lure that would prevent ys from prioritizing a real solution"

With the "real solution" being dropping rings altogether and use something like the Halo protocol from Zcash

But well, if nobody steps up and develops that ...

you cant easily convince ppl to go back from 96 ring members to 16 if the existing ring sig tech lets us do a spend behavior that the higher scalability version cannot

<kwxmr[m]> "Hi, do you know which of the 9..." <- Thank you very much UkoeHB . So from what you said I assume Jamtis has selected option 9, Janus E. Right? Thanks again!

so i must step up and being halo 2 to monero? i'm trying to remind us we need to not give up on that and other spending behaviors we cannot even condone but which are now valid

i posted on gh about it

"so i must step up and being halo 2 to monero?" Did somebody request that from you?

For me "giving up" would mean we close shop, wait until Pirate Chain copies over Halo 2, and then all switch. Bliss, no more rings :)

kwxmr[m]: I said it was Janus B. The find-received tier can link outputs to your addresses (for non-change/self-spends), but can't read amounts.

endogenic: you seem to be implying we should be paralyzed by 'what ifs'

opposite

we already are

and it's not a what if

UkoeHB: Ok thank you very much!

who is paralyzed? not me

Now it's my turn to lol a bit ...

the community. you said "we" which is plural

sure, I don't see anyone who is paralyzed

so?

"we already are" ?

what if i said i do?

would you ignore me?

how many people have to say they see it and argue it over and over?

i'm not alone

the people who agree are highly technical

i'm out

i dont need to stress myself over this rn

Probably not, yeah

clearly has no effect and i get laughed at by rbrunner. thanks man

i'll just keep on my work

why drop criticism if you aren't going to back it up... this is confusing

i do back it up

besides i'm not the proof of it

i've talked about it over and over

this is the first I have seen you mention halo 2 lol

well, that's bad

i'm not interested in halo 2 specifically either

we have a research meeting every wednesday if you want to be sure your research concerns are noticed and addressed

i have been doing so

and will keep doing so

thanks

btw i've been here since 2016

i basically helped start those meetings

I wonder why it's so hard to get down to Earth and have a discussion with hard technical arguments. I think such arguments would have considerable impact

it's not, jerk

stop arguing so dirty

i'm out if here for now

call me avoidant. maybe i have a reason to be

I wish you to have impact, and then I am a jerk?

And argue dirty?

UkoeHB: What is a tier exactly, it is an address with corresponding rights?

So overall each address would have the FindReceive tier, plus the 3 merchant tiers, and plus the spend tier? It means 5 levels of private keys that can be shared?

s/an/private/, s/address/key/

* UkoeHB: What is a tier exactly, is it a private key with corresponding rights?

kwxmr[m]: check section 4.5

I used to word 'tier' originally because higher tiers have all the capabilities of lower tiers (subsets of capabilities).

UkoeHB: Thank you very much! I have all information I need

what was the purpose of the monerod zmq interface? looks like it's incomplete?

AFAIK, faster RPC. It's used by mymonero internally, but I'm not sure anyone uses it beyond the notifications. It's a parallel RPC so it's getting left out when new RPC get added, but still works fine for what it implements.

yeah faster RPC

pub/sub modes as well

Speaking of RPC, could y'all think of any security concerns for allowing public nodes to send Access-Control-Allow-Origin headers? I created a PR that allows for that: monero-project/monero #8187

It would enable a lot of web functionality for webextension or other browser applications, but I'm sure that there was a decent reason for requiring an RPC login

Is it possible to make a comment on the transfer (transactions) to Monero? Here in banks there is a "purpose of payment" there you can write any message. This is very important and necessary

I don't think there is a currently supported way to do this. You used to be able to write unencrypted messages in the tx_extra field, but that was bad for fungibility, so the devs removed that feature. If you aren't using payment IDs you could probably cook up a way to send encrypted comments in the tx_extra field

I'm stupid, I'm thinking of unencrypyed payment IDs, just look at the above link

a simple unencrypted message (payment comment) for the recipient

It will be encrypted between you and the recipient, so they can see it

but not anyone else

and how many characters are allowed there at most? How to do it?

Please don't bloat the chain by putting stuff in tx_extra

Especially messages

Just use one of the myriad of encrypted communication methods already available. Much more efficient, and avoids bloating the chain forever

I don't need an encrypted message, and I don't even need it to be stored somewhere in the blockchain. You just need to get it to the recipient of the payment with the payment and read it

tx_extra gets stored in the blockchain as part of the transaction data, so it's not what you're looking for then

You need to establish some form of communication with the recipient

merope: The recipient of the payment can be anonymous. How am I even going to find other means of communication with him, as you say?

For this, monero is anonymous

Same way you found their wallet address, I guess. They could leave you some additional contact information

Oh yeah if you just want an off-chain way to communicate payment details to someone, use any anonymous messenger

Also endor00, IIRC you can't "bloat" tx_extra because it's also the same size no matter whether you use it or not.

I do not know the person there is no data (such a situation if). And yes, there are no anonymous messengers. Here Montero could become such on the basis of its technologies, where is the wallet (account number) this is the login in the messenger

another 3 xmr fee