<tevador> "On a side note, the official..." <- Can't be told to RTFM if there is no manual *taps head*

* ```... (full message at libera.ems.host/_matrix/media/r0/do…aeaacbf6513b8ca18f6a07c98d64ba72ac3)

tevador: monero-project/monero-site #1448#issuecomment-964924456

Please help. To sign a transaction offiline, I follow the code from the doc: `github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md`.... (full message at libera.ems.host/_matrix/media/r0/do…0ccea19ef218a0e62f5c362ac7f97c5f0c2)

* Please help. To sign a transaction offiline, I follow the code from the doc: `github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md`.... (full message at libera.ems.host/_matrix/media/r0/do…ebd4432aa1f63ed65eb5fb87983f6ca89a9)

* Please help. To sign a transaction offiline, I follow the code from the doc: `github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md`.... (full message at libera.ems.host/_matrix/media/r0/do…bc3cce101c2f02580e731c2b594628cd5ac)

* Please help. To sign a transaction offiline, I follow the code from the doc: `github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md`.... (full message at libera.ems.host/_matrix/media/r0/do…a08f32bab6342ce8ed9eded02d4394d9f56)

To sign a transaction offiline, I follow the code from the doc: `github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md`.... (full message at libera.ems.host/_matrix/media/r0/do…eaa57b357e9c9162cf87344ca4dd57f66f5)

* To sign a transaction offiline, I follow the code from the doc: `github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md`.... (full message at libera.ems.host/_matrix/media/r0/do…70e6465803722cc4fbfb8a458d06e49b65e)

will.yijinin: Just so you know, most devs are on IRC rather than Matrix. This is what they are seeing: libera.monerologs.net/monero-dev/20211213

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.

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./

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.

Assuming that JS code you use has the same defaults.

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.

cute http-wallet PR tevador. will try it out

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?

It will never unprune. If you prune it once, it'll stay pruned.

moneromooo: Ok, even better 🙂 Thanks!

... now wondering whether we should have an --unprune option, for after you migrate to bigger storage

Hi guys, is it just me or the block number stay same this last 10 minutes (at least thats how long I notice it)

block 2514036 with 17 tx

Block time variance is always a thing, just wait.

Now it just move to next block

I see

Yeah no reason to bother devs for a 10m block 🙂

k

coki.ss: The probability of waiting 10 minutes or longer for the next Monero block is 0.67%

Proof: gist.github.com/Rucknium/e04fc1f5e698a4f6d3ab1a52641b3dea

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.

Nothing to be concerned about.

aw they're gone. this is useful as well . melo.tools/blocks/frequencies

tevador: Can you give a little more info on your PR? monero-project/monero #8110 What problem this solves / what kind of functionality could this allow for in the future?

it provides a ui for wallet-rpc

something I think it sorely needs. has needed ever since the IMO wrong decision to split wallet-rpc from wallet-cli

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

Imo that just bloats wallet-rpc even further

maybe so

So it's an http gui wallet?

Basically yes

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

which is how the wallet code was originally written

We already have light wallets that connect to wallet-rpc, so this is just redundant

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.

had to write an entire CLI myself after the update that split those apart. set me back a few days.

an entire rpc-based CLI, because I needed wallet-rpc to be online all the time

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.

Having the HTTP wallet part of monero-wallet-rpc is more secure than an external website with CORS, for one.

Yes, and yes (start with --wallet-dir, use open_wallet RPC)

yes, wallet-rpc was only designed to be used by one client at a time

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?

It could be made to support that scenario. Currently it's more like the GUI.

Are there any other wallet frontends that use wallet rpc? I wasn't aware of any.

You have visibility on a running daemon using utils/python-rpc/console. I use that all the time on TF, it's super useful.

utils/python-rpc/console 18881, then, eg: wallet.get_balance()

Those are thin python layers above raw RPC.

Works for daemon and wallet.

ah, that didn't exist at the time I was talking about

just reinventing wheels. none of which would be necessary if wallet-cli and wallet-rpc were unified ...

but whatever, I guess what we have now is usable

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: monero-project/monero #8076

Oh nvm, I was thinking of github.com/vtnerd/monero-lws

But from a cursory glance, it looks like it implements its own server stuff without using wallet-rpc

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 ?

I've asked the same in #monero:monero.social , I don't mind getting the answer there.

* answer there, as this isn't purely dev.

I'll review it.

Splendid, many thanks in advance

IIRC it was mostly because some people managed (for reasons unknown) to generate subaddresses with funky indices.

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.

So it's just a way to generate one without having to generate all the intervening others. Subaddresses do not dissipate.

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 ?

The former.

rbrunner: I commented, I did not finish the review yet though.

I just want to ask that before continuing.

Apologies for not thinking of this before when you discussed this (assuming it's possible).

merope: yeah monero-lws is completely different

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

Well, the circular bit is just to avoid it growing without bound. A stack also works for understanding the idea.

Or vector/deque.

I'm concerned that that idea breaks when monerod is restarted

tho maybe it's fine, since txpool is persistent

Using time instead of a counter fixes that.

yes which is why I originally suggested timestamps

But has the duplicates issue (which is not a bug issue though).

big*

reminds me of LDAP synchronization. we use "change sequence numbers" which are timestamps + counters

And you need to restart twice fairly fast for this to break (so the counter reaches >= what theclient last saw).

to handle multiple events within the same time quantum

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

And it must be able to continue in a non-incremental way anyway

The annoying bit here being the sizing of the conter, which usually will grow to a few, but can adversarially grow pretty large.

Actually, we don't really care here, it's not like the list will get huge.

So good point, best of both worlds.4

Can also store a random cookie that gets rolled at every daemon start.

yeah, that'd be ok

Oh no, that'd rat on daemons doing clearnet+tor on the same process.

cookie could be server start time

True.

Not sure what you mean, right now the maps that contain the necessary info for incremental mode are RAM-only.

Then again, this RPC can probably fingerprint a daemon fairly well in the first place.

Not sure that the fingerprinting problem got much worse, actually

With a granularity of seconds for the queries

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.

Hmm, yes, but they do that already now, without my code additions, right?

So if you have, say, 10k tx events, with random starting point, it's likely a daemon's txpool history is unique.

Possibly :)

Maybe my code adds a way, in some circumstances, to guess how long the daemon is running already

as a possible additional info point

is uptime privileged info?

don't know offhand, is there a way to query that over RPC?

Yes, start time is restricted.

I suppose it would let you rule out how new a version is running, but you can already tell from rpc version

And receive time for txes is passed even for restricted, so fingerprintability is already there.

start_time in COMMAND_RPC_GET_INFO

<tevador> "Are there any other wallet..." <- github.com/woodser/monerowebwallet.com

that will use the fully client side wallet by default, and optionally switch to wallet rpc

cool, although what I had in mind was a lightweight UI frontend for wallet RPC

I think the first wallet was like that. By... jojatekok IIRC. Might have the nick wrong.

First GUI wallet of course :D

the GUI has become too sluggish for me

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

<tevador> "cool, although what I had in..." <- you accomplished your goal and we are all proud of you 🫂

what will go into the next Monero fork, other than rs=16?

@chaser monero.observer/monero-hard-fork-v15-planned-early-spring-2022

escapethe3ra[m]: tyvm!

woodser[m]: Will there be a (beta) release of that project soon?