Is there a way to choose a specific transaction fee amount using the monero wallet cli? Right now all the only options I see is "priority" [ 1 - 4 ]

s/all//

s/all//, s/options/option/

not currently as far as I know.

by design, to improve tx uniformity

gingeropolous How are these priorities choosen across different wallets? Is there an agreed upon multiples for each of the priorities? (ex. x1, x4, x20, and x166) Or does every wallet choose these levels arbitrarily?

s/choosen/chosen/, s//-/

xmr-ack: ideally every wallet would be using this: github.com/monero-project/monero/bl…/src/wallet/wallet2.cpp#L7513-L7553

Started working on a prototype browser extension / wallet called Himitsu for quick testing of monero-wallet-rpc with React.js. I'm still learning about react myself so not really focused much on styling, and also new getting into working with Monero code. For now this project is primarily for test / development on stagenet.

release notes: github.com/hyahatiph-labs/infosec/r…ses/tag/himitsu-v0.1.0-experimental

source: github.com/hyahatiph-labs/infosec/tree/main/himitsu

nice. I wish more people were writing wrappers for monero-wallet-rpc

leave wallet-rpc running on a secure box somewhere 24/7, never have to worry about waiting to sync

hyc: thx! And connect over i2p / tor too 😎

excellent

with monero-lws your spend key doesn't have to sit exposed for what should be the same UX

"exposed" is a bit fuzzy. isn't it encrypted in memory until it's needed?

fair point. I'm not certain. but that sounds plausible and more secure than what I said

I mean, if you chose a weak wallet passphrase, it is vulnerable. so not having it all would be most secure, yes.

right, and still a vulnerable at the time of when it's used

then what would you do for spends? process them in the rpc client?

the wallet connected to the running rpc instance could be view-only right? So it is just staying synced and create unsigned tx sets? then relay that with a block explorer raw tx broadcaster over nym or hidden tunnels.

* sets? then sign offline and relay that

that's a nice use case I think. just can be a little cumbersome passing key images from offline wallet back to the rpc wallet

with monero-lws, the server perpetually scans for received tx's with just the view key (and also saves all tx's that use those received outs as ring members). when the client revisits the app, the light wallet client takes in all receives outs and plausibly spent tx's from the server, determines which are the real spends, displays balance/tx history to the user, and user can construct tx's client-side

jberman[m]: I haven't had a chance to play with lws yet. Will check it out tomorrow. Do you think this is the most optimal solution for minimizing the trade-off between ease-of-use and end-user security / privacy? Looking to research more or integrations with UI / UX.

if you split tx construction from signing you just moved where the vulnerable spendkey resides. not sure which can really be said to be safer, client or server...

If an attacker gets access to the device and gets past the password, in both cases they can pretty much do whatever they want though, no? But with the rpc server, there is still the additional vector of the spend key on the server

yeah. if the attacker is on the same box, you're probably screwed regardless

but if the attacker is coming over the network, then a simple redesign would be sufficient: have the -rpc server fork() a new process for a wallet session

then the spendkey is only in that child process's memory, and can't be accessed by any other RPC client even if there's a bug in the main code.

hyc: what would be the theoretical limit on sessions in this case? is this bound to the `max-concurrency` rpc flag?

that affects how many threads to use for multithreaded crypto processing, mainly

but I suppose it could apply to this as well

<reeemuru[m]> "I haven't had a chance to play..." <- I've put a decent amount of time into monero-lws and was hoping to put a lot more time into it because I believe the answer to that question is yea for people who run their own nodes. This convo is lending me an interesting perspective though/giving me thoughts. naturally I have a bias here

possibly after you bang -rpc into proper shape it winds up looking like -lws anyway

right now it has no real notion of sessions or logging in. it needs that.

it needs to know that a session is bound to a specific connection

etc...

hyc: right a model with a -rpc view only, and client is like a light wallet client

the background sync cache I think is a step in that direction too

This past week, I've been diving really deep into some of the light wallet client/server differences with the core code that have manifested into fingerprinting bugs, so a solution to achieve this general UX without necessarily needing to use brand new code is sorta wanting

<jberman[m]> "This past week, I've been diving..." <- do you have docs on those bugs? I will read up on it. lots of interesting research to do. need more hrs in the day 😭

nay I think I'll have PR's in the next day hopefully

jberman: sure no prob. will check back later then. take it ez mrl. have a good Sunday ☀️