00:45:20 <Lyza> <boogerlad[m]> it might be fine for nodes that are running but if it stays that high it would make it problematic for new nodes to catch up to the chain tup
00:45:23 <Lyza> tip*
03:41:38 <cryptogrampy[m]> tevador: Likely a dumb question, but is it possible to have a Jamtis merchant tier that is sort of like a subaccount that can only view payments to address it has generated, but can't view payments to the parent main wallet?
03:43:35 <cryptogrampy[m]> The use case is if you run say, a grocery store and you have access to the main wallet, and you want each cash register (PoS) to be able to generate addresses and verify payment amounts, but you don't want the registers or the cashiers running them to be able to know how much money the main wallet has received.  
03:47:08 <cryptogrampy[m]> It would be kind of a limited, account-only payment validator
03:48:35 <cryptogrampy[m]> it would also not be able to view payments to other accounts
03:51:58 <UkoeHB> cryptogrampy[m]: possible, yes; easy to do, no
03:53:10 <plowsof[m]> given a private view key and random subaddress - can you create the primary wallet address?
03:53:15 <UkoeHB> In that case you’d probably just run a payment validator hub server that the cashiers’ computers talk to on the local network
03:54:52 <UkoeHB> plowsof[m]: yes, although there isn’t really a primary wallet address
03:57:24 <plowsof[m]> just to confirm: a view only wallet (cashier see's everything) can be derived from a pvk - and sub-add (that theyre given to check blocks for outputs belonging to that address)?
03:57:30 <UkoeHB> There are a lot of things jamtis ‘could’ do (earlier versions did more than the current version), but even the current version is at a barely-manageable level of complexity
03:58:46 <cryptogrampy[m]> I'm a little biased because I'm working on an in-browser, no-server point of sale thingamahoo at the moment, so I thought I would ask.  
03:58:47 <UkoeHB> Uh if you have the view-balance key + a address in the wallet then yes you should be able to derive all the other tiers.
03:59:45 <UkoeHB> Generally if you have a view-balance key then you’ll also have the wallet base spend key, which also lets you derive the other weaker tiers
04:01:47 <UkoeHB> cryptogrampy[m]: your best bet might just be a separate wallet for each point of sale that needs a payment validator
04:02:16 <UkoeHB> Although a payment validator does need a server connection of some kind to scan for received enotes
04:02:51 <cryptogrampy[m]> UkoeHB: would definitely suffice
04:05:35 <cryptogrampy[m]> UkoeHB: Is there any proof that can be provided to an offline device that x monero amount was received to y monero address? 
04:06:00 <UkoeHB> Yeah sorry we can’t support more things. I think if it gets more complicated then it will become an ugly behemoth. Gotta strike a balance
04:07:11 <UkoeHB> cryptogrampy[m]: there is InProofV2 right now
04:09:02 <cryptogrampy[m]> UkoeHB: Oh no worries, i think the address generator level and the light wallet improvements are going to really unlock some cool integration/centralized service possibilities.  
04:11:00 <cryptogrampy[m]> UkoeHB: Can you possibly point me to where I could find more info on this? 
04:38:57 <UkoeHB> cryptogrampy[m]: uh not sure, CLI/RPC documentation maybe?
15:34:05 <reeemuru[m]> not sure if i will be able to make the next meeting... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9316ba3ad3ec5a3aded20277a91c4fc36f3552a6)
16:24:50 <Rucknium[m]> reeemuru: Very interesting. Thanks for sharing. Could you describe the end goal of this analysis? Also, what are the approximate hardware resource requirements for running this? Also could you help me Dockerize all my projects ;)
16:30:28 <reeemuru[m]> <Rucknium[m]> "reeemuru: Very interesting..." <- i was thinking this would be useful for current research on possible fingerprinting? Or maybe an opportunity to realize an optimal privacy fee. Still need to acquire more domain expertise on different wallet fee calc. Elbow method is not always correct for cluster selection some I am still reviewing the data. I am currently using ASUSTek machine with 4 cores, which is pretty old.
16:30:28 <reeemuru[m]> Only pulled about 5040 blocks to match the about transactions count that xmr-ack was using for analysis. Already it is pretty slow to display. 
16:30:28 <reeemuru[m]> > Also could you help me Dockerize all my projects ;)
16:30:28 <reeemuru[m]> Sure, np. I like doing this type of stuff. It's fun. 🤗
16:30:39 <reeemuru[m]> > <@rucknium:monero.social> reeemuru: Very interesting. Thanks for sharing. Could you describe the end goal of this analysis? Also, what are the approximate hardware resource requirements for running this? Also could you help me Dockerize all my projects ;)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6eb7f97ce1a7e02275e27d244c3082e551fd93cd)
16:31:23 <reeemuru[m]>  * i was thinking this would be useful for current research on possible fingerprinting? Or maybe an opportunity to realize an optimal privacy fee. Still need to acquire more domain expertise on different wallet fee calc. Elbow method is not always correct for cluster selection some I am still reviewing the data. I am currently using ASUSTek machine with 4 cores, which is pretty old. Only pulled about 5040 blocks to match the
16:31:23 <reeemuru[m]> amount transactions count that xmr-ack was using for analysis. Already it is pretty slow to display.
16:31:23 <reeemuru[m]> > Also could you help me Dockerize all my projects ;)
16:31:23 <reeemuru[m]> Sure, np. I like doing this type of stuff. It's fun. 🤗
16:32:37 <reeemuru[m]>  * i was thinking this would be useful for current research on possible fingerprinting? Or maybe an opportunity to realize an optimal privacy fee. Still need to acquire more domain expertise on different wallet fee calc. Elbow method is not always correct for cluster selection so I am still reviewing the data. I am currently using ASUSTek machine with 4 cores, which is pretty old. Only pulled about 5040 blocks to match the
16:32:38 <reeemuru[m]> amount transactions count that xmr-ack was using for analysis. Already it is pretty slow to display.
16:32:38 <reeemuru[m]> > Also could you help me Dockerize all my projects ;)
16:32:38 <reeemuru[m]> Sure, np. I like doing this type of stuff. It's fun. 🤗
16:33:03 <mj-xmr[m]> That's one positive Bro :)
16:36:00 <reeemuru[m]>  * i was thinking this would be useful for current research on possible fingerprinting? Or maybe an opportunity to realize an optimal privacy fee. Still need to acquire more domain expertise on different wallet fee calc. Elbow method is not always correct for cluster selection so I am still reviewing the data. I am currently using ASUSTek machine with 4 cores (8GB RAM), which is pretty old. Only pulled about 5040 blocks to match
16:36:00 <reeemuru[m]> the amount transactions count that xmr-ack was using for analysis. Already it is pretty slow to display.
16:36:00 <reeemuru[m]> > Also could you help me Dockerize all my projects ;)
16:36:00 <reeemuru[m]> Sure, np. I like doing this type of stuff. It's fun. 🤗
16:39:23 <Rucknium[m]> With R Shiny you can cache the plot images so it doesn't have to re-compute for each new visitor. Maybe I will submit a PR.
16:42:44 <reeemuru[m]> Ah that will be dope. Also, I was thinking to replace typescript with lmdb++ since it will be faster but I was struggling to re-write that library 😪
16:42:44 <reeemuru[m]> maybe later
17:08:14 <xmr-ack[m]> I've been thinking of ways to direct more talent in the data science community to look at Monero. What reeemuru  is doing with analitiko, I feel, is really important for Monero. The more we can learn from the data accessible on-chain, the more heuristics we can eliminate. 
17:09:10 <xmr-ack[m]> s/for Monero//
17:10:44 <xmr-ack[m]> We are in a fight where adversaries are using our own data against us, we need to understand what they can learn. 
19:04:36 <UkoeHB> I wonder... is there an advantage to more than 1 significant digit in tx fees? I'd really like to minimize fee-based fingerprinting/timing analysis as much as possible.
19:06:14 <UkoeHB> we could even add rounding to tx weights to make it more opaque
19:06:47 <moneromooo> tx weights are public.
19:07:10 <UkoeHB> I mean rounding tx weights for deciding what fee to use
19:14:33 <UkoeHB> If fees are very low granularity, then when you see a tx with a certain fee, there will be many 'regions' of past chain states that would tell you to use that fee. That might be enough to obfuscate when a seraphis tx proposal is constructed (in combination with delaying membership proofs), even for stuff like multisig/swaps/etc. where it can take an arbitrary amount of time to go from tx proposal to submitting a full 
19:14:33 <UkoeHB> tx.
19:16:16 <UkoeHB> maybe ArticMine has an opinion ^
19:17:41 <merope> I remember a talk/presentation by someone in Monero looking at tx fee levels and "anonimity puddles"
19:18:03 <UkoeHB> yeah isthmus did one a couple/few years ago
19:19:15 <merope> And they were suggesting implementing coarser/discrete fee levels at the protocol level, thus reducing the fingerprinting effect of fees
19:21:01 <UkoeHB> this one https://www.youtube.com/watch?v=XIrqyxU3k5Q
19:21:13 <UkoeHB> worth a rewatch I think
20:03:54 <UkoeHB> Hmm a single bit position would certainly be easier to implement, and would give more consistent gradations between fees (with a single digit you’d have 8->9->10->20). I guess the only objections would be: 1) you cant as easily change the level of precision (can easily add/remove significant digits), 2) fee amounts would be more opaque to users (a lot more dust, no manual entry).
20:38:27 <Rucknium[m]> UkoeHB: Overall I think it would increase tx uniformity and therefore would be a good idea. My only concern is the discretization of fees could lead to troublesome oscillations and spikes when the block size tx fee penalty is touched and a fee market emerges. This is only a hunch and not really based on much, so my concern might amount to nothing.
20:40:33 <UkoeHB> Rucknium[m] what kind of oscillations?
20:41:20 <Rucknium[m]> For example, imagine the market rate to get a tx confirmed goes from 1 unit to 2 (If I understand the proposal correctly). That's a doubling of fees. This would happen if most wallets are sending 1-unit fees, tx volume rises, and the mempool stops clearing with every block. Wallet software would then bid up the fee to 2 units....
20:42:46 <Rucknium[m]> And let's say that there are some wallets out there that see the fee doubling -- they see a sudden spike and then want to ensure that the tx gets confirmed in the next block, so they submit txs with a fee unit of 3. Of course I'm simplifying here since I'm not dealing with tx size, which varies
20:43:29 <Rucknium[m]> Then there is a "bubble" in tx fees, and eventually the bubble crashes. That would be the oscillation.
20:44:54 <Rucknium[m]> I quickly looked and there are several papers about auctions when the bid is forced to be discrete rather than continuous. I don't have time to look through them now, though. Or rather it's probably not a priority.
21:15:22 <UkoeHB> It seems pretty natural for there to be oscillations in a fee market, as a function of current tx volume. There would only be weird behavior if wallets auto-bid in ways inconsistent with user expectations (eg they are willing to pay up to 0.01 xmr for <10min delay, up to 0.015 for <20min delay, etc. but the wallet just thinks ‘this user wants <10min delay, bid infinitely’). Or if wallets are unable to accurately 
21:15:22 <UkoeHB> estimate current fees and tx volume, so they bid fees that are higher than necessary to satisfy the user’s delay expectation.
21:18:36 <UkoeHB> I do think the current fee priority system makes it difficult to express user delay/cost expectations around fees. What does ‘normal priority’ mean? What does ‘automatic’ mean?
21:23:43 <UkoeHB> I feel like it would be better UX if users could look at potential delay/cost pairings and choose one.
21:25:24 <UkoeHB> And instead of ‘priorities’, wallets just have preset delays and then they figure out approximately what fee is needed to match those delays.
21:26:34 <UkoeHB> And then we rely on low granularity fees (1 significant digit or 1 bit position) for privacy.
21:30:05 <UkoeHB> (delay would be delay between submission and first confirmation)