!balance

balance

balance!

god dammit how you used to do it?

Mr_Doge, it ded

wtf

why

a lot has changed since 2017

jwinterm,

Mr_Doge: balances are safe and will be available someday

Mr_Doge, I dunno

tippero is ded tho

press F to pay respects

F

tippero did not keep up with the protocol changes

.seen tippero

in what situation would I need to use "store" RPC command? getmonero.org/resources/developer-guides/wallet-rpc.html#store

lza_menace: Considering that generate_from_keys does automatically save the wallet, my guess is for hot/cold wallet management.

The wallet saves data on the chain state, and cold wallets take in a variety of information about transaction outputs. My guess is one of those doesn't automatically save, instead only operating in memory.

That said, I will say I'm not sure.

thanks

is there a "right" way to scale wallets for many users for a web app? subaddress per user? access per user? payment id per user?

s/access/account/

each have his own encrypted wallet that is decrypted client side

so server never gets direct access

not necessarily for a web wallet

but i guess person with server access could always just change the client code and log passphrases anyway lol

yes for web wallet.

the server can store the encrypted wallet but wouldnt have passphrase

that's not my questino though

lza_menace: Subaddress per user if you're being a custodian (payment processing/exchange)

i don't seem to be having good success doing subaddress based

apps that have been account per register/user ahve worked flawlessly

now im trying subaddress based but it's buggy/weird

Standard addresses require scanning for unique key pairs. Payment IDs are dated and no longer recommended (wallet software also won't generate them unless explicitly told to). Subaddresses allow rewriting the check to see if a transaction's output key 'belongs' to you by rewriting it to P - X and then doing a hash table lookup

Poor explanation, sorry. My comment is they're unique per user, identifiable, and extremely quick.

What's the problem?

You likely want to write your own indexing code. Subaddress indexes of x/y, where you should skip x == 0. You can do x per user and y per requested addresses.

But without knowing more about your use case/problems, I'll really just throwing out words and random specs :P

im testing a new web app using subaddress per user registration - I'm using a single wallet-rpc process and using "create_address" on registration and storing the subaddress index in the DB alongside user details

from an external wallet/account I'm sending funds to test to subaddresses A and B

Sounds correct so far

balances and transfers all seem to work fine. the RPC has good mechanisms to ensure my balance check and transfer use only the right subaddress index - seems good so far

(as long as you have each user under an account; you don't have to, but I'd recommend it. 0/0 doesn't return a subaddress. It's an exempted index)

but the issue is that eventually the funds "go missing" from a subaddress

As in, they're no longer reported when you call get_transfers?

they're still in the wallet, but in the primary account

My guess is that's change

Wait, nope

You didn't spend the incoming deposits, right?

And incoming_transfers or get_transfers?

also, there have been a couple 0 balance transfers

get_transfers

If you use curl, does incoming_transfers (which requires specifying the index) report it correctly?

Just trying to debug that aspect

is it possible to corrupt things by opening "wallet-cli" in conjunction with "wallet-rpc"?

RPC is running and I'm poking around in CLI (read only though)

My other Q is when you use get_transfers, you say it's in the primary. If you're checking by .address, what's the .subaddr_index report?

I don't think it would, but it does sound questionable.

you know what...

if a subaddress sends funds to another subaddress of the same account it seems to not "report" things accurately

subaddress A sent funds to subaddress B

I see it in the "out" list of get_transfers

but I don't see it in the "in" list

it's also reported as "amount": 0

in the out list

hmm

maybe I have a wire crossed somwhere

will check later - thanks a ton kayabaNerve

Good luck lza_menace. Sorry I couldn't help more.

damn, the monero space video with sarang is NICE - check it out youtube.com/watch?v=w5rtd3md11g

i wonder, if i have 3 tainted outputs (outputs i know would be considered illegal in a jurisdiction) could one not simply churn them, i.e. do one merge of all these outputs, send them around a bunch afterwards (only as a single output) and increase privacy that way?

can't watch at work but what's with the 'monero tracing tool'?

tumbling monero when?

he doesnt give a whole lot of details, which makes it hard to assess. also, i am not the expert on this.

"Block notifications are good for immediate reaction. However, you should always assume you will miss some block notifications and you should independently poll the API to cover this up."

why should i assume i'll miss some block notifications? (--block-notify)

and does this mean we also cannot rely upon the rpc's --tx-notify?

azy, i guess it means that receiving software (which would react to those events) could be unavailable at some particular point (e.g.: stopped, crashed), so to cover all uncatched blocks in-between it's advicable to fetch those using API

And so it begins

haha

bigslim[m]: probably best to link a reputable website :)

Russian site?

bigslim[m]: twitter.com/DAlperovitch/status/1300797478921547776

#monero-community

Coding problem: let's say there are 3 outputs: A,B,C. You look at a transaction to determine whether each of outputs A,B,C appear in 3 distinct rings in a tx. Therefore if a tx has 3 input rings, and if we locate matches in each of the rings as [A][B][C], the result is TRUE (i.e. A was found in the first ring, B was found in the second ring, and C was found in the third ring). But if the matches located in

the rings are [A,B][C][A,C], the result is FALSE, because it's not possible that all of A,B,C could have been spent together in that tx. What's an efficient algorithm to determine if each of A,B,C appear in different rings in a tx?

therefore the goal is to get true/false depending on whether all outputs could have been spent together in a particular tx

are outputs appearing multiple times in ring members in a same transaction really that common?

artefact it's not common, but i'm looking to ensure the code is right in the rare cases

so if i'm looking to work out if three outputs are ever spent together, i don't want to get a false result because one ring contains two of them and the other ring contains the third

artefact has a good point. It means you can, eg: c=0; for r in rings: for o in r: if o in [A, B, C] ++c; if c<3 return false;

Then brute force shit algorithm for the rest, which will be run very seldom so you don't care how slow it is.

moneromooo fair enough, i can brute force the rest. i'm wondering what the best way to brute force is in that case

i could somehow generate all permutations of the matches and then check for A in the first, B in the second, and C in the third

i guess that is easiest. seems like i'm missing a trick though.

I *think* it means the number of rings with at least one member of ABC is >= 3, and all members of ABC are seen.

Nope, I got a counter example :/

haha

it's the kind of problem that seems like it should be really simple, yet isn't

I am syncing a pruned chain for the first time, at the 77% mark regular syncing messages stopped and now getting just "get_pruned_transaction_weight does not support older range proof types" ...is that normal?

Thominus: Are you sure the sync actually stopped?

You can check with the status command

Thominus: which version are you using?

It's fixed in recent code.

how come monero has so large binary size?

like few hundred megs

Debug symbols ?

Shitloads of C++ gunk :)

yanmaani: cli + daemon is ~50MB, that’s what most people need

So if you compile with -Os and strip heavily, it's smaller?

dEBRUYNE: not sure it just stopped showing progress on the "Synced" message, cpu useage dropped to nothing, data rate on my net meter also dropped , its repeating the get_pruned_transaction_weight error message only - maybe its just stopped

^^ maybe it just stopped to prune the unused portion and its going through the records getting that?

Can you type status?

That should give an overview

My monerod is 15 MB. You might have built static too.

Then wait a few minutes, type status again

Then you can see whether it is stuck

dEBRUYNE: Status: Height: 1685555/2177393 (77.4%) on mainnet, not mining, net hash 513.30 MH/s, v8, 8(out)+0(in) connections, uptime 0d 2h 59m 35s

which version are you using? :) it’s fixed in current master

but not sure when it got broken

monero-x86_64-linux-gnu-v0.16.0.3

which flags are you using?

how did you start the daemon?

started it from the shell (bash) like ./monerod --config-file=myconfigfile, the config file has paths for data-dir, log-dir, and prune-blockchain sync-pruned-blocks=1 (I thought it might be faster) and fast-block-sinc=1 (which I found out is the default anyway)

AFAIK sync-pruned-blocks is currently broken and only fixed in next release (or you compile the newest version yourself)

but moneromooo might know

In that case I can just compile from github if needed - but will my sync fail? - would be nice if I didn't have to redo it.

this is the PR

By "currently broken" you actually mean that, or you mean "it was broken until a week ago or so" ?

yes

Ah. My mistake.

current as in latest release

Which of these do you mean ?

OK.

does monero in remote node mode support blockchain reorgs?

Thominus: you can remove sync-pruned-blocks or compile from Github, note that current git master wallets are not compatible with v0.16.0.3, so if you downgrade you have to rebuild your wallet cache

I would recommend to remove sync-pruned-blocks

git master does not have updated checkpoints so sync will take ages.

thanks for the info selsta , so just to confirm before I interrupt it - is this sync toast?

I don’t think so.

You can test it by removing the option, if it continues to sync it should be fine.

I'll give that a shot then

It's not toast (or at least this partiular problem does not make it toast).

cool! - disabled sync-pruned-blocks and looks like its now resumed syncing normally - thanks very much!