03:04:55 <Mr_Doge> !balance
03:05:10 <Mr_Doge> balance
03:05:27 <Mr_Doge> balance!
03:05:39 <Mr_Doge> god dammit how you used to do it?
03:07:53 <jwinterm> Mr_Doge, it ded
03:11:46 <Mr_Doge> wtf
03:11:47 <Mr_Doge> why
03:11:57 <Mr_Doge> a lot has changed since 2017
03:12:02 <Mr_Doge> jwinterm,
03:12:28 <niocbrrrrrr> Mr_Doge: balances are safe and will be available someday
03:13:04 <jwinterm> Mr_Doge, I dunno
03:13:10 <jwinterm> tippero is ded tho
03:13:15 <jwinterm> press F to pay respects
03:13:16 <Quotes> F
03:13:17 <niocbrrrrrr> tippero did not keep up with the protocol changes
03:13:28 <niocbrrrrrr> .seen tippero
04:02:16 <lza_menace> in what situation would I need to use "store" RPC command? https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#store
04:11:36 <kayabaNerve> lza_menace: Considering that generate_from_keys does automatically save the wallet, my guess is for hot/cold wallet management.
04:13:20 <kayabaNerve> 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.
04:13:25 <kayabaNerve> That said, I will say I'm not sure.
04:17:55 <lza_menace> thanks
04:43:15 <lza_menace> 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?
04:44:41 <lza_menace> s/access/account/
04:45:11 <louipc> each have his own encrypted wallet that is decrypted client side
04:45:24 <louipc> so server never gets direct access
04:46:16 <lza_menace> not necessarily for a web wallet
04:46:36 <louipc> but i guess person with server access could always just change the client code and log passphrases anyway lol
04:46:57 <louipc> yes for web wallet.
04:47:19 <louipc> the server can store the encrypted wallet but wouldnt have passphrase
04:47:38 <lza_menace> that's not my questino though
04:48:58 <kayabaNerve> lza_menace: Subaddress per user if you're being a custodian (payment processing/exchange)
04:49:50 <lza_menace> i don't seem to be having good success doing subaddress based
04:50:05 <lza_menace> apps that have been account per register/user ahve worked flawlessly
04:50:14 <lza_menace> now im trying subaddress based but it's buggy/weird
04:50:16 <kayabaNerve> 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
04:50:37 <kayabaNerve> Poor explanation, sorry. My comment is they're unique per user, identifiable, and extremely quick.
04:50:46 <kayabaNerve> What's the problem?
04:51:41 <kayabaNerve> 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.
04:52:11 <kayabaNerve> But without knowing more about your use case/problems, I'll really just throwing out words and random specs :P
04:55:01 <lza_menace> 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
04:55:34 <lza_menace> from an external wallet/account I'm sending funds to test to subaddresses A and B
04:56:08 <kayabaNerve> Sounds correct so far
04:56:28 <lza_menace> 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
04:56:44 <kayabaNerve> (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)
04:56:46 <lza_menace> but the issue is that eventually the funds "go missing" from a subaddress
04:57:00 <kayabaNerve> As in, they're no longer reported when you call get_transfers?
04:57:06 <lza_menace> they're still in the wallet, but in the primary account
04:57:37 <kayabaNerve> My guess is that's change
04:57:56 <kayabaNerve> Wait, nope
04:58:03 <kayabaNerve> You didn't spend the incoming deposits, right?
04:58:15 <kayabaNerve> And incoming_transfers or get_transfers?
04:58:39 <lza_menace> also, there have been a couple 0 balance transfers
04:58:54 <lza_menace> get_transfers
04:59:17 <kayabaNerve> If you use curl, does incoming_transfers (which requires specifying the index) report it correctly?
04:59:24 <kayabaNerve> Just trying to debug that aspect
04:59:36 <lza_menace> is it possible to corrupt things by opening "wallet-cli" in conjunction with "wallet-rpc"?
04:59:48 <lza_menace> RPC is running and I'm poking around in CLI (read only though)
05:00:38 <kayabaNerve> 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?
05:01:01 <kayabaNerve> I don't think it would, but it does sound questionable.
05:03:50 <lza_menace> you know what...
05:07:34 <lza_menace> if a subaddress sends funds to another subaddress of the same account it seems to not "report" things accurately
05:09:46 <lza_menace> subaddress A sent funds to subaddress B
05:10:07 <lza_menace> I see it in the "out" list of get_transfers
05:10:13 <lza_menace> but I don't see it in the "in" list
05:11:22 <lza_menace> it's also reported as "amount": 0
05:11:27 <lza_menace> in the out list
05:12:05 <lza_menace> hmm
05:12:27 <lza_menace> maybe I have a wire crossed somwhere
05:12:37 <lza_menace> will check later - thanks a ton kayabaNerve
05:25:54 <kayabaNerve> Good luck lza_menace. Sorry I couldn't help more.
07:45:38 <alexanarcho[m]> damn, the monero space video with sarang is NICE - check it out https://www.youtube.com/watch?v=w5rtd3md11g
07:45:38 <alexanarcho[m]> 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?
07:55:26 <charolastra> can't watch at work but what's with the 'monero tracing tool'?
07:55:55 <charolastra> tumbling monero when?
07:57:21 <alexanarcho[m]> he doesnt give a whole lot of details, which makes it hard to assess. also, i am not the expert on this.
11:29:14 <azy> "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."
11:29:31 <azy> why should i assume i'll miss some block notifications? (--block-notify)
11:36:07 <azy> and does this mean we also cannot rely upon the rpc's --tx-notify?
12:57:26 <Nebraskka> 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
14:55:22 <bigslim[m]> https://meduza.io/en/feature/2020/09/01/russian-hackers-leak-personal-data-of-nearly-every-voter-in-michigan-plus-a-million-more-voters-in-four-other-states
14:55:26 <bigslim[m]> And so it begins
14:58:10 <dsc_> haha
14:58:34 <dsc_> bigslim[m]: probably best to link a reputable website :)
14:59:24 <bigslim[m]> Russian site?
15:00:07 <dsc_> bigslim[m]: https://twitter.com/DAlperovitch/status/1300797478921547776
15:00:34 <dsc_> #monero-community
16:44:23 <knaccc> 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
16:44:25 <knaccc> 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?
16:52:06 <knaccc> therefore the goal is to get true/false depending on whether all outputs could have been spent together in a particular tx
16:58:55 <artefact> are outputs appearing multiple times in ring members in a same transaction really that common?
17:01:19 <knaccc> artefact it's not common, but i'm looking to ensure the code is right in the rare cases
17:02:11 <knaccc> 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
17:02:33 <moneromooo> 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;
17:02:53 <moneromooo> Then brute force shit algorithm for the rest, which will be run very seldom so you don't care how slow it is.
17:06:01 <knaccc> moneromooo fair enough, i can brute force the rest. i'm wondering what the best way to brute force is in that case
17:06:54 <knaccc> 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
17:08:56 <knaccc> i guess that is easiest. seems like i'm missing a trick though.
17:09:04 <moneromooo> I *think* it means the number of rings with at least one member of ABC is >= 3, and all members of ABC are seen.
17:10:21 <moneromooo> Nope, I got a counter example :/
17:10:26 <knaccc> haha
17:10:50 <knaccc> it's the kind of problem that seems like it should be really simple, yet isn't
19:52:59 <Thominus> 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?
19:58:33 <dEBRUYNE> Thominus: Are you sure the sync actually stopped?
19:58:39 <dEBRUYNE> You can check with the status command
19:59:22 <selsta> Thominus: which version are you using?
19:59:32 <moneromooo> It's fixed in recent code.
19:59:37 <yanmaani> how come monero has so large binary size?
19:59:39 <yanmaani> like few hundred megs
19:59:48 <moneromooo> Debug symbols ?
20:00:07 <moneromooo> Shitloads of C++ gunk :)
20:00:30 <selsta> yanmaani: cli + daemon is ~50MB, that’s what most people need
20:00:37 <yanmaani> So if you compile with -Os and strip heavily, it's smaller?
20:00:52 <Thominus> 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
20:01:52 <Thominus> ^^ maybe it just stopped to prune the unused portion and its going through the records getting that?
20:02:06 <dEBRUYNE> Can you type status?
20:02:08 <dEBRUYNE> That should give an overview
20:02:09 <moneromooo> My monerod is 15 MB. You might have built static too.
20:02:13 <dEBRUYNE> Then wait a few minutes, type status again
20:02:17 <dEBRUYNE> Then you can see whether it is stuck
20:02:32 <Thominus> 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
20:02:47 <selsta> which version are you using? :) it’s fixed in current master
20:02:51 <selsta> but not sure when it got broken
20:03:19 <Thominus> monero-x86_64-linux-gnu-v0.16.0.3
20:03:27 <selsta> which flags are you using?
20:03:35 <selsta> how did you start the daemon?
20:06:42 <Thominus>  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)
20:08:08 <selsta> AFAIK sync-pruned-blocks is currently broken and only fixed in next release (or you compile the newest version yourself)
20:08:14 <selsta> but moneromooo might know
20:09:40 <Thominus> 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.
20:10:11 <selsta> https://github.com/monero-project/monero/pull/6753
20:10:13 <selsta> this is the PR
20:10:20 <moneromooo> By "currently broken" you actually mean that, or you mean "it was broken until a week ago or so" ?
20:10:27 <selsta> yes
20:10:32 <moneromooo> Ah. My mistake.
20:10:35 <selsta> current as in latest release
20:10:36 <moneromooo> Which of these do you mean ?
20:10:38 <moneromooo> OK.
20:11:04 <yanmaani> does monero in remote node mode support blockchain reorgs?
20:11:42 <selsta> 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
20:11:59 <selsta> I would recommend to remove sync-pruned-blocks
20:12:26 <selsta> git master does not have updated checkpoints so sync will take ages.
20:16:06 <Thominus> thanks for the info selsta , so just to confirm before I interrupt it - is this sync toast?
20:16:24 <selsta> I don’t think so.
20:16:38 <selsta> You can test it by removing the option, if it continues to sync it should be fine.
20:17:06 <Thominus> I'll give that a shot then
20:17:21 <moneromooo> It's not toast (or at least this partiular problem does not make it toast).
20:22:48 <Thominus> cool! - disabled sync-pruned-blocks and looks like its now resumed syncing normally - thanks very much!