16:52:59 <m-relay> <r​brunner7:monero.social> Meeting in a bit more than 1 hour
18:00:04 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1277
18:00:24 <m-relay> <j​effro256:monero.social> howdy
18:01:24 <m-relay> <j​berman:monero.social> *waves*
18:01:30 <m-relay> <s​needlewoods_xmr:matrix.org> hey
18:01:32 <m-relay> <h​into:monero.social> hello
18:01:40 <m-relay> <s​yntheticbird:monero.social> hi
18:02:04 <m-relay> <r​brunner7:monero.social> Ok, with the "gang" complete, on to the reports from last week!
18:02:30 <m-relay> <j​effro256:monero.social> stressnet!
18:02:49 <m-relay> <s​needlewoods_xmr:matrix.org> worked on some bugs and on `sweep_*` commands, `sweep_single` is still in progress
18:02:49 <m-relay> <s​needlewoods_xmr:matrix.org> `grep "\<m_wallet\>" src/simplewallet/simplewallet.cpp -c` gives 23 results
18:02:53 <m-relay> <s​needlewoods_xmr:matrix.org> just saw [this comment](https://github.com/seraphis-migration/monero/pull/130#issuecomment-3367470453) about estimated restore height on wallet creation today, will try to look into it this week
18:03:24 <m-relay> <r​brunner7:monero.social> One bug down, next one waiting, is the impression that I got from afar about stressnet. But that's progress of course
18:03:25 <m-relay> <s​needlewoods_xmr:matrix.org> and I have a comment and two questions, can drop the comment now and the questions at the end of the meeting if that's okay!?
18:03:33 <m-relay> <r​brunner7:monero.social> No problem
18:03:41 <m-relay> <h​into:monero.social> me: finishing an initial impl proposal for PoWER, should be ready before the next MRL meeting
18:04:01 <m-relay> <h​into:monero.social> I may as well ask this here, were there any thoughts on ZMQ? It can relay transactions as well: https://github.com/monero-project/monero/blob/8e9ab9677f90492bca3c7555a246f2a8677bd570/src/rpc/
18:04:01 <m-relay> <h​into:monero.social> daemon_handler.cpp#L104-L105
18:04:27 <m-relay> <j​berman:monero.social> me: basically exclusively stressnet + opened another daemon RPC PR from the integration to main monero repo
18:04:29 <m-relay> <j​effro256:monero.social> My personal opinion: the restore height, if off-chain, should instead be specified by a "restore date". If the wallet is doing a first-time refresh, then it can guess the height from the date, being conservative.
18:05:07 <m-relay> <o​frnxmr:monero.social> I think this estimate is likely worse on testnet
18:05:42 <m-relay> <o​frnxmr:monero.social> On mainnet, it seems to be 20k blocks in the past, which seems OK to me. But if testnet is guessing into the future, thats a problem
18:05:54 <m-relay> <r​brunner7:monero.social> Sounds reasonable, but if the API offers already a call that accepts a height, maybe we should continue to support that. Asking for a date as a single possibility if offline would be an UI issue.
18:06:26 <m-relay> <j​effro256:monero.social> Me: basically same as j-berman, working through stressnet issues, monitorying the network health through my personal node, clarifying a lot of details about the implementation of Carrot. We already opened 2 PRs amending consensus rules for the next stressnet
18:07:26 <m-relay> <j​berman:monero.social> One issue with current is that a wallet doesn't have a daemon connection at that stage of wallet creation, and so it estimates based on hardcoded values in the client
18:08:08 <m-relay> <j​berman:monero.social> I think the wallet should be able to make a daemon connection, although that's a little tricky still considering GUI's configs
18:08:31 <m-relay> <j​berman:monero.social> I think that avenue is worth investigating first
18:09:28 <m-relay> <j​effro256:monero.social> This is a good idea
18:09:35 <m-relay> <r​brunner7:monero.social> Aren't some parameter values that you may need to connect possibly in the wallet itself?
18:10:08 <m-relay> <j​berman:monero.social> Yes but I believe current flow is wallet creation before initializing the wallet with those params
18:10:49 <m-relay> <r​brunner7:monero.social> Anyway, a directed investigation will clear things up
18:12:04 <m-relay> <j​berman:monero.social> If there is a successful simple way to make the daemon connection first when setting that initial restore height with the estimate (step 1 in that PR linked above), then I think it's ok to remove that secondary check for "if it's a new wallet -> update restore height and then persist that new wallet to keys file" (i.e. no need to even do step 2)
18:12:17 <m-relay> <r​brunner7:monero.social> On the other hand, if the new PolySeeds with restore height in them become more prevalent, the urgency slowly goes down
18:12:43 <m-relay> <j​berman:monero.social> Yep
18:14:09 <m-relay> <r​brunner7:monero.social> On the third hand restoring with seed should be as foolproof as possible. Many people are already pretty stressed out probably when doing so :)
18:15:09 <m-relay> <j​berman:monero.social> If wallet is offline or cannot establish a connection to the daemon for whatever reason (and is creating a new legacy seed), I think a reasonable estimate could be to just use the latest hardcoded checkpoint
18:15:29 <m-relay> <o​frnxmr:monero.social> The latest hardcoded checkpoint might be months or even years behind
18:15:48 <m-relay> <o​frnxmr:monero.social> (Depending on when you last updated the wallet)
18:15:49 <m-relay> <s​pirobel:kernal.eu> its just one http call to get info .json daemon connection sounds so big :)
18:16:17 <m-relay> <r​brunner7:monero.social> The restore height could easily go further back than the last checkpoint? Maybe I am missing something about the general idea.
18:16:38 <m-relay> <j​berman:monero.social> this is only applicable when creating a new wallet
18:16:49 <m-relay> <r​brunner7:monero.social> Ah, I see
18:16:54 <m-relay> <o​frnxmr:monero.social> creating new wallet while offline needs to set a restore height, but if offline would need to estimate it based on some value
18:17:51 <m-relay> <o​frnxmr:monero.social> I would assume that it currently uses checkpoint time value + n days * 720 - some number to add a safezone
18:18:19 <m-relay> <o​frnxmr:monero.social> But testnet times are probably out of wack
18:18:22 <m-relay> <j​effro256:monero.social> Which is why I think storing a restore date (like Polyseed) is the best long-term solution. But if we can make a connection during wallet init to determine a real height in the chain based on date, then that could be an easy win in the short-term
18:18:27 <m-relay> <r​brunner7:monero.social> Yeah, and lacking checkpoints on testnet being off more
18:19:29 <m-relay> <j​berman:monero.social> it's using hardcoded fork v2's values lol:
18:19:29 <m-relay> <j​berman:monero.social> ```
18:19:31 <m-relay> <j​berman:monero.social> uint64_t wallet2::get_approximate_blockchain_height() const
18:19:33 <m-relay> <j​berman:monero.social> {
18:19:35 <m-relay> <j​berman:monero.social>   // time of v2 fork
18:19:37 <m-relay> <j​berman:monero.social>   const time_t fork_time = m_nettype == TESTNET ? 1448285909 : m_nettype == STAGENET ? 1520937818 : 1458748658;
18:19:39 <m-relay> <j​berman:monero.social>   // v2 fork block
18:19:41 <m-relay> <j​berman:monero.social>   const uint64_t fork_block = m_nettype == TESTNET ? 624634 : m_nettype == STAGENET ? 32000 : 1009827;
18:19:43 <m-relay> <j​berman:monero.social>   // avg seconds per block
18:19:45 <m-relay> <j​berman:monero.social>   const int seconds_per_block = DIFFICULTY_TARGET_V2;
18:19:47 <m-relay> <j​berman:monero.social>   // Calculated blockchain height
18:20:46 <m-relay> <o​frnxmr:monero.social> "so the estimation is way off. Lets not fix it tho"
18:21:12 <m-relay> <r​brunner7:monero.social> Well, the estimated numbers of blocks off are right there, no?
18:21:15 <m-relay> <j​berman:monero.social> that could use an improvement for sure. I'm ok with using latest hardcoded value + some extremely conservative estimate (e.g. assume 4 minute blocks, or give 2 weeks of leeway)
18:21:19 <m-relay> <o​frnxmr:monero.social> Gotta love the comments. At least they are helpful
18:23:12 <m-relay> <o​frnxmr:monero.social> on master, blockchain.cpp, line 2083/2084, is a FIXME that asks the qiestion about whether alt chains can have checkpoints. This `is_a_checkpoint` condition doesnt trigger when there is a reorg that comes before receiving a dns checkpoint
18:23:23 <m-relay> <s​needlewoods_xmr:matrix.org> will have to test this, but think we may could use [this](https://github.com/monero-project/monero/blob/8e9ab9677f90492bca3c7555a246f2a8677bd570/src/wallet/api/wallet_manager.cpp#L250-L258) `WalletManagerImpl::blockchainHeight()` method
18:23:25 <m-relay> <o​frnxmr:monero.social> tldr: reorg handling is broken, and this is the main blocker for dns checkpoint rollout
18:24:23 <m-relay> <o​frnxmr:monero.social> 0xfffc and i failed to fix it.. so any help ia greatly appreciated
18:25:25 <m-relay> <r​brunner7:monero.social> Is there a GitHub issue already documenting this problem, and offering a place for discussion?
18:26:12 <m-relay> <o​frnxmr:monero.social> Its on the dns checkpoint pr
18:26:22 <m-relay> <r​brunner7:monero.social> Ok
18:26:43 <m-relay> <o​frnxmr:monero.social> https://github.com/monero-project/monero/pull/10075
18:27:21 <m-relay> <r​brunner7:monero.social> By the way, does stressnet already get stressed? Is it already far enough along for spamming to start?
18:27:31 <m-relay> <o​frnxmr:monero.social> Spamming has started
18:27:50 <m-relay> <o​frnxmr:monero.social> Txpool is >100mb atm, and someone mined with a lot of hashrate,, so blocks are slow atm
18:28:11 <m-relay> <s​needlewoods_xmr:matrix.org> my node already oomed twice
18:28:17 <m-relay> <o​frnxmr:monero.social> Spackle and i have noticed some issues with block propagation and disconnects
18:28:39 <m-relay> <j​effro256:monero.social> Really? What amount of RAM is the machine running on?
18:28:53 <m-relay> <o​frnxmr:monero.social> I also think (unrelated to fcmo/stressnet) that fluffyblocks isnt working properly
18:28:54 <m-relay> <s​needlewoods_xmr:matrix.org> 8GB and 1GB swap
18:29:02 <m-relay> <j​effro256:monero.social> Myabe hitting new serialization / spam limits ?
18:29:11 <m-relay> <s​needlewoods_xmr:matrix.org> nothing in the logs though, just vanished
18:29:20 <m-relay> <j​berman:monero.social> I think this may be it
18:29:32 <m-relay> <o​frnxmr:monero.social> https://www.zerobin.net/?8bc88251cad0e881#btN+g6cdxiNCkx1ie5T6DmhpzFUne3IzKZDG1uULkaU=
18:29:46 <m-relay> <o​frnxmr:monero.social> This is what it looks like when i receive a new block
18:30:13 <m-relay> <o​frnxmr:monero.social> Connection logs here https://matrix.to/#/!sgiUzbrYPvMAvwQKTG:monero.social/$5K51MAULjli9CJ6UdXFUnM3h0R66L0ti6AHiR66om80?via=monero.social&via=matrix.org&via=xmr.mx
18:30:22 <m-relay> <j​berman:monero.social> is your node currently still stuck like that?
18:30:38 <m-relay> <o​frnxmr:monero.social> No, it syncs the block eventually
18:30:47 <m-relay> <r​brunner7:monero.social> Lol
18:30:52 <m-relay> <o​frnxmr:monero.social> Sorry, starts a couple msgs above https://matrix.to/#/!sgiUzbrYPvMAvwQKTG:monero.social/$x8jp2Lbp4hB3GW7M4Pd2SRhZd6jlW6qDLBkWsmlBTHs?via=monero.social&via=matrix.org&via=xmr.mx
18:31:45 <m-relay> <o​frnxmr:monero.social> I did _not_ have these issues on my 4 host + proxied private testnet
18:33:12 <m-relay> <r​brunner7:monero.social> Ok, with this all discussed, maybe we continue with your comments and questions, SNeedlewoods
18:33:54 <m-relay> <s​needlewoods_xmr:matrix.org> I really like the detailed output for `transfer/sweep` commands with `set print-ring-members 1`. At least the part that shows the enote pub key and enote amount.
18:33:55 <m-relay> <s​needlewoods_xmr:matrix.org> So I tested with `alpha1.1` (haven't checked the code), the setting is still present, but after setting it the output didn't change when making a tx (I assume that's because `simple_wallet::process_ring_members()` gets skipped with FCMP++s!?).
18:33:57 <m-relay> <s​needlewoods_xmr:matrix.org> Would be nice to have a wallet setting like `print-tx-enotes-in` for the FCMP++ update, which shows some enote info for inputs used in txs like `print-ring-members` does (except for the information about ring members)
18:33:59 <m-relay> <s​needlewoods_xmr:matrix.org> Example: Old output for `transfer/sweep` with `print-ring-members` set
18:34:01 <m-relay> <s​needlewoods_xmr:matrix.org> `Input 1/3 (<enote public key>): amount=0.005000000000`
18:34:38 <m-relay> <s​needlewoods_xmr:matrix.org> Question 1
18:34:39 <m-relay> <s​needlewoods_xmr:matrix.org> I considered to add `outputs=<N>` argument to `sweep_below` and `sweep_unmixable` commands. The arg is present in all the other `sweep_*` commands, but on second thought, I assume there is a bigger privacy concern for `sweep_unmixable` e.g. if someone uses this exotic method the resulting tx will already stick out on the blockchain AFAIU. On the other hand merging enotes that were<clipped 
18:34:41 <m-relay> <s​needlewoods_xmr:matrix.org>  split before is always a privacy concern, don't know if it would be worse in this case. So any opinions on adding `outputs` arg to `sweep_below` or `sweep_unmixable`?
18:35:08 <m-relay> <s​needlewoods_xmr:matrix.org> Question 2
18:35:09 <m-relay> <s​needlewoods_xmr:matrix.org> Noticed there is a difference on the confirmation prompt between `transfer` and `sweep_*` in the total amount shown
18:35:11 <m-relay> <s​needlewoods_xmr:matrix.org> transfer shows total sent as just the amount, fees _not_ included
18:35:13 <m-relay> <s​needlewoods_xmr:matrix.org> sweep shows total sent as amount + fee, so the actual total sent amount
18:35:15 <m-relay> <s​needlewoods_xmr:matrix.org> I think I'd leave it like that, but make it clear with new prompt messages if fees are included or excluded. Do you agree this is reasonable or any other suggestions?
18:35:17 <m-relay> <s​needlewoods_xmr:matrix.org> Old transfer: `Sending 0.004000000000.  The transaction fee is 0.000044110000`
18:35:19 <m-relay> <s​needlewoods_xmr:matrix.org> New transfer: `Sending 0.004000000000.  Excluding the transaction fee of 0.000044110000`
18:35:21 <m-relay> <s​needlewoods_xmr:matrix.org> Old sweep: `Sweeping 0.004011810000 for a total fee of 0.000102900000.`
18:35:23 <m-relay> <s​needlewoods_xmr:matrix.org> New sweep: `Sweeping 0.004011810000 including total fee of 0.000102900000.`
18:35:25 <m-relay> <s​needlewoods_xmr:matrix.org> that's it for now
18:36:34 <m-relay> <r​brunner7:monero.social> I think question 2 is easy to answer: Make things clearer / harder to mis-interpret is almost always a win, so I would go with the improved messages.
18:37:23 <m-relay> <r​brunner7:monero.social> That, and leaving the logic as-is, there may be reasons it's like that, and anyway people are used to it to function that way probably
18:38:24 <m-relay> <r​brunner7:monero.social> Will that `sweep_unmixable` command itself survive the hardfork to FCMP++?
18:38:49 <m-relay> <s​needlewoods_xmr:matrix.org> thank you for the quick feedback
18:40:01 <m-relay> <r​brunner7:monero.social> Maybe Rucknium would have input for your question 1.
18:40:35 <m-relay> <o​frnxmr:monero.social> btw Sweep_below is just an extra arg to sweep_all when using rpc
18:40:46 <m-relay> <r​brunner7:monero.social> Don't have an opinion myself right now, don't know enough.
18:41:15 <m-relay> <o​frnxmr:monero.social> So i assume sweep_below accepts the same args as sweep all, since sweep_below is itself just an arg
18:41:54 <m-relay> <o​frnxmr:monero.social> Sweep_unmixable or sweep_dust is its own endpoint, so no comment there. Never used it
18:42:21 <m-relay> <r​brunner7:monero.social> Being conservative and not, or at least not yet, adding new things beyond the immediate migration to the Wallet API could be a thing, the job being already quite big without any improvements ...
18:42:56 <m-relay> <r​brunner7:monero.social> I know the temptation well however, as you are already there, and seeing things clearly, why not ... :)
18:43:44 <m-relay> <j​effro256:monero.social> If you're talking about adding a new API endpoint for sweep unmixable to the wallet API, I'd personally just keep the current API in wallet2: no arguments, you get what you get
18:45:26 <m-relay> <r​brunner7:monero.social> Alright, anything else left for today's meeting?
18:45:46 <m-relay> <b​oog900:monero.social> should this ever be exposed publicly ?
18:46:08 <m-relay> <b​oog900:monero.social> or is it like the restricted RPC interface
18:47:25 <m-relay> <b​oog900:monero.social> some of the methods look to expose sensitive data like `get_peer_list`
18:47:28 <m-relay> <j​effro256:monero.social> This is existing right? Not with the FCMP++ code ?
18:49:07 <m-relay> <s​needlewoods_xmr:matrix.org> this part https://github.com/monero-project/monero/blob/8e9ab9677f90492bca3c7555a246f2a8677bd570/src/wallet/api/wallet.cpp#L1697-L1705 already handles sweeps, so if we add optional argument `std::string key_image = ""` we could also call `m_wallet.create_transaction_single()`, no new function needed
18:49:29 <m-relay> <h​into:monero.social> I'd guess on interfaces that are (or are supposed to be) for trusted internal use, PoW checks get skipped?
18:49:40 <m-relay> <s​needlewoods_xmr:matrix.org> yes questions are related to my current work on CLI, only first comment is related to FCMP++
18:50:06 <m-relay> <b​oog900:monero.social> yeah
18:50:56 <m-relay> <j​effro256:monero.social> Oh I see. I think that I would simply keep it as-is
18:51:36 <m-relay> <s​needlewoods_xmr:matrix.org> jeffro you saw this ^? if sweep_unmixable wont make it to FCMP then I agree there is no need to add it to Wallet API now
18:52:32 <m-relay> <j​effro256:monero.social> Oh yeah, unmixable sweep will be useless after FCMP++ since A) FCMP++ transactions can spend "unmixable" pre-RingCT outputs, and B) v1 transactions are banned after hard fork v17
18:52:57 <m-relay> <s​needlewoods_xmr:matrix.org> awesome
18:52:58 <m-relay> <b​oog900:monero.social> FWIW I don't _know_ if the ZMQ RPC interface is supposed to be just internal or not
18:53:09 <m-relay> <s​needlewoods_xmr:matrix.org> rbrunner may end the meeting now :)
18:53:22 <m-relay> <r​ucknium:monero.social> SNeedlewoods: Unmixables are an extremely small share of txs today.
18:54:14 <m-relay> <r​brunner7:monero.social> Alright :) Feel free to use the room for further detail discussions of course. Thanks everybody for attending, read you again next week!
18:54:35 <m-relay> <s​needlewoods_xmr:matrix.org> thanks everyone!
18:54:43 <m-relay> <s​yntheticbird:monero.social> thanks delicious meeting
18:58:11 <m-relay> <s​needlewoods_xmr:matrix.org> and I'll leave `sweep_below` for now, but keep it in my notes that we could add an `outputs=<N>` argument to it later
18:58:21 <m-relay> <o​frnxmr:monero.social> sneedlewoods
18:58:38 <m-relay> <o​frnxmr:monero.social> Does that work on the existing rpc?
18:59:04 <m-relay> <o​frnxmr:monero.social> I dont know why sweep_below has its own command in cli, but it an arg on rpc. Maybe cli is just a shortcut?
18:59:17 <m-relay> <j​effro256:monero.social> Yeah it makes sense to consolidate that. Although I would argue for both to have it listed like a receipt: sub-total (sum of amounts in outputs), fee, total (outputs  + fee)
18:59:49 <m-relay> <s​needlewoods_xmr:matrix.org> I don't know about RPC, but in the CLI they call the same underlying `sweep_main()` method, though they handle their arguments independently AFAICT
18:59:49 <m-relay> <o​frnxmr:monero.social> https://docs.getmonero.org/rpc-library/wallet-rpc/#sweep_all
19:00:04 <m-relay> <o​frnxmr:monero.social> "below_amount - unsigned int; (Optional) Include outputs below this amount."
19:00:18 <m-relay> <s​needlewoods_xmr:matrix.org> https://github.com/monero-project/monero/blob/8e9ab9677f90492bca3c7555a246f2a8677bd570/src/simplewallet/simplewallet.cpp#L201-L204
19:00:24 <m-relay> <j​effro256:monero.social> This way, you're not relying on English language to disambiguate, you can discern which number is which total through math
19:01:39 <m-relay> <o​frnxmr:monero.social> I think its an oversight?
19:02:04 <m-relay> <s​needlewoods_xmr:matrix.org> ah wait, the underlying method does handle `output` arg for all of them https://github.com/monero-project/monero/blob/8e9ab9677f90492bca3c7555a246f2a8677bd570/src/simplewallet/simplewallet.cpp#L7033
19:02:05 <m-relay> <s​needlewoods_xmr:matrix.org> so I have to test it, maybe just wrong usage messages .... that never happened before /s
19:11:07 <m-relay> <s​needlewoods_xmr:matrix.org> @ofrnxmr you're right, the `outputs` argument already works for `sweep_below`, it's just missing from `USAGE_SWEEP_BELOW`
19:12:30 <m-relay> <o​frnxmr:monero.social> Lets revisit on 2 weeks time and decide how to move fwd with that /s :D lolol
19:12:35 <m-relay> <v​tnerd:monero.social> crap, missed meeting this week. still testing carrot integration in lws. only subaddresses+balance-key needs to be tested, spends are currently being tracked
19:12:37 <m-relay> <o​frnxmr:monero.social> Nice easy pr
19:23:06 <m-relay> <s​needlewoods_xmr:matrix.org> sorry I mixed something up here. The Wallet API already has an old method for sweep_umixable [src](https://github.com/monero-project/monero/blob/8e9ab9677f90492bca3c7555a246f2a8677bd570/src/wallet/api/wallet.cpp#L1791)
19:23:07 <m-relay> <s​needlewoods_xmr:matrix.org> The change I talked about here was in regards to `sweep_single`, for which we do not have a method in the Wallet API currently. That can be solved by adding the key image arg to `createTransactionMultDest()` instead of making a new function.