03:12:17 <xmr-ack[m]> 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 ]
03:12:23 <xmr-ack[m]> s/all//
03:12:30 <xmr-ack[m]> s/all//, s/options/option/
03:31:34 <gingeropolous[m]> not currently as far as I know. 
03:31:51 <gingeropolous[m]> by design, to improve tx uniformity
04:51:54 <xmr-ack[m]> 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?
05:39:12 <xmr-ack[m]> s/choosen/chosen/, s//-/
06:17:16 <jberman[m]> xmr-ack:  ideally every wallet would be using this: https://github.com/monero-project/monero/blob/9aab19f349433687c7aaf2c1cbc5751e5912c0aa/src/wallet/wallet2.cpp#L7513-L7553
08:27:35 <reeemuru[m]> 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.
08:27:35 <reeemuru[m]> release notes: https://github.com/hyahatiph-labs/infosec/releases/tag/himitsu-v0.1.0-experimental
08:27:35 <reeemuru[m]> source: https://github.com/hyahatiph-labs/infosec/tree/main/himitsu
08:30:09 <hyc> nice. I wish more people were writing wrappers for monero-wallet-rpc
08:31:16 <hyc> leave wallet-rpc running on a secure box somewhere 24/7, never have to worry about waiting to sync
08:31:57 <reeemuru[m]> hyc: thx! And connect over i2p / tor too 😎
08:32:06 <hyc> excellent
08:34:18 <jberman[m]> with monero-lws your spend key doesn't have to sit exposed for what should be the same UX
08:35:27 <hyc> "exposed" is a bit fuzzy. isn't it encrypted in memory until it's needed?
08:37:58 <jberman[m]> fair point. I'm not certain. but that sounds plausible and more secure than what I said
08:39:25 <hyc> I mean, if you chose a weak wallet passphrase, it is vulnerable. so not having it all would be most secure, yes.
08:40:17 <jberman[m]> right, and still a vulnerable at the time of when it's used 
08:41:13 <hyc> then what would you do for spends? process them in the rpc client?
08:44:26 <reeemuru[m]> 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.
08:44:40 <reeemuru[m]> * sets? then sign offline and relay that
08:48:21 <jberman[m]> 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
08:48:33 <jberman[m]> 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
08:53:32 <reeemuru[m]> 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.
08:54:56 <hyc> 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...
09:02:12 <jberman[m]> 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
09:07:02 <hyc> yeah. if the attacker is on the same box, you're probably screwed regardless
09:07:46 <hyc> 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
09:08:27 <hyc> 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.
09:12:34 <reeemuru[m]> hyc: what would be the theoretical limit on sessions in this case? is this bound to the `max-concurrency` rpc flag?
09:13:47 <hyc> that affects how many threads to use for multithreaded crypto processing, mainly
09:14:03 <hyc> but I suppose it could apply to this as well
09:14:13 <jberman[m]> <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
09:14:59 <hyc> possibly after you bang -rpc into proper shape it winds up looking like -lws anyway
09:15:23 <hyc> right now it has no real notion of sessions or logging in. it needs that.
09:15:39 <hyc> it needs to know that a session is bound to a specific connection
09:15:43 <hyc> etc...
09:16:11 <jberman[m]> hyc: right a model with a -rpc view only, and client is like a light wallet client
09:16:24 <jberman[m]> the background sync cache I think is a step in that direction too
09:17:09 <jberman[m]> 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
09:23:50 <reeemuru[m]> <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 😭
09:24:22 <jberman[m]> nay I think I'll have PR's in the next day hopefully
09:26:56 <reeemuru[m]> jberman: sure no prob. will check back later then. take it ez mrl. have a good Sunday ☀️