01:36:28 <willshu[m]> https://github.com/monero-ecosystem/monero-javascript/issues/99
01:36:28 <willshu[m]> I tested the monero-javascript library and found the offline signing mechanism does not work when a deposit is made to a subaddress with a very large index, say 200,000. Does ledger works correctly when deposits are made to subaddresses with a very large index?
01:40:15 <selsta> willshu[m]: what lookahead did you set?
10:12:40 <moneromooo> So... it looks like for multisig, not only the whole tx creation code was rewritten, but it's actually duplicated. Only for for MS txes. WTF ?
10:13:20 <moneromooo> The construct_tx code is called for normal txes, and not at all for MS txes.
10:13:48 <moneromooo> This doubles attack surface, doubles the amonut of maintenance and changes needed later.
10:13:54 <moneromooo> That can't be right... ?
10:15:15 <moneromooo> Oh wait, no. Attack surface is the same, since the verification must have been kept, since the dameon can't tell MS from not MS. So at least that has to be unchanged.
10:54:26 <moneromooo> Or is it meant to be temporary, and the construct_tc code will be removed ?
11:13:11 <federico[m]> Hello
11:13:40 <federico[m]> Does somebody know how to predict tx size in order to calculate fees with daemon rpc (estimate fee)?
11:14:31 <federico[m]> the input counting only doesn't work and i didn't found anything that explains how to do that
11:20:51 <moneromooo> wallet2 has estimate_tx_fee.
11:21:02 <moneromooo> It's not byte exact IIRC, but close enough.
11:21:41 <federico[m]> moneromooo: where
11:21:50 <moneromooo> src/wallet/wallet2.cpp
11:22:12 <moneromooo> Ah, it's estimate_fee.
11:24:28 <federico[m]> https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L785
11:24:37 <federico[m]> well so i've to use this right?
11:25:12 <moneromooo> Yes, again it's an estimate, but a good one for the kind of txes wallet2 creates.
11:27:26 <federico[m]> 👌 thank you
11:58:59 <federico[m]> what does mixin and bulletproof means?
12:02:14 <federico[m]> and extra size
12:17:53 <federico[m]> also, does subaddress mean extra size? how they are calculated?
12:48:50 <moneromooo> mixin is ring size minus 1. bulletproofs are a type of range proof. extra size is the size of extra, a string of byts that contains, among other things, the tx pubkey.
12:49:09 <moneromooo> Subaddresses aren't directly related, but can cause more data to be added to extra.
12:49:52 <moneromooo> For current monero txes, we do not use bulletproofs anymore, but BP+.
14:07:45 <federico[m]> how can i dinamically get ring size?
14:08:45 <moneromooo> The one you ought to be using ? No direct easy way. You have to use what wallet2 does, like: if (use_fork_rules(X)) return Y; etc.
14:08:53 <federico[m]> * ring size and calculate extras?
14:09:36 <federico[m]> k while instead regarding extras?
14:09:43 <moneromooo> If you hve no ideas about htese htings, just make a tx and look at its fee.
14:12:20 <moneromooo> (and ask for it not to be relayed)
14:32:09 <jozsef[m]> After exposing wallet2:{en,de}crypt() via json wallet-rpc, does it make sense to expose them to zmq rpc? What is the goal of the zmq rpc compared to the json/http rpc?
14:34:42 <moneromooo> It was supposed to replace it, being faster (and allegedly more widespread or something like that, but I never belived that). Never happened, and nobody really maintains it since who wants to have two things that do the same thing.
14:34:55 <moneromooo> Now it's really used for pub/sub, which the JSON RPC does not have.
14:35:20 <moneromooo> Originally, JSON RPC was supposed to be gutted and made into a thin layer above the 0MQ replacement.
14:35:53 <moneromooo> So I'd say expose it there if it's useful to you, but it's probably missing years of changes.
14:36:09 <moneromooo> (I mean the 0MQ RPC is probably missing years of changes)
14:41:01 <jozsef[m]> I don't think it is necessary: I think the json rpc is enough so I can hook it up to monero-cpp. woodser do you agree?
14:43:39 <jozsef[m]> Also, what is below json rpc? Raw sockets?
14:44:03 <woodser[m]> yes json rpc at minimum given zmq hasn't been maintained. that said, I'd really like to support zmq in the libraries for better notification support. much of this is already done
14:44:06 <moneromooo> The epee networking code. That relies on boost networking. Which hopefully relies on sockets.
14:51:34 <jozsef[m]> Okay, I don't mind exposing {en/de}crypt to zmq rpc. But "better notification support" sounds like you mean it via zmq pub/sub. I don't see {en,de}crypt making sense via pub/sub, only via req/rep. 
15:11:23 <woodser[m]> ah yes
15:36:42 <woodser[m]> maybe I'm missing something. is there a way to set up a view-only wallet to only scan a subset of subaddresses?
15:43:10 <moneromooo> Erase the addresses you do not want to see from m_subaddresses.
15:43:23 <moneromooo> You'll have to add code to do this.
15:45:49 <woodser[m]> ok, so it's not supported now. wanted to make sure
15:47:30 <moneromooo> Also, you'd have to disable the auto lookead system or it'll create more addresses.
16:10:24 * r4v3r23[m] uploaded an image: (25KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/sEXMzxNRCLMyPthOiGKAGEiD/photo_2022-08-18_18-43-11.jpg >
16:10:46 <r4v3r23[m]> friend  downloaded  the GUI update and got this
16:11:24 <r4v3r23[m]> both from getmonero.org and GUI update had these dates
16:14:13 <selsta> r4v3r23[m]: yes, will be fixed with the next release
16:15:21 <selsta> the package script set the timestamp wrong, it is harmless
17:15:59 <selsta> jozsef[m]: did you solve your issue with trailing bits?
17:16:56 <jozsef[m]> Yes, I did. I needed to pad the plaintex that I was feeding to wallet2::encrypt().
17:17:46 <jozsef[m]> Also added unit tests and functional tests to exercise it.
17:25:35 <selsta> jozsef[m]: can you also bump the minor version in src/wallet/wallet_rpc_server_commands_defs.h ?
17:32:57 <jozsef[m]> Done.
17:52:00 <selsta> ok, let's wait for tests to finish
18:34:01 <woodser[m]> I'm trying to support multithreading in monero-javascript and running into an error: "A leaf routine is using a thread pool." looking at the code, I'm confused how lines like [this](https://github.com/monero-project/monero/blob/b6a029f222abada36c7bc6c65899a4ac969d7dee/src/wallet/wallet2.cpp#L2825) don't error, when threadpool.cpp [immediately
18:34:01 <woodser[m]> errors](https://github.com/monero-project/monero/blob/b6a029f222abada36c7bc6c65899a4ac969d7dee/src/common/threadpool.cpp#L85) on leaf=true, unless it's supposed to be caught and processed in error handling?
18:42:50 <woodser[m]> ah, it's checking its internal `is_leaf`, not the passed parameter :)
19:08:44 <vtnerd> moneromooo jozef[m] : there are two difficulities with merging 0mq and http-json-rpc paths
19:09:28 <vtnerd> some of the http-json uses REST, which will work over 0mq, but its a bit more custom (basically a `path_name:{json_object}` ... which isn't really a blocker
19:10:58 <vtnerd> the other issue is that some of the endpoint apis would have to be broken, likely in 0mq
19:10:59 <vtnerd> the information is often duplicated, but not that exact DOM structure
19:21:19 <selsta> vtnerd: https://github.com/monero-project/monero/pull/8423#discussion_r946976184
19:21:48 <selsta> "Dandelion++ is not used over the AN, but the remote service receiving the tx over an AN is expected to use it after a randomized delay" <-- quite sure this gets skipped when disable_noise is enabled
19:22:26 <selsta> disable_noise does more than just disable noise
19:25:03 <selsta> transactions sent with disable_noise always show up next to instantly in the mempool, there is no D++ involved
19:27:37 <selsta> it seems documented here https://github.com/monero-project/monero/pull/6354#pullrequestreview-399554356
19:28:41 <vtnerd> hmm. I thought I added code to have a randomized delay when switching between overlay networks
19:28:48 <vtnerd> will have to double check that hten
19:29:00 <selsta> see the last link
19:29:46 <vtnerd> ah yeah I see, damn and I even wrote the code
19:30:13 <vtnerd> I think the problem was the confusion the delay could cause, but I dunno in hindsight
19:30:51 <selsta> I only remember this since there were a lot of sybil nodes initially when D++ was introduced and using disable_noise was the only was to get fast transaction times
19:31:03 <vtnerd> oh yeah right it makes no sense
19:32:54 <vtnerd> in the standard threat model tor is hiding the source. so delaying adds nothing. in the paranoid threat model (a "big" actor monitoring timing analysis) an immediate tx-send after receiving the usual tx is a dead give-away
19:33:22 <vtnerd> *usual tx->tx sent in the "noise" window
19:35:20 <vtnerd> or no wait, it skips D++ too? ah damn
19:35:39 <vtnerd> yeah again, it makes sense because tor is doing the entire leg of work in that less paranoid situation
19:35:47 <selsta> yep it skips d++ too on the clearnet side
19:37:01 <vtnerd> hmm. then I will have to post another comment about that section because its written fairly well then. Also shocking that I dont remember how my own code worked, especially since I still agree with the result
19:37:16 <selsta> seems to have been a last minute change
19:37:28 <selsta> going by the comment
19:39:42 <vtnerd> correct, it wasn't initially coded that way. I think someone asked about it, and then I realized it was kind of pointless given the standard usage of tor
19:40:21 <vtnerd> if you trust the onion overlay network, its just slowing things down (delay AND d++)
19:41:02 <jozsef[m]> So with a zmq layer rpc woukd be faster? Or what is the main rationale?
19:42:04 <vtnerd> jozef[m]:  yeah in theory it should process faster because the 0mq is faster binary protocol to process than http
19:42:27 <vtnerd> but things are probably dominated by json processing time, so Im not sure of the % difference unless msgpack (or similar) is used
19:43:33 <vtnerd> the http parser in monerod probably isn't the most optimized either. but even ignoring that...
19:48:58 <jozsef[m]> Is there a high-level doc on the various networking types and protocols used and what their main use by all the tools? E.g. dameon, wallet, req/rep, pub/sub, ...
20:21:49 <vtnerd> if `docs/...` doesn't have what you want, then no
20:22:38 <selsta> vtnerd: last question, "Dandelion++ sending on the hidden service side (immediate flood/fluff)" shouldn't this say on the clearnet side?
20:23:41 <vtnerd> guess it wasn't clear, upated comment
20:23:57 <selsta> from hidden service side to clearnet
20:24:24 <selsta> ok yes it is more clear now, otherwise some might think we do d++ over tor