05:27:07 <kayabaNerve> Blackwolfsa You do have basepoint multiplication for a variety of curves in your first method for the purpose of verifying it's the cross-curve point from the specified scalar. It's a script shim to solve a lack of a DLEq proof, one uneeded and unflexible.
05:27:28 <kayabaNerve> I understand it isn't actually a DLEq proof yet it's on chain code replacing one, hence why nI called it that.
05:36:26 <kayabaNerve> Blackwolfsa: I did see the linked StackOevrflow for the DLEq proof. AFAICT this is completely invalid
05:36:33 <kayabaNerve> *StackOverflow, sorry.
05:37:32 <kayabaNerve> For a given X1, X2, t, s, v, "The verifier computes u and verifies v⋅G=t+u⋅X1 and v⋅H=s+u⋅X2.". Set v to 0 and have t/s be any values which cause X1/X2 to add to the identity point.
05:37:50 <kayabaNerve> Like this is based on the idea you can't subtract points. You can. It's trivial.
05:38:46 <kayabaNerve> Wait. No. I'm an idiot. t/s is committed to as part of u.
05:39:35 <kayabaNerve> ... this still shouldn't be this simple AFAIK, but I'd have to double check with someone else. 
06:22:19 <Blackwolfsa> Yeah that proof is simple, but I cant see why it should not work. Perhaps I am missing something?
06:29:27 <kayabaNerve> Blackwolfsa So I found the history of it
06:29:38 <kayabaNerve> It's Chaum Pedersen's signature algorithm from 1993
06:29:43 <kayabaNerve> The whole point (pun intended) of the discrete log equality idea is that it works across arbitrary groups, and therefore arbitrary curves, without an algebraically meaningful map between them. It opens up possibilities of atomic swaps with non-ed25519 constructions. The notation in the Cloudflare article is informal and seems (at first glance) to imply a single group structure; please correct me if this is wrong.
06:30:08 <kayabaNerve> This was sarang's comment on it when he was presented with it after announcing the work on his proof in the first place, which was actually posited by Poelstra
06:32:10 <kayabaNerve> I legitimately wouldn't trust this as it's saying Poelstra didn't know of this, despite it going around a fare bit, and sarang improperly dismissed it, without one of them confirming it's valid (though I also don't suggest bothering them, making this a questionable comment)
06:33:23 <kayabaNerve> Unless the comment is that it's for some exotic set of curves? I have no idea what those exotic qualities would be yet that theoretically means it's fine for secp/Ed25519? 
06:34:58 <kayabaNerve> TL;DR Don't know. Only one person suggested this be used across entire groups and it's a SO post with no research backing that it holds for different groups. I don't know why it wouldn't. sarang seemingly dismissed it (though they may have dismissed it based on its intent, instead of its merits), and Poelstra... no idea. I wish I could find his original positing of this proof as it may open this up but I have no idea where it'd be 
06:34:58 <kayabaNerve> and Google has nothing.
06:38:52 <Blackwolfsa> I am going to try and look at the uncompressed edwards points for the Ristretto points and Ed25519 points as used by Monero again, because if we don't need a DLEQ proof then at least for Monero swaps this whole thing is moot.
06:38:52 <Blackwolfsa> But it would still be interesting to find out if this proof is valid and if its not why not?
06:39:54 <kayabaNerve> You don't need a DLEq proof if you have on chain verification the scalar in question maps to the expected public key. That's not a flexible system and forces you to include more and more curves in your node software. You're still welcome to do it. I just don't recommend it.
06:41:01 <kayabaNerve> As for the DLEq proof you use, I'm definitely stumped and can't comment further. I recommend MRL-0010 until you find out Poelstra's/sarang's commentary against (or for) CP93 across groups. It sounds like sarang does know an edge case and I honestly couldn't comment what it is.
06:42:03 <kayabaNerve> For reference, you're currently looking at requiring 5 different curves if you want to support the XMR-BTC swap protocol across all curves which benefit from its inclusion. secp256k1, Ed25519, Ristretto, Jubjub, and whichever of Pallas/Vesta is actually used for the SpendAuthSig in ZEC
06:42:27 <kayabaNerve> OR you have an offchain library handle curve management and leave your node software untouched, also shifting computations to the swap participants and away from the network.
06:42:40 <kayabaNerve> But your decision to make ;) I just wanted to offer my advice.
06:43:11 <kayabaNerve> And if you do learn anything about CP93's cross group potential, please let me know. I'd love to learn of it
06:52:05 <kayabaNerve> Oh
06:52:16 <kayabaNerve> Blackwolfsa: Doesn't this break whenever v is naturally greater than a scalar modulus?
06:53:02 <kayabaNerve> One system will reduce it when the other won't causing v != v and the proof to fail accordingly, even if r, x, and u are < each modulus
06:55:38 <kayabaNerve> x * u should cause several reductions on its own creating a series of disparaties.
07:21:27 <Blackwolfsa> Is v not just a simple scalar?
07:22:15 <Blackwolfsa> But if the scalar size differs between curves, like 256 bit and 128 bit?
13:34:14 <andytoshi> kayabaNerve: i don't think i ever posted my proof publicly because i didn't realyl flesh it out. maybe i posted a pastebin here or something
13:34:31 <andytoshi> i definitely passed it around privately to people who i thought would fill it out and publish it 
13:34:52 <andytoshi> anyway the argument is pretty forward ... "discrete log equality" is meaningless between groups of different order, as you have noticed
13:35:02 <andytoshi> but what you can do is break the DL into its binary decomposition
13:36:00 <andytoshi> and simultaneously reconstruct the result in both groups (you will get different overflow behavior but this is fine for many usecases ... e.g. for adaptor-signature applications you can just start with a 128-bit secret and then if you reconstruct that in two different groups of order 2^255ish there's no problem)
13:36:45 <andytoshi> and so you get a proof of "equivalent" discrete log, where the "equivalence" is that the two discrete logs have the same bits when you write them as numbers
13:37:05 <andytoshi> and which isn't defined on the entirety of the larger group
13:37:30 <andytoshi> (btw i am Poelstra, i realize you only highlighted me by that name, not andytoshi)
14:56:46 <UkoeHB> Meeting 2 hrs: https://github.com/monero-project/meta/issues/637
15:23:21 <maxwellsdemon[m]> put me on for next week i cant make it today
15:24:48 <Rucknium[m]> maxwellsdemon: No problem. Take care
17:00:09 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/637
17:00:09 <UkoeHB> 1. greetings
17:00:09 <UkoeHB> hello
17:00:44 <Rucknium[m]> Meeting time! 🤩
17:00:49 <rbrunner> Hi there
17:01:09 <one-horse-wagon[> Hello
17:01:32 <jberman[m]> Howdy
17:04:11 <UkoeHB> 2. updates, what has everyone been up to the past week?
17:04:44 <Halver[m]> Hi
17:05:01 <h4sh3d> Hi
17:05:03 <SerHack> Hi
17:05:13 <UkoeHB> btw andytoshi isn't  DLP security half the number of bits? If you know the DL of your secret key is between [G, 2^128 G], won't your security only be 64 bits?
17:05:23 <rbrunner> Ha, this time I have sometimes. I ran some tests with the latest multisig PR code, as written in the issue. All successful, zero problems.
17:05:30 <rbrunner> *something
17:06:48 <UkoeHB> cool thanks rbrunner; this week I reviewed a multisig patch from wfaressuissia and got to learn all about the wonderful `export_multisig()` and `import_multisig()` functions. I feel your pain...
17:07:24 <jberman[m]> Been more rigorously re-testing "batched" wallet scanning based on UkoeHB's feedback on view tag PR (1 more small commit incoming soon, no significant changes), started reviewing multisig PR (grateful vtnerd is reviewing this, it's fairly challenging for me but I'm getting the gist of the code), started reviewing Rucknium's preliminary OSPEAD work (not much to report on that yet on my end, but looking solid)
17:07:52 <Rucknium[m]> Doing some work on mining revenue, sort of in preparation for tail emission issues. Getting feedback from jberman on my "dry run" of OSPEAD. Have decided for now to use the Akaike Information Criterion (AIC) to compare distribution families when using Maximum Likelihood Estimation (MLE). MLE visualization and results table should be posted in https://github.com/Rucknium/OSPEAD soon.
17:09:09 <Rucknium[m]> However, my Monero work is slowing since I need to pivot back to BCH work. BCH people are asking "What has BCH CashFusion Red Team been up to lately?" The answer is red-teaming Monero ;)
17:09:35 <andytoshi> UkoeHB: great question. i *think* the answer is no
17:10:01 <andytoshi> i think in a 256 bit group, the security is always the minimum of 128 and the entropy of your secret
17:10:24 <andytoshi> but i guess, there is almost certainly some way that you could choose a secret with 128 bits that'd give a boost to pollard-rho..
17:10:38 <andytoshi> i just don't think that "choose from [0, 2^128]" is such a way
17:10:52 <andytoshi> anyway i am not confident. you should not take my word on this :)
17:11:58 <andytoshi> maybe, to be sure, users should just always use 224-bit secrets, which should be fine even if they lose half their bit-security
17:12:00 <UkoeHB> I think baby step giant step would do it if you just generate the keys [0, 2^64] ( https://en.wikipedia.org/wiki/Baby-step_giant-step ).
17:12:16 <UkoeHB> > users should just always use 224-bit secrets
17:12:16 <UkoeHB> yeah I was thinking this as well
17:12:43 <andytoshi> yeah you might be right about baby-step-giant-step. i'll try to work it out
17:13:32 <UkoeHB> 254-bits*
17:14:15 <bbqcore[m]> UkoeHB: hows the seraphis POC work going? i dont see any updates in the ccs
17:15:01 <UkoeHB> thanks for the updates guys
17:15:01 <UkoeHB> 2. discussion, any topics to discuss today? I don't think there are _new_ agenda items. Maybe we can highlight tevador's seraphis address scheme idea ( https://github.com/monero-project/research-lab/issues/92#issuecomment-985018982 ).
17:15:39 <UkoeHB> bbqcore[m]: a couple weeks ago I released performance results https://github.com/monero-project/research-lab/issues/91
17:16:03 <UkoeHB> Right now I am in the 'taking a break' part of the ccs, where design decisions need to be made and I need to finish the paper.
17:16:04 <Rucknium[m]> The only new item was from maxwellsdemon , and they cannot make it to the meeting today.
17:16:24 <UkoeHB> ah
17:17:17 <UkoeHB> wow almost a month since perf results...
17:17:17 <bbqcore[m]> UkoeHB: yeah i remember seeing this now. whats next?
17:20:00 <Rucknium[m]> I want to reiterate now that if anyone want to see the OSPEAD technical specification, i.e. "Document A",  let me know and I can send it to you. I haven't posted it publicly since i want to make a somewhat laypeople-friendly version soon and I don't want two versions floating around out there in public.
17:20:58 <Rucknium[m]> It's important for interpreting https://github.com/Rucknium/OSPEAD   (and even now I am working with jberman on improving the interpretability of the dry run results there)
17:22:29 <rbrunner> "I reviewed a multisig patch from wfaressuissia" Is this public, or still hidden / connected with Hacker One?
17:23:16 <UkoeHB> Ok yeah since that report I mostly took a vacation, worked on reviewing multisig security issues, and added an efficiency section to the paper (with various other updates). Next steps, I need to finish the paper (coinstudent2048[ continues to work on/improve the security model, which is non-trivial), and I am hoping we can hone in on an address scheme and decide which seraphis variant to use. After that, I will fork my 
17:23:16 <UkoeHB> perf branch to clean up the code so I can hand it off to other developers for a potential future hard fork.
17:23:39 <UkoeHB> rbrunner: not public yet... hopefully later this week if wfaressuissia gets back to me
17:23:58 <rbrunner> Holding my breath :)
17:27:17 <rbrunner> There was talk of submitting something to some conference. Did that happen?
17:27:31 <rbrunner> I think the flood analysis, right?
17:27:37 <bbqcore[m]> UkoeHB: i only ask because the ccs proposal said 6 weeks. not rushing you, just curious as to the status and what the next steps are possibly getting seraphis into monero codebase
17:30:47 <UkoeHB> yeah, for design decisions I really need the input of other people at this point... especially people who have read and understood the paper
17:31:27 <dEBRUYNE> Think we should do a meeting dedicated to some design choices for Seraphis that have to be made 
17:31:29 <UkoeHB> Seraphis-Squashed seems promising, but relies on unusual security assumptions.
17:31:40 <Rucknium[m]> rbrunner: Yes, isthmus submitted the "Fingerprinting a Flood" paper to the Science of Blockchain conference.
17:32:37 <rbrunner> Nice!
17:32:37 <UkoeHB> dEBRUYNE: sounds good to me
17:32:37 <Rucknium[m]> I expect that we should hear a reply on acceptance within the next two weeks maybe since the conference happens late January.
17:33:22 <Rucknium[m]> What would an audit process on Seraphis look like? Who might do it and how long do these things typically take?
17:34:11 <UkoeHB> Idk the process, but it would be a very big audit since there are two new proof structures and an entire tx protocol.
17:34:31 <UkoeHB> With a whole new address scheme.
17:35:08 <one-horse-wagon[> Are there any plans to run Seraphis as a testnet first?
17:35:22 <rbrunner> Maybe a look back to the Bulletproof audits will shed some light on this, e.g. https://blog.quarkslab.com/security-audit-of-monero-bulletproofs.html
17:35:30 <UkoeHB> one-horse-wagon[: I would be amazed if it doesn't run on testnet for over a month before use.
17:35:43 <rbrunner> At least 2 different companies reviewed the code, as far as I remember
17:36:01 <rbrunner> With CCS to finance
17:36:29 <rbrunner> Yeah, running on testnet first is a must
17:36:29 <Rucknium[m]> <UkoeHB> "yeah, for design decisions I..." <- What can people like me who don't really understand cryptography do to help with feedback? "Nothing" is a valid answer :)
17:36:59 <UkoeHB> you can look at https://github.com/monero-project/research-lab/issues/92
17:37:17 <rbrunner> Well, some design decisions have UI/UX consequences, and those should be accessible to us non-cryptographers ...
17:38:10 <UkoeHB> Yes, other than address schemes the other UI/UX decision that comes to mind is whether to support collaborative funding or not.
17:38:32 <UkoeHB> And what to do about timelocks...
17:39:56 <rbrunner> Nuke them from orbit, of course
17:40:25 <UkoeHB> And, the best way to implement ring-member-references for large rings (e.g. https://github.com/monero-project/research-lab/issues/84 https://github.com/monero-project/research-lab/issues/88 ).
17:41:41 <rbrunner> This will probably keep us busy the whole 2022
17:41:42 <UkoeHB> rbrunner: I'm wondering if there is an alternative timelock scheme that could be simple but useful. It would be really helpful if the advanced users like atomic swap experts could cleanly describe what would/wouldn't be useful from timelocks.
17:42:24 <rbrunner> Would be interesting to hear, yes
17:44:35 <one-horse-wagon[> Timelocks were talked about a little before.  Few people use them.  I believe the number was about 200.  
17:44:35 <one-horse-wagon[> If you just removed the timelocks, the coins would still be there.  I wouldn't let the issue interfere with the movement toward the adoption of Seraphis.
17:45:58 <one-horse-wagon[> Timelocks are also a possible vector of attack as they stick out on the block chain.
17:46:37 <rbrunner> I think timelocks that are encrypted avoid many of these problems, but are quite costly, if I got that correctly.
17:47:05 <UkoeHB> seraphis is a tx protocol, so it would be nice to have all the tx protocol questions worked out before finalizing the design
17:47:21 <rbrunner> And it looks like atomic swaps really could take off, so users of timelocks could, in theory, be finally there
17:47:39 <UkoeHB> but, it isn't necessary; just bringing up the topic so we can make progress
17:48:12 <jberman[m]> <UkoeHB> "rbrunner: I'm wondering if there..." <- I've gotten some more feedback on that. Thomas from COMIT answered a bunch of q's I had. First off, again, current timelocks are not and wouldn't be useful for atomic swaps. Second, a timelock that prevents an output from being spendable in the chain until height N would be useful and I have to go back through the conversation to get full details on exactly how
17:49:13 <UkoeHB> > a timelock that prevents an output from being spendable in the chain until height N 
17:49:14 <UkoeHB> This is literally the timelocks we have right now.
17:49:50 <rbrunner> Well, now it's all outputs of a tx, maybe that's the difference?
17:50:21 <Rucknium[m]> Maybe it is "tx cannot be mined until block N" That's bitcoin-style time locks, right?
17:50:41 <Lyza> yeah, with btc for example you can *sign* a transaction that can't be mined until N, so the monero lock time on outputs is different
17:51:21 <jberman[m]> I miswrote, that^ is what I meant
17:51:31 <jberman[m]> like the tombstone concept you've mentioned in the past
17:52:00 <UkoeHB> Can you get that effect right now by spending an output that is timelocked?
17:52:49 <jberman[m]> No because it still allows the ability to spend the output with a separate tx
17:53:10 <UkoeHB> you mean the timelocked output?
17:53:23 <UkoeHB> so there s a race condition
17:54:12 <jberman[m]> You could collaboratively sign a tx with another party that can't be included in the chain until time N but spends output X, but before time N are still able to spend output X
17:55:31 <UkoeHB> Can't you do that with bitcoin timelocks as well? I am confused
17:56:17 <jberman[m]> This is Bitcoin's equivalent: https://en.bitcoin.it/wiki/NLockTime
17:57:22 <jberman[m]> You can't do this with Monero's timelocks today because if output X is in the chain and timelocked until time N, no one is able to spend it until time N
17:57:55 <UkoeHB> No, the idea is you make a timelocked dummy output, then spend it in your tx you want locked.
17:58:02 <andytoshi> UkoeHB: yeah, i'm pretty sure baby-step-giant-step will work just fine breaking a DL in a known range (with runtime sqrt(that range)
17:58:16 <andytoshi> thanks!! i will stop casually suggesting that 128 bit secrets are ok
17:58:25 <UkoeHB> sure :)
18:00:35 <UkoeHB> ok we are at the end of the hour, so I will call the meeting here; thanks for attending everyone
18:00:59 <Rucknium[m]> UkoeHB: I think part of the benefit of BTC-style time locks is that one party gives the signed but currently unmineable tx to another party. Then if something goes wrong, Bob can broadcast that timelocked tx to recover funds or something.
18:02:17 <hyc> which would only work if the tx includes sufficient txn fees
18:03:19 <jberman[m]> "The reason nLocktime is useful is because we can agree on a joint-output and pre-sign a TX that refunds the money after time T. Once I have this TX in my pocket, ready to use, I am happy to commit funds to a joint-output. Without this "backup" TX, I can be held hostage once I moved money into the joint-output."
18:03:19 <jberman[m]> So it seems you have to be able to move the funds into the joint-output where it is spendable with this "backup" nLocktime'd tx, or with another tx that can be created separately before the nLocktime
18:03:44 <Rucknium[m]> hyc: Yes, which is why the Lightning Network will fail. But I digress...
18:07:53 <UkoeHB> I'm pretty sure you can do that with current monero timelocks, so long as there is tx chaining available.
18:08:46 <hyc> ? current monero timelocks, the txn is mined immediately, but outputs are unusable till timer expires.
18:09:13 <UkoeHB> Using the dummy timelocked output idea. However, it would be better to switch from current timelocks to a 'spendable range' timelock: tx can be added to a block in range `[start, end]`, given the current system's flaws re: deterministic rings.
18:09:13 <hyc> you can't use that for a refund mechanism, because that would require being able to spend the same outputs twice - once in real txn and once in timelocked
18:09:53 <UkoeHB> hyc: yes, you make a timelocked tx that creates a dummy output (0 amount), then you 'spend' that dummy output in another tx, effectively locking that tx until the dummy is spendable.
18:11:04 <hyc> the 2nd txn can't be mined until the lock expires ... ?
18:11:10 <UkoeHB> right
18:12:07 <hyc> got it
18:13:27 <jberman[m]> I'm getting it too, ya I think this achieves the same effect
18:15:05 <hyc> so..... to make sure the txn will be usable when it unlocks, you might consider using higher-than-default fee. but then the txn would be fingerprintable
18:15:58 <Rucknium[m]> So the other non-dummy output is spendable at any time by creating a separate tx, which is similar to what bitcoin-style time locks do, I think.
18:19:36 <UkoeHB> I think hidden txlockranges can be done far more cheaply than hiding current timelocks. You just need 2 range proofs.
18:22:48 <UkoeHB> maybe ~5-15% increased verification cost, <100 bytes
18:27:12 <jberman[m]> It seems a little clunky in that there would be 1 extra input/ring sig in the chained tx that spends the dummy output (+ the dummy output itself), which could be avoided with an nLockTime equivalent
18:28:43 <koe000[m]> yes, I am just trying to understand why people think the current timelocks don't work
18:29:04 <jberman[m]> I think you're right in that they would work to enable the effect of nLockTime
18:29:42 <jberman[m]> the dummy output concept, like moo's subscription idea
18:40:10 <kayabaNerve> andytoshi: Yeah, I know who you are ;) I didn't want to bother you though. I'm definitely not the best cryptographer but am happy I managed to realize why this didn't work with enough time. Thanks for chiming in yourself :)
18:41:46 <andytoshi> kayabaNerve: no prob :) thanks for not pinging me. though FYI i also highlight on "poelstra" :)
18:42:52 <kayabaNerve> Ha. Definitely not my intent. Time for Poelstr_a then
18:43:33 <andytoshi> lolol, don't worry about it. i can interpret poelstra as an unintential ping and ignore it
18:44:01 <kayabaNerve> Blackwolfsa: Bit length shouldn't matter, just modulus value from my understanding. If one has a modulus of 5 and one has a modulus of 6, `v = r + u * x` = 20 will cause v to equal 0 and 2 at the same time.
18:44:53 <kayabaNerve> Hence why this shouldn't work if you even just try and get a PoC of it up.
20:34:15 <jberman[m]> <hyc> "so..... to make sure the txn..." <- To get around the increasing fee issue, bitcoin supports this thing called "child-pays-for-parent" where the recipient of the unconfirmed UTXO spends that UTXO in a new tx including a higher fee, so miners will be incentivized to mine both the parent and child tx at the same time
20:36:20 <jberman[m]> Seems possible to do but trickier. I can't see how to do this in a way that isn't finger-printable
20:39:32 <carrington[m]> Surely the ten block lock forbids this?
20:40:39 <Rucknium[m]> carrington: That's what I was thinking, too.
20:41:27 <jberman[m]> You could prevent the parent output from being used in other rings, should a child tx that spends the parent output be included in the same block (and so allow these child tx's). But this parent-child tx is finger-printable, and probably other issues with this I'm not seeing
20:43:07 <jberman[m]> I mean you can't do this today, would require a protocol change
20:44:02 <carrington[m]> Are you saying that child-pays-for-parent would have to be a consensus-level exception to the ten block lock?
20:44:14 <jberman[m]> Yea
20:44:18 <carrington[m]> Right
20:46:59 <carrington[m]> I'm not sure higher than normal fee would be needed anyway. It's not clear to me whether XMR will develop any kind of meaningful fee market because of the dynamic block size
20:48:14 <carrington[m]> Suggestions have been made to make fees less fingerprintable lowering the significant digits
20:54:22 <UkoeHB> carrington[m]: more than a suggestion, it will be wallet policy if this PR is merged: /
20:54:34 <UkoeHB> https://github.com/monero-project/monero/pull/7819
21:14:41 <carrington[m]> Not consensus though right?
21:34:39 <UkoeHB> no
23:03:47 <bbqcore[m]> has there been talk of reducing fees relative to ring size/tx size increases?
23:08:27 <UkoeHB> no
23:12:12 <carrington[m]> Why would fees be lower for larger transactions?
23:12:25 <carrington[m]> Not sure I understand the suggestion bbqcore 
23:14:54 <bbqcore[m]> carrington[m]: lowering the fee rate to account for increase in tx size
23:17:10 <Rucknium[m]> bbqcore: We had an apparent spam incident earlier this year. Slightly higher fees could help reduce the spam risk. I don't think there is much appetite for lowering fees at this time.
23:17:40 <bbqcore[m]> not lowering fees
23:18:18 <bbqcore[m]> but making larger txs cost the same as current ones 
23:22:19 <carrington[m]> From what I remember, the plan is to make fees higher in the next upgrade (ringsize 16) to reduce spam risk. I think seraphis will not substantially change the fees from that level under current estimates. Maybe that's wrong though.
23:22:57 <Rucknium[m]> The fee changes for the next hard fork are supposed to raise fees, I think:
23:22:57 <Rucknium[m]> https://github.com/monero-project/meta/issues/630
23:23:34 <Rucknium[m]> The best current estimate for the cost of the spam incident is only 5 XMR:
23:23:34 <Rucknium[m]> https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60
23:35:49 <UkoeHB> bbqcore[m]: The fee rate is based on a 'reference' tx size of 3kB. Since seraphis won't cause standard tx to exceed 3kB, it's not necessary to change the fee calculation. ArticMine[m] can tell you more