03:01:23 <Rucknium[m]> <tevador> "On a side note, the official..." <- Can't be told to RTFM if there is no manual *taps head*
03:07:10 * willyijinin[m] sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/ff4dd7989102a5e87d096deacab4d6ffdae6a78f
03:44:38 * willyijinin[m] sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/12eccffd411f7690d4f65ee467649356d1c0604e
03:44:49 <willyijinin[m]>  * ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a6aa9aeaacbf6513b8ca18f6a07c98d64ba72ac3)
07:09:30 <dEBRUYNE> tevador: https://github.com/monero-project/monero-site/pull/1448#issuecomment-964924456
11:59:24 <willyijinin[m]> Please help. To sign a transaction offiline, I follow the code from the doc: `https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md`.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7522c0ccea19ef218a0e62f5c362ac7f97c5f0c2)
12:00:50 <willyijinin[m]>  * Please help. To sign a transaction offiline, I follow the code from the doc: `https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md`.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/55688ebd4432aa1f63ed65eb5fb87983f6ca89a9)
12:01:19 <willyijinin[m]>  * Please help. To sign a transaction offiline, I follow the code from the doc: `https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md`.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/75eaebc3cce101c2f02580e731c2b594628cd5ac)
12:06:38 <willyijinin[m]>  * Please help. To sign a transaction offiline, I follow the code from the doc: `https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md`.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3ef3fa08f32bab6342ce8ed9eded02d4394d9f56)
12:29:41 <willyijinin[m]> To sign a transaction offiline, I follow the code from the doc: `https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md`.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9b53ceaa57b357e9c9162cf87344ca4dd57f66f5)
12:32:56 <willyijinin[m]>  * To sign a transaction offiline, I follow the code from the doc: `https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md`.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/eb93e70e6465803722cc4fbfb8a458d06e49b65e)
12:34:18 <Rucknium[m]> will.yijinin: Just so you know, most devs are on IRC rather than Matrix. This is what they are seeing: https://libera.monerologs.net/monero-dev/20211213
12:36:04 <willyijinin[m]> Rucknium[m]: Ok got it. I will not delete previous messages, edit them and re-post them. I feel like I have state my issue clearly.
12:36:16 <willyijinin[m]> s/Ok got it. I will not delete previous messages, edit them and re-post them. I feel like I have state my issue clearly./Ok got it. I will not delete previous messages, edit them and re-post them./
14:04:15 <moneromooo> exporting key images exports nothing if they were all already exported. It'll only export new ones since last export. So that's not necessary bad.
14:04:34 <moneromooo> Assuming that JS code you use has the same defaults.
14:05:58 <moneromooo> You may want to run the wallet with log level 2, maybe the tx isn't getting built and this should tell you why if that's the problem.
14:46:01 <hyc> cute http-wallet PR tevador. will try it out
14:48:11 <sethsimmons> How does monerod handle if you have a pruned node and remove the `--prune-blockchain` arg? Does it properly backfill missing blocks, or can it not handle that?
14:49:47 <moneromooo> It will never unprune. If you prune it once, it'll stay pruned.
14:50:05 <sethsimmons> moneromooo: Ok, even better 🙂 Thanks!
15:09:16 <hyc> ... now wondering whether we should have an --unprune option, for after you migrate to bigger storage
15:21:15 <cokiss[m]> Hi guys, is it just me or the block number stay same this last 10 minutes (at least thats how long I notice it)
15:21:44 <cokiss[m]> block 2514036 with 17 tx
15:21:47 <sethsimmons> Block time variance is always a thing, just wait.
15:21:51 <cokiss[m]> Now it just move to next block
15:22:00 <cokiss[m]> I see
15:22:18 <sethsimmons> Yeah no reason to bother devs for a 10m block 🙂
15:22:27 <cokiss[m]> k
15:30:17 <Rucknium[m]> coki.ss: The probability of waiting 10 minutes or longer for the next Monero block is 0.67%
15:30:27 <Rucknium[m]> Proof: https://gist.github.com/Rucknium/e04fc1f5e698a4f6d3ab1a52641b3dea
15:32:19 <Rucknium[m]> Since on average 720 blocks are created every day, we would expect to wait more than ten minutes for about 5 blocks per day, on average.
15:32:27 <Rucknium[m]> Nothing to be concerned about.
15:44:08 <gingeropolous> aw they're gone. this is useful as well . https://melo.tools/blocks/frequencies/
17:14:36 <crypto_grampy[m]> tevador: Can you give a little more info on your PR? https://github.com/monero-project/monero/pull/8110  What problem this solves / what kind of functionality could this allow for in the future?
17:22:45 <hyc> it provides a ui for wallet-rpc
17:23:23 <hyc> something I think it sorely needs. has needed ever since the IMO wrong decision to split wallet-rpc from wallet-cli
17:23:54 <merope> Why should that be merged into the main repo though? Wouldn't it be better to have it as a separate program? The goal of wallet-rpc is to allow other programs to connect to it, not be the final UI itself
17:24:23 <merope> Imo that just bloats wallet-rpc even further
17:24:52 <hyc> maybe so
17:25:22 <crypto_grampy[m]> So it's an http gui wallet?
17:25:33 <merope> Basically yes
17:26:04 <merope> If the goal is to have an rpc interface and a cli/gui interface for the same wallet, then the way to that would be integrating the rpc features in the core wallets
17:26:27 <hyc> which is how the wallet code was originally written
17:27:02 <merope> We already have light wallets that connect to wallet-rpc, so this is just redundant
17:28:28 <hyc> just for reference, when I was running monerodirect.com my hot wallet was running all the time with rpc for the server to use it, but I still issued cmds on the cli part to check status, balances, etc.
17:28:49 <hyc> had to write an entire CLI myself after the update that split those apart. set me back a few days.
17:29:27 <hyc> an entire rpc-based CLI, because I needed wallet-rpc to be online all the time
17:42:33 <Rucknium[m]> AFAIK wallet-rpc can only handle one open wallet at a time. Is this true? If so, is there any way to have the same functionality but run only one wallet-rpc instance? wallet-rpc can be resource-expensive to run on a VPS, so having lots of them open is not ideal.
17:46:33 <tevador> Having the HTTP wallet part of monero-wallet-rpc is more secure than an external website with CORS, for one.
17:46:47 <moneromooo> Yes, and yes (start with --wallet-dir, use open_wallet RPC)
17:48:11 <hyc> yes, wallet-rpc was only designed to be used by one client at a time
17:51:15 <crypto_grampy[m]> So if I'm running a payment gateway with some wrapper around monero-wallet-rpc, this PR gives me( the merchant ) easy internal visibility into the wallet currently in use/locked by my service?
17:52:14 <tevador> It could be made to support that scenario. Currently it's more like the GUI.
17:55:21 <tevador> Are there any other wallet frontends that use wallet rpc? I wasn't aware of any.
17:56:00 <moneromooo> You have visibility on a running daemon using utils/python-rpc/console. I use that all the time on TF, it's super useful.
17:56:20 <moneromooo> utils/python-rpc/console 18881, then, eg: wallet.get_balance()
17:56:53 <moneromooo> Those are thin python layers above raw RPC.
17:57:19 <moneromooo> Works for daemon and wallet.
17:57:37 <hyc> ah, that didn't exist at the time I was talking about
18:00:25 <hyc> just reinventing wheels. none of which would be necessary if wallet-cli and wallet-rpc were unified ...
18:01:06 <hyc> but whatever, I guess what we have now is usable
18:19:33 <rbrunner> I am aware that this PR of mine is not trivial to review. But anyway, if somebody wants to take the jump I am ready to explain further if needed: https://github.com/monero-project/monero/pull/8076
18:25:26 <merope> Oh nvm, I was thinking of https://github.com/vtnerd/monero-lws
18:26:13 <merope> But from a cursory glance, it looks like it implements its own server stuff without using wallet-rpc
18:28:18 <ga_1700[m]> what is the power of "one-off" sub-address, vs. just a sub-address, does the one-off sub address dissipate after a single TX is sent to it ?
18:28:18 <ga_1700[m]> I've asked the same in #monero:monero.social , I don't mind getting the answer there. 
18:28:48 <ga_1700[m]> * answer there, as this isn't purely dev.
18:29:52 <moneromooo> I'll review it.
18:30:43 <rbrunner> Splendid, many thanks in advance
18:30:51 <moneromooo> IIRC it was mostly because some people managed (for reasons unknown) to generate subaddresses with funky indices.
18:31:19 <moneromooo> So in order to restore those, the "normal" way would generate every index between 0 and that random index, which is impossible due to RAM usage.
18:32:30 <moneromooo> So it's just a way to generate one without having to generate all the intervening others. Subaddresses do not dissipate.
18:32:31 <ga_1700[m]> so from what I gather there's no need to use a one-off address, unless <edge case>, or is it recommended in some case ?
18:32:39 <moneromooo> The former.
19:02:32 <moneromooo> rbrunner: I commented, I did not finish the review yet though.
19:02:52 <moneromooo> I just want to ask that before continuing.
19:03:21 <moneromooo> Apologies for not thinking of this before when you discussed this (assuming it's possible).
19:10:54 <hyc> merope: yeah monero-lws is completely different
19:11:41 <rbrunner> Ok, very interesting, I will try to wrap my head around the idea with that circular queue tomorrow or the next day, today I am not up to speed anymore
19:12:36 <moneromooo> Well, the circular bit is just to avoid it growing without bound. A stack also works for understanding the idea.
19:13:28 <moneromooo> Or vector/deque.
19:17:32 <hyc> I'm concerned that that idea breaks when monerod is restarted
19:18:03 <hyc> tho maybe it's fine, since txpool is persistent
19:18:04 <moneromooo> Using time instead of a counter fixes that.
19:18:21 <hyc> yes which is why I originally suggested timestamps
19:18:25 <moneromooo> But has the duplicates issue (which is not a bug issue though).
19:18:32 <moneromooo> big*
19:19:14 <hyc> reminds me of LDAP synchronization. we use "change sequence numbers" which are timestamps + counters
19:19:21 <moneromooo> And you need to restart twice fairly fast for this to break (so the counter reaches >= what theclient last saw).
19:19:25 <hyc> to handle multiple events within the same time quantum
19:19:53 <rbrunner> I think in any case daemon restarts are not a problem: The system is simply not ready to deliver incremental info for a few minutes, that's all
19:20:07 <rbrunner> And it must be able to continue in a non-incremental way anyway
19:20:09 <moneromooo> The annoying bit here being the sizing of the conter, which usually will grow to a few, but can adversarially grow pretty large.
19:21:06 <moneromooo> Actually, we don't really care here, it's not like the list will get huge.
19:21:21 <moneromooo> So good point, best of both worlds.4
19:21:53 <moneromooo> Can also store a random cookie that gets rolled at every daemon start.
19:22:13 <hyc> yeah, that'd be ok
19:22:24 <moneromooo> Oh no, that'd rat on daemons doing clearnet+tor on the same process.
19:22:46 <hyc> cookie could be server start time
19:22:53 <moneromooo> True.
19:23:16 <rbrunner> Not sure what you mean, right now the maps that contain the necessary info for incremental mode are RAM-only.
19:23:17 <moneromooo> Then again, this RPC can probably fingerprint a daemon fairly well in the first place.
19:23:55 <rbrunner> Not sure that the fingerprinting problem got much worse, actually
19:24:18 <rbrunner> With a granularity of seconds for the queries
19:25:15 <moneromooo> It's likely txes will have a timestamp that varies a few seconds over the whole set of daemons. Not alwas in the same direction.
19:25:41 <rbrunner> Hmm, yes, but they do that already now, without my code additions, right?
19:25:51 <moneromooo> So if you have, say, 10k tx events, with random starting point, it's likely a daemon's txpool history is unique.
19:25:56 <moneromooo> Possibly :)
19:26:57 <rbrunner> Maybe my code adds a way, in some circumstances, to guess how long the daemon is running already
19:27:11 <rbrunner> as a possible additional info point
19:27:16 <hyc> is uptime privileged info?
19:27:40 <rbrunner> don't know offhand, is there a way to query that over RPC?
19:27:52 <moneromooo> Yes, start time is restricted.
19:27:58 <hyc> I suppose it would let you rule out how new a version is running, but you can already tell from rpc version
19:28:13 <moneromooo> And receive time for txes is passed even for restricted, so fingerprintability is already there.
19:30:54 <rbrunner> start_time in COMMAND_RPC_GET_INFO
20:19:36 <crypto_grampy[m]> <tevador> "Are there any other wallet..." <- https://github.com/woodser/monerowebwallet.com
20:25:50 <woodser[m]> that will use the fully client side wallet by default, and optionally switch to wallet rpc
20:53:59 <tevador> cool, although what I had in mind was a lightweight UI frontend for wallet RPC
20:55:28 <moneromooo> I think the first wallet was like that. By... jojatekok IIRC. Might have the nick wrong.
20:56:01 <moneromooo> First GUI wallet of course :D
20:57:22 <tevador> the GUI has become too sluggish for me
20:57:55 <merope> Fwiw I like the idea of a ui for wallet-rpc - I just don't think it should be part of the code of wallet-rpc itself, but a standalone application
21:00:23 <plowsof[m]> <tevador> "cool, although what I had in..." <- you accomplished your goal and we are all proud of you 🫂
22:29:11 <chaser[m]> what will go into the next Monero fork, other than rs=16?
22:30:02 <escapethe3ra[m]> @chaser https://www.monero.observer/monero-hard-fork-v15-planned-early-spring-2022/
22:31:43 <chaser[m]> escapethe3ra[m]: tyvm!
23:11:06 <dEBRUYNE> woodser[m]: Will there be a (beta) release of that project soon?