00:01:08 -xmr-pr- xiphon opened pull request #6892: core_rpc_server: on_send_raw_tx - fix bootstrap daemon mode check
00:01:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6892
00:01:09 -xmr-pr- xiphon opened pull request #6891: core_rpc_server: on_get_blocks - forward bootstrap daemon error
00:01:09 -xmr-pr- > https://github.com/monero-project/monero/pull/6891
00:16:08 -xmr-pr- xiphon opened pull request #6893: [release-v0.17] core_rpc_server: on_get_blocks - forward bootstrap dae...
00:16:09 -xmr-pr- > https://github.com/monero-project/monero/pull/6893
00:31:19 <selsta> luigi1111w: could you merge 6868 now so that we avoid merge conflict later?
01:14:26 <selsta> grydz: we will release v0.17.1.0 relatively soon, please update the ledger app to support both v0.17.0.0 and v0.17.1.0
01:15:08 <selsta> the release contains only bug fixes, no ledger specific testing is required
01:21:52 <luigi1111w> yes
01:26:42 <selsta> hyc: please rebase 6887
01:27:29 <selsta> .merge+ 6893
01:27:29 <xmr-pr> Added
09:58:49 <xnbya> Hi, I've submitted a bugfix in pr #6894, hopefully theres time to include it in the next release
09:59:17 <selsta> still time if it gets reviewed
09:59:36 <selsta> please PR also against master if necessary
10:01:08 -xmr-pr- xnbya opened pull request #6894: [release-v0.17] core_rpc_server: getblocktemplate - fix next_seed_heig...
10:01:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6894
10:09:07 <xnbya> ok thanks
10:16:08 -xmr-pr- xnbya opened pull request #6895: core_rpc_server: getblocktemplate - fix next_seed_height
10:16:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6895
11:28:56 <selsta> Seeing that I don’t have a way to contact anyone at Ledger I guess we are forced to use v0.17.0.2...
12:49:53 <binaryFate> selsta: someone must have a way to reach somebody at ledger?
13:17:26 <selsta> hyc: please rebase https://github.com/monero-project/monero/pull/6887 we plan to tag in a couple hours
13:17:51 <dEBRUYNE> We could PM their CTO on Reddit I suppose
13:17:53 <dEBRUYNE> He is quite active there
13:18:10 <selsta> doubt he will reply in 1-2 hours
13:18:52 <dEBRUYNE> Well, last comment was a few hours ago -> https://www.reddit.com/user/btchip
13:20:37 <hyc> ok looking
13:23:55 <hyc> selsta: rebased
13:24:02 <selsta> thanks
13:35:49 <selsta> .merges
13:35:49 -xmr-pr- 6808 6822 6828 6833 6869 6870 6880 6883 6884 6887 6893
13:36:27 <selsta> .merge+ 6894
13:36:27 <xmr-pr> Added
13:56:59 <grydz> selsta, indeed we'll do that!
13:57:11 <grydz> Do you plan to release CLI and GUI at the same time?
13:57:27 <selsta> yes, both tomorrow if everything works well :)
13:58:12 <selsta> all from Ledger side that has to be done is add support for both v0.17.0 and 0.17.1 here: https://github.com/LedgerHQ/app-monero/blob/master/src/monero_init.c#L182
13:59:26 <grydz> Sure.
14:00:29 <moneromooo> Does anyone here have a machine that can mine randomx with a large number of threads that's tuned ? I have a patch which might affect performance with lots of threads and I want to know if it does.
14:01:10 <selsta> sech1: ^ ?
14:02:12 <moneromooo> https://paste.debian.net/hidden/447d356d/ is the patch
14:05:31 <Inge-> does mining with xmrig count?
14:07:29 <sech1> that shouldn't affect performance much
14:08:08 <moneromooo> No, monerod only.
14:09:18 <grydz> We'll release version 1.7.4 of the app before tomorrow: https://github.com/LedgerHQ/app-monero/pull/88
14:11:35 <selsta> awesoe thank you :)
14:11:37 <selsta> awesome*
14:14:41 <selsta> We need a review for 6888 and 6889, then we can tag v0.17.1.0
14:26:34 <selsta> .merge+ 6888 6889
14:26:34 <xmr-pr> Added
14:26:51 <Inge-> Quick q: if 0.17.1.0 is a monerod update, is it a correct assumption that it should be fine to run 0.17.0.x + Ledger monero app 1.7.3 until next major release?
14:30:31 <selsta> not sure what monerod update means
14:30:49 <selsta> v0.17.0.x + Ledger 1.7.3 is fine until the next network upgrade, yes
14:31:00 <selsta> but I would recommend updating as there are multiple wallet fixes too
15:02:20 <selsta> .merges
15:02:20 -xmr-pr- 6808 6822 6828 6833 6869 6870 6880 6883 6884 6887 6888 6889 6893 6894
15:02:49 <selsta> luigi1111w: we would be ready to merge and tag now
15:09:23 <Inge-> selsta: ack
15:24:51 <luigi1111w> yup
15:55:42 <luigi1111w> what is the effect of 6894?
15:58:47 <moneromooo> AFAIK it allows miners to start setting up the next dataset while still mining on the old one.
16:01:00 <selsta> I assume rw lock stuff is not necessary for this release?
16:01:08 -xmr-pr- moneromooo-monero opened pull request #6896: crypto: add a rw lock to rx_slow_hash for robustness
16:01:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6896
16:01:19 <moneromooo> Not necessary.
16:01:21 <luigi1111w> so the effect of it missing is just an optimization thing?
16:01:32 <moneromooo> AFAIK yes, it is just that.
16:01:44 <moneromooo> xnbya: is that what you use this for ?
16:02:49 <selsta> luigi1111w: looks like we are good to tag
16:03:27 <luigi1111w> does moneromooo double confirm?
16:04:12 <selsta> (v0.17.1.0)
16:05:54 <moneromooo> I think so
16:19:21 <aubergine> Hi everyone
16:19:39 <aubergine> monero php integration no longer works after the recent fork. What has changed?
16:19:40 <moneromooo> hi
16:19:40 <aubergine> https://github.com/monero-integrations/monerophp
16:19:46 <moneromooo> CLSAG probably.
16:19:58 <moneromooo> SerHack: ^
16:20:09 <aubergine> mmm what does CLSAG mean?
16:20:19 <aubergine> the curl RPC call?
16:20:45 <moneromooo> Exact meaning doens't matter, it's a change to the signatures.
16:20:55 <moneromooo> Do you have any error message ?
16:21:36 <aubergine> yes
16:21:37 <aubergine> Invalid response data structure
16:21:52 <aubergine> looking up in the repository this error is generated at line 112 here https://github.com/monero-integrations/monerophp/blob/master/src/jsonRPCClient.php
16:23:09 <moneromooo> Can you paste the remainder of the message on paste.debian.net ? It seems to also log the response it got.
16:24:01 <aubergine> https://paste.debian.net/1166991
16:25:25 <moneromooo> CLSAG changes should not have caused that.
16:25:57 <moneromooo> Do you know how to log pMethod/pParams ?
16:26:21 <moneromooo> Oh, looks like it logs request, which should be that.
16:26:23 <aubergine> no but I saw a debug function within the code
16:26:44 <moneromooo> So switch to debug, and paste the request please.
16:26:49 <aubergine> I'm pretty sure something has changed, such error has never appeared in two months
16:26:50 <luigi1111w> like that?
16:26:51 <luigi1111w> selsta
16:27:07 <selsta> yay
16:27:17 <selsta> now we also have to do gui
16:28:40 <SerHack> Aubergine: Thanks. I'll look for that tonight
16:31:14 <aubergine> SerHack ok ping me if you need help
16:51:51 <selsta> iDunk: hyc: TheCharlatan: scoobybejesus: v0.17.1.0 is tagged
16:52:05 <selsta> (reproducible builds), and whoever else wants to participate
16:52:41 <xnbya> moneromooo: yes the next_seed_hash is used to set up the next dataset for share verification
16:54:23 <xnbya> and its also sent to pool miners, I'm unaware of any miners which currently use it tho
16:55:57 <sech1> xmrig doesn't use it
17:36:31 <hyc> xmrig doesn't even use it? ironic
17:37:04 <hyc> although I'm wondering how it would ever be an optimization - it would eat CPU & memory bandwidth to prep the next dataset in advance anyway
17:37:17 <hyc> which would hurt mining throughput while generating
17:38:42 <hyc> if no one uses it ... and it's actually of questionable usefulness, maybe better to drop it entirely
17:39:47 <dEBRUYNE> selsta: I can write something for the mailing list I guess
17:39:50 <moneromooo> I can think of a very special case. Say it takes you 2 minutes to generate the data set (extreme example of course). You connect to a pool on the last block before an epoch change.
17:39:53 <dEBRUYNE> Now that the tag has been set
17:40:08 <moneromooo> You then decide to generate the next epoch's data set and not bother wit the current one.
17:40:24 <selsta> dEBRUYNE: thanks
17:42:16 <hyc> yeah quite a rare case moneromooo
17:42:33 <moneromooo> I'm a coder. I think of these things -_-
17:42:45 <hyc> but I guess so. if any miner actually bothers to implement it
17:43:24 <gingeropolous> so whats 17.1 all about?
17:43:35 <selsta> gingeropolous: bug fixes
17:45:07 <gingeropolous> but a full decimal delimiter hop .. ?
17:45:41 <scoobybejesus> https://paste.debian.net/1166997/
17:46:22 <iDunk> https://paste.debian.net/hidden/a15ce47c/
17:55:22 <hyc> starting a build now
18:16:08 -xmr-pr- vtnerd opened pull request #6897: Add support for i2p and tor seed nodes
18:16:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6897
18:40:47 <selsta> .merge+ 6867 6863
18:40:47 <xmr-pr> Added
18:46:54 <sethsimmons> https://reddit.com/r/Monero/comments/jajm84/cli_v01710_oxygen_orion_has_been_tagged_you_may/
18:59:02 <luigi1111w> iDunk scoobybejesus is the linux 64 available to dl somewhere
19:03:15 <selsta> luigi1111w: https://gui.xmr.pm/files/cli/v0.17.1.0/monero-linux-x64-v0.17.1.0.tar.bz2
19:03:24 <luigi1111w> thx
19:42:41 <gingeropolous> ok, so with the "nodes-syncing-don't-relay-so-borks-stem" issue, is it possible for a node to check (and thus relay) a transaction even if the node doesn't have complete chain info?
19:43:05 <gingeropolous> i.e., can you validate a tx if you can only access n/11 inputs?
19:43:23 <moneromooo> If you have all the outputs if refers to, yes.
19:43:37 <moneromooo> That's assuming you're on the partial main chain though.
19:44:11 <gingeropolous> ok, so you *do* need all of the outputs it refers to
19:44:50 <gingeropolous> so if my node was 1k blocks behind, and a tx came in and 5/11 outputs i have access to, but I don't have the other 6, I can't say "well, these 5 check out, so the other 6 must be good"
19:45:00 <gingeropolous> the outputs it uses as inputs
19:47:39 <binaryFate> if you miss just one then you can't check it's not a trickery of sort
19:48:51 <binaryFate> <moneromooo> If you have all the outputs if refers to, yes. <--- conceptually yes but in practice isn't a daemon currently syncing not relying anything?
19:49:16 <moneromooo> We could implement RFC 3514 for those cases.
19:49:23 <gingeropolous> ok. i was just curious if there's some cryptohashmagic that says hash(N sub 1-5) + hash(N sub 6-11) = hash(N sub 1-11)
19:49:50 <moneromooo> When a daemon is syncing, it drops txes currently.
19:50:03 <gingeropolous> replace hash with "curve dither monomer" or whatever else it may be
19:50:10 <moneromooo> hash(N shub - niggurath)
19:50:42 <gingeropolous> shubadubdub, 3 hash in a tub
19:50:52 <selsta> comment in code says "while syncing, core will lock for a long time, so we ignore those txes"
19:52:50 <gingeropolous> i guess im curious what "while syncing" means. does that mean IBD? Or does that mean anytime a peer says "hey I have a new block", because that's technically syncing.
19:53:13 <gingeropolous> or u bring a node back online, and it needs 10 blocks.
19:53:47 <gingeropolous> cause it seems that dandelion works best with a lotta nodes
19:56:14 <gingeropolous>  --- OR - why not just let daemons relay without checking while in stem phase, and then validate in fluff?
19:56:47 <selsta> What problem are you trying to solve right now?
19:59:47 <Alex_LocalMonero> Is there a document we can look up to see the wallet RPC API changes between v0.16.0.3 and v0.17.1.0?
20:00:09 <Alex_LocalMonero> Every time there's an upgrade we have to figure out API changes by trial and error, it's quite annoying.
20:01:37 <gingeropolous> <selsta> What problem are you trying to solve right now? >>> the network not being able to utilize all available nodes as relays for dandelion routing.
20:02:13 <dEBRUYNE> Alex_LocalMonero: I suppose you could use this (partly) -> https://github.com/monero-project/monero/commits/master/src/rpc
20:02:27 <gingeropolous> i imagine the steady state of the network will be n% of always on machines, and 100-n% of machines that come and go sporadically
20:03:17 <gingeropolous> these come and go are most likely syncing-up when they come on, so they are re-integrating into the network in preparation to submit a transaction
20:04:44 <gingeropolous> but mebbe its nothing
20:10:47 <hyc> built http://paste.debian.net/1167013/
20:11:44 <hyc> matches iDunk
22:21:25 <luigi1111w> let's see how long this little box takes to sync
23:16:08 -xmr-pr- xiphon opened pull request #6898: device: Ledger - update status codes
23:16:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6898