doesn't even make sense to my why any kerberos stuff is built into there but whatever

"salsa.debian.org/debian/krb5/-/merge_requests/5" this unmerged PR will add static libs into the most recent version

"sources.debian.org/src/zeromq3/4.3.1-4+deb10u2/debian/rules/#L21" they added krb5 in this version of libzeromq

"sources.debian.org/src/zeromq3/4.2.1-4+deb9u2/debian/rules/#L21" previous version was without krb5

But it's waste of time to sync with each distro in order to build static binaries, easier to use depends

yeah, I guess so

Hey guys its hard for me to keep up is the ring decoy issue going to be patched soon or is it still being duscussed which approach to take?

Hello bros, does anyone know current monero daemon follows which RingCT version? 1.0, 2.0 or 3.0? Or the progress of this?

<jakroo09[m]> "Hey guys its hard for me to keep" <- Shooting to have an improved patch ready for re-review within the next day, possibly tonight. AFAIK once the patch is merged, assuming nothing else is holding up a release, the next release would ship 2 weeks later

jberman[m]: Oh ok thanks jberman I saw you on that monerotopia thing you seem like a really knowledgable dude......really appreciate what you are doing for the monero community

its guys like you and younger passionate guys that will keep XMR going into the future

Thank you :)

even though we have a general fund we dont have a massive dev fund like ETH....so the future of XMR purely relies on the hard work of the devs we have

but i feel the future is bright and we are in good hands

"the next release would ship 2 weeks later" <-- might be even faster

though depends on how available some people are

selsta: Hey Selsta! Is there any chance do you think we see Triptych this year or is there still other ways the Monero project can go in terms of the massive ring upgrade?

BP+ with a slight ring size bump is more more likely this year

the problem with Triptych is the complexity of multisig

triptych ain't happening this year

ok yeah i figured as much i understand there is a lot that goes into it

luigi1111w: Is it ever happening 🤔 if multisign is not feasible

multisig is possible but more complex

selsta: Yah I mean a acceptable implementation

there are other schemes that are similar to triptych but with easier multisig, but they require everyone to generate a new address (different address scheme)

hmm wasnt there another implementation option called seraphis/lelantis?

it's also possible some "magical" new scheme will come out in the meantime; this area is in pretty active development

luigi1111w: that would be pretty sick

jakroo09[m]: yes but they require a different address scheme

ah ok got it

selsta: Should be fine, what happens with subadress? Has the migration been thought through yet

no

jakroo09[m]> luigi1111w: that would be pretty sick <= agreed

luigi1111w: your comments motivated my subconscious to come up with a new idea that might work

eggcellent

Unfortunately I think it's impossible to come up with a scheme that has the same properties and efficiency as Seraphis, while also perfectly matching the current address format and permission structure. So, there will be non-trivial tradeoffs to consider (if everything pans out in the end).

and on further thought... my idea was mistaken; it's probably impossible

*impossible to match current address format and permission structure

that's the spirit

The problem is any new key image scheme on a fixed base point will let the view key holder know when outputs are spent. So, current view-only wallets would gain that power. Seraphis solves this by changing the address format so there are 3 private keys instead of 2.

Relevant: for most users today, a view key also lets you guess with a high degree of accuracy when an output has been spent. That’s how light wallets work to my knowledge; I don’t believe they use key images to determine spent outputs, the server guesses

hm looking at change outputs?

Yep

If you know all past outputs sent to an address, then see a new tx with an output sent to the address, you can check the rings of that tx for past outputs that were sent to the address. If all rings in the tx contain an output belonging to the address, you have a high degree of certainty those outputs were spent in that tx

guess I forgot you could do that lol

Are the Seraphis efficiency gains + same address format maintained if that property is dropped?

no to retain the address format there are efficiency losses

Got it

jberman[m] that's incorrect

that would require extra indexing and wouldn't be 100% anyway

for sure mymonero uses keyimages

never mind indexing

the light wallet API doesn't seem like it takes in key images as input anywhere: github.com/monero-project/meta/blob…ter/api/lightwallet_rest.md#methods

it looks like the mymonero client uses the spend key to filter out key images that can't be correct: github.com/mymonero/mymonero-app-js…nt/response_parser_utils.js#L56-L71

I think what's important is that current view keys already leak significant data about your spent outputs, so making that more reliable wouldn't necessarily affect users' threat models. You could argue that 'in theory' users could avoid this view-only data leak with a custom tx builder, but I don't know of any reason to think one exists.

Yes, that^ that's why I felt it was relevant

anyone know how exactly block_weight differs from just raw block_size?

exactly would be in the code, but it's to do with number of outputs mostly, since BP scales poorly in compute and strongly in space

gotcha, thanks.

Weight is the notional size that a tx would have if its bulletproofs were to have 2 outputs at most.

Or something like that.

thanks for that as well

ndorf see ZtM2 section 7.3.2

of course ukoe wrote about it

nice. thanks again

ndorf weight = size for all 2-output transactions. If transactions have more than 2 outputs, their weight is bigger than size. Exact details are in the code

just wanted to document the relevant fields in the daemon rpc guide, so this is already good enough, i think. feedback welcome of course erciccione/monero-site #25/commits/56e81b1f810a5dc17870e16953d55ed042257eee

LGTM

Hello. I am looking for some help. I am building the site xmrmemes.com and I had everything working fine on test net locally. Once I attempted to take the site live on mainnet, I have faced a bunch of issues.

The payments occasionally would go through but sometimes it would take hours even though Monerod is fully synced. I seem to be having issues with the RPC returning nothing the large majority of the time. I have been trying to debug it and am getting [] (blank array) when checking the transfers.

I really don't know what to do.

monerod says I am fully synced

rpc command says 2021-08-10 20:31:51.896 W Loaded wallet keys file, with public address: 47iHdE1TQ3c84EKE7PDF7Qb6hnncpW4ysS6zU3SoR8Pwcw2zRmNGD4wUz9sMhWL37Jg8rxZPYvSW4KLGg3hU4y9bDhLH6ZL

but when I interact with the RPC file using one of the Monero integrations libraries, i get nothing returned. But it all works on test net.

Digitalocean backend shows the server is using only 60% memory an 15% cpu the past hour

Any ideas how I can debug? Not sure where else to ask. I have been trying to fix this for days.

#monero's the best place to ask I think. But it's possibly a RPC timeout due to a lot more traffic on mainnet.

Okay I will ask there, thank you. Do you know if there is anyway to prevent an RPC timeout?

Set a massive timeout.

Might not be a great idea either. Find what RPC is taking time (hopefully just one).

Assuming it's that in the first place.

IIRC getting rct output data is heavy on the daemon the first time, but it's cached so only the first tx will take a while to create.

If a tx is created but takes hours to go through, it might be you have random network connection issues. Relay is "blind" and txes get re-relayed every... 4 hours IIRC.

You can also run monero-wallet-rpc with --log-level 2, you should see any errors in the log.

Timeouts won't say "timeout" per se, it'll say... "recv fail" or the like.

Log level 1 on monerod should also help in case the daemon itself is going wonky, you never know.

moneromooo: Thank you very much

Well now I realize it is something else. Because the verification of XMR addresses works flawlessly and fast on registration. I just used the wallet with the monero-wallet-cli tool and the "show_transfers" command actually returns nothing so the RPC I think is actually working. It almost seems as the wallet was corrupted or something? Have you ever seen something like this? There was definitely transactions before but now it shows

none. The Monero library also won't overwrite a wallet with the same name so I don't think I overwrote it.

I will try to create a new wallet and see if things work. but honestly very bizarre the wallet data would go blank like this

And excuse my ignorance, I don't see anyone talking in the main Monero group on Matrix. Maybe I clicked the wrong one. I am new to matrix. Anyway to link the group here?