15:11:02 <UkoeHB> meeting ~2hr
15:22:54 <spacekitty420[m]> last one was like the whole hour about plowsof new position, hopefully next one will be less about that o.o
15:27:21 <UkoeHB> spacekitty420[m]: last meeting was mainly spent discussing rbrunner as 'seraphis migration admin' https://github.com/monero-project/meta/issues/748 maybe you mean a community meeting?
15:31:21 <spacekitty420[m]> right my bad, i meant rbrunner, not plowsof, the hour seemed a bit wasted on that one topic is all, all the aspects are important tho so i guess it's still better than not talk about those specifics at all
15:57:01 <one-horse-wagon[> Seraphis and Jamtis are the future of Monero.  The hour spent on it last week was far from wasted as it got the project well organized and  supported by some of the devs.   
15:58:00 <spacekitty420[m]> 100% agree, was only referring to the admin position thingy
16:02:34 <one-horse-wagon[> It was a big deal to put an administrator and thus required a bit of discussion.  Seraphis and Jamtis now has its own room on Matrix--No Wallet Left Behind--and that's where most of the discussion about it will take place.  
16:03:17 <one-horse-wagon[> * an administrator in charge and thus
16:04:53 <spacekitty420[m]> any link to the room? watched koe's youtube video recently and pretty interested to keep an eye on the development of that <3
16:06:42 <nioc> is that room bridged to IRC?
16:15:47 <one-horse-wagon[> rbrunner7will be posting an announcement of the first meeting.  
16:25:51 <UkoeHB> nioc: not bridged unless someone sets it up
16:26:21 <UkoeHB> spacekitty420[m]: https://github.com/monero-project/meta/issues/751
16:28:33 <spacekitty420[m]> UkoeHB: tenkyu <3
17:00:04 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/750
17:00:04 <UkoeHB> 1. greetings
17:00:04 <UkoeHB> hello
17:00:29 <one-horse-wagon[> Hello.
17:00:31 <SerHack> hi
17:00:34 <rbrunner> Hi
17:00:52 <Rucknium[m]> Hi
17:00:57 <dangerousfreedom> Hello
17:02:04 <plowsof> hi
17:02:46 <UkoeHB> 2. updates, what's everyone working on?
17:03:54 <rbrunner> Still busy writing issues about various aspects of the Seraphis wallet to build: https://github.com/seraphis-migration/wallet3/issues
17:04:11 <rbrunner> And of course preparing our first regular working group meeting: https://github.com/monero-project/meta/issues/751
17:04:42 <rbrunner> All interested parties welcome, and of course let the comments flow for the issues :)
17:05:14 <UkoeHB> me: completed legacy integration to seraphis multisig, legacy spending is now fully supported by the seraphis library (hurray!); also added/adding error reporting to multisig utilities so it's easier to identify problems (for UX this means it's easier to identify which signers you need to get particular messages from, for security this means identifying malicious signers in some contexts); then, on to seraphis coinbase 
17:05:14 <UkoeHB> txs which is the final piece I plan to work on
17:05:24 <plowsof>  i plan to first obtain an audit of the bp++ eprint paper. I have received 2 quotes to date.  
17:05:24 <dangerousfreedom> I'm working on opening a jamtis/seraphis wallet compatible with the wallet2. Maybe I will have something to present next week.
17:05:24 <plowsof> Quarkslab estimate around 12 days of work with a daily rate of 2’370 USD tax excluded ~$28,440 (including the deliverable edition and project management). Unavailable until Q2 2023.
17:05:25 <plowsof> CypherStack estimate the same time frame but for a total cost of $16,500 and are available to start next month. 
17:06:54 <Rucknium[m]> plowsof: How do the firms define "audit"? What tasks does it involve?
17:07:12 <UkoeHB> plowsof: did you also ask for a proof of concept implementation? https://libera.monerologs.net/monero-research-lab/20221026#c153793
17:08:11 <plowsof> Quarkslab where unable to quote for a PoC and would need to complete task 1 first to gauge how long it would take. These are estimates 
17:10:57 <plowsof> " theoretical review of your eprint paper with a focus on the security aspects"
17:12:24 <Rucknium[m]> Do you happen to know if they have any public examples? A paper and then their review of it side-by-side?
17:13:25 <plowsof> i do not, i will do more probing. theyve only just got back to me with these daily rates/estimates 
17:13:39 <UkoeHB> How about this. 1) paper review + proof of concept from CypherStack Q4 2022, 2) me: proof of concept -> full implementation Q1 2023, 3) paper review + implementation audit from Quarkslab (+ one or two more implementation audits, possibly going back to CypherStack for this) in Q2-Q4 2023.
17:15:48 <Rucknium[m]> Sounds Ok to me. Where is the original author in all of this?
17:15:50 <plowsof> i will get the wheels in motion for 1) (funding firstly) 
17:16:01 <UkoeHB> 3. discussion (updates are over)
17:17:00 <UkoeHB> Rucknium[m]: I'll contact him with our plan one it gets moving
17:17:05 <UkoeHB> once*
17:20:28 <UkoeHB> any other comments on BP++?
17:21:43 <UkoeHB> ok we can move on to jamtis address checksums: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#64-checksum
17:21:44 <one-horse-wagon[> <Rucknium[m]> "plowsof: How do the firms define..." <- Very good question that I would like to see answered also.
17:22:37 <UkoeHB> the questions with checksums are: what algorithm to use? is it good or bad to have error correction?
17:23:31 <SerHack> always good
17:23:35 <rbrunner> So that's double the number of checksum bytes compared with today
17:23:54 <rbrunner> 8 instead of 4
17:24:08 <UkoeHB> I'm a little uncertain about error correction, it seems like it might be abusable (generate an address that looks like another address but error corrects to something else).
17:24:17 <Rucknium[m]> To clarify, this would all be wallet-level, right? I assume that address checksums are not possible at the blockchain consensus level.
17:25:04 <UkoeHB> Rucknium[m]: yes for wallets
17:26:16 <rbrunner> Error correction as a base-level wallet feature also could lead to all sorts of UI/UX complications.
17:26:42 <rbrunner> Maybe have error correction, but only offering it through a special tool, to be used in "emergencies", for recovery so to say?
17:27:15 <Rucknium[m]> FWIW, here's the Bitcoin Cash recommendation on error correction: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/cashaddr.md#error-correction
17:27:31 <Rucknium[m]> "BCH codes allows for error correction. However, it is strongly advised that error correction is not done in an automatic manner as it may cause funds to be lost irrecoverably if done incorrectly. It may however be used to hint a user at a possible error."
17:27:36 <UkoeHB> I think we should avoid conditional behavior of address strings. Better to have one format that does the same thing always.
17:28:11 <UkoeHB> Rucknium[m]: that's a good recommendation
17:28:40 <UkoeHB> but you don't need error correction for that, you just need a checksum
17:28:50 <rbrunner> "conditional behavior" What do you mean with this?
17:29:39 <UkoeHB> rbrunner: I mean addresses that deserialize to different things in different settings
17:29:48 <UkoeHB> based on whether or not you error correct
17:31:02 <UkoeHB> better to just have a try_deserialize() that internally calls is_corrupted()
17:32:10 <rbrunner> Not yet sure where those arguments lead regarding UI and whether we could/should offer some "address recovery tool" or not
17:33:03 <UkoeHB> for UI you just paste an address and it tells you 'this is an invalid address [(optional) because of reason X]'
17:33:12 <dangerousfreedom> I think error correction adds a layer of possible problems that we want to avoid. A checksum should be enough to say if there is a mistake in the address and if there is the user could check the address himself. If we use error correction, there might be a case where it does not do its job and if the transfer happens the funds would be lost.
17:34:04 <one-horse-wagon[> dangerousfreedom: agree with you completely.
17:34:07 <rbrunner> Is the chance of a false alarm of a checksum algorithm significantly lower than the chance of error correction failing?
17:35:00 <UkoeHB> rbrunner: don't think so
17:35:38 <dangerousfreedom> Depends on how much bytes you want to use to ensure it I guess
17:35:47 <UkoeHB> 8 bytes means a 64bit hash, which should have negligible failure rates for non-malicious addresses
17:36:23 <rbrunner> Then I ask myself what we risk if we only permit error correction in carefully designed and very clear contexts, like a dedicated recovery tool
17:36:26 <dangerousfreedom> Is there a limitation on the address string that we want to use?
17:36:36 <dangerousfreedom> Currently we are targetting a 181 characters for normal addresses
17:36:46 <rbrunner> Maybe that some wallet dev starts to add error correction nevertheless directly to an app ...
17:36:57 <UkoeHB> rbrunner: it's only carefully designed and clear in the tools that you write
17:38:13 <rbrunner> The saying "That's we cannot have nice things come to mind". Technically, we could do better than just moaning "Wrong!", but it's risky
17:38:32 <rbrunner> *That's why we
17:39:04 <rbrunner> Annoying, in a way
17:40:40 <UkoeHB> it's interesting that tevador says "The checksum can detect all errors affecting 4 or fewer characters", so there may be some advantage to using a polynomial solution instead of a hash. This way malicious addresses that only change a few characters will be detected if you can validate the checksum. On that note the checksum should probably be ordered first in the address string so users are more likely to memorize it.
17:40:51 <Rucknium[m]> Most software companies: "If it works, ship it!" Reminds me of the thousands of Monero transactions that all use the same outputs as decoys, revealing the real spend.
17:41:27 <rbrunner> Maybe people producing errors in addresses will become a less and less realistic scenario anyway; QR codes for example checksum themselves
17:41:48 <rbrunner> And who types 181 characters?
17:45:17 <rbrunner> Is there a way to estimate how many wrong characters a hash can "detect"?
17:45:34 <UkoeHB> rbrunner: it detects 1 wrong character with the same probability as 1000
17:47:32 <rbrunner> We already have hashes implemented, right, but those polynoms would have to get added?
17:47:46 <UkoeHB> right
17:48:29 <rbrunner> Well, we have versioning now for addresses, so we could very well start with hashes and see how that goes, and if the dust settled talk again about error correctio as a possible improvement
17:49:02 <UkoeHB> agreed, it's a fairly easy piece to switch out
17:49:12 <rbrunner> "now" = "with Seraphis" of course
17:50:31 <rbrunner> I think I move towards dangerousfreedom's viewpoint: "I think error correction adds a layer of possible problems that we want to avoid."
17:50:48 <rbrunner> At least for the first version of Seraphis and Jamtis
17:51:19 <UkoeHB> "Maybe people producing errors in addresses will become a less and less realistic scenario anyway" -> I agree, manually validating a long string is just not reasonable. It's really up to the ecosystem to make address passing robust and automated.
17:51:27 <dangerousfreedom> <rbrunner> "And who types 181 characters?" <- Yeah, I think that's the point nobody will make mistakes by typing it but copying mistakes may occur. A checksum would certainly detect that and the person would need to copy again the address. With error correction on the other hand might be a bit more comfortable if you miss one character but I still dont know if it is worth the risk of having it corrected to a wrong
17:51:27 <dangerousfreedom> address. I also dont know if this assumption is valid since you have checksum + error correction and if it passes both than you can be sure that the address is correct. Now I'm confused if I generalize my thought to an address with 1000 characters for example. Maybe error correction + checksum makes sense there.
17:52:04 <moneromoooo> In what case(s) would an EC mechanism would yield an unwanted address where a checksum would not ?
17:52:21 <rbrunner> Copying errors are probably mostly "not copying all", and there no error correction helpls. E.g. you copy only 170 characters or so.
17:52:28 <UkoeHB> moneromoooo: EC mechanism?
17:52:41 <hyc> error correction
17:52:44 <moneromoooo> I mean error correction vs checksum/hash.
17:52:46 <UkoeHB> oh error correction (not elliptic curve)
17:53:05 <moneromoooo> An actuve attacker will set both to what advantages them.
17:53:05 <hyc> ECC seems like overkill here
17:53:17 <hyc> and again, not useful if you just incompletely copy the string\
17:53:40 <UkoeHB> error correction means post-processing the address to 'fix' it, which means an error-correctable string really has two addresses within it depending if you error correct or not
17:53:54 <UkoeHB> a checksum is just pass/fail
17:54:14 <hyc> but for example, a classical ECC mech on a 32 or 64bit word can detect 2 bit errors and correct all 1-bit errors
17:54:25 <hyc> if there are more than 2 wrong bits, you're on your own
17:54:41 <rbrunner> Just re-displaying the corrected address in a wallet in a way that makes patently clear what was corrected is a challenge
17:54:54 <moneromoooo> Well the amount of redundant data is a tradeoff you can choose.
17:55:15 <moneromoooo> And, IIRC, scales fairly well for longer strings.
17:55:29 <moneromoooo> (meaning sublinear)
17:55:34 <hyc> true
17:55:59 <hyc> but I don't think anyone has a good idea of the threat model being protected against here
17:56:07 <one-horse-wagon[> Instead of typing out the entire 181 character address every time, couldn't the address when first created, have a simple nickname in your wallet that would then reference the complete address?
17:56:52 <one-horse-wagon[> Or even a sequential number if you are going to have many addresses
17:57:19 <rbrunner> Hmm, yes, but making that easy is a different problem, seems to me. We are talking about getting the 181 characters in correctly in the first place
17:57:54 <dangerousfreedom> hyc: True. Is anyone aware about complaints so far about the current model? Which is a simple checksum using Keccak?
17:57:57 <merope> some wallets already have an addressbook feature, but it doesn't help when you're copy pasting an address you've received (or when you want to send it to someone else)
17:58:35 <rbrunner> Can't remember any reported problems.
17:58:47 <hyc> seems to me those are all interactive situations
17:58:59 <moneromoooo> EC is really for unreliable data transmission, not defence vs active attacks.
17:59:01 <hyc> in which case it's perfectly fine to just checksum, say "this is wrong, try again"
17:59:02 <UkoeHB> Let's say an attacker wants to replace your address with something that looks similar but sends funds to the attacker. The attacker needs to generate an address that converts to a similar base58 string, but that probably takes many 'erroneous' characters to get right even with a lot of work. Therefore a checksum is superior because for large numbers of errors it has the same detection probability, whereas an error 
17:59:02 <UkoeHB> correction polynomial apparently has lower detection rates for large numbers of errors (given the same checksum bit length).
17:59:24 <moneromoooo> Or unreliable store/retrieveal.
18:00:05 <moneromoooo> I suspect that'll only work if the address has *lots* of redundancy info in.
18:00:39 <hyc> it seems to me that a checksum is all that is necessary and sufficient here
18:00:43 <UkoeHB> If an attacker wants to replace your address with a burn address, then neither checksums nor error correction will be very useful (for long strings that can't be fully validated visually, which we are dealing with).
18:00:50 <rbrunner> Usually attackers nowadays just ask "Buy my NFT" and people send their XMR already over :)
18:02:10 <Rucknium[m]> https://www.reddit.com/r/Monero/comments/y8xmph/psa_weve_discovered_malware_that_replaces_the/
18:02:34 <Rucknium[m]> Would error correction make this attack easier? 
18:02:54 <hyc> no impact
18:02:54 <rbrunner> Right, but as far as I remember that was blunt replacement with a completey different address, just silently / invisibly
18:03:14 <rbrunner> because implemented as a browser extension
18:03:22 <rbrunner> that can do such things
18:03:56 <rbrunner> So, no help from any checks, I would say
18:05:03 <rbrunner> So down with polynoms, we already are busy enough coding mountains of other code for Seraphis, no?
18:05:04 <UkoeHB> dangerousfreedom: I'd tentatively go for a checksum (we can revisit this as needed). You can use the seraphis hashing interface to access blake2b, which is faster than keccak.
18:06:01 <dangerousfreedom> UkoeHB: Ok. Great. I agree with everyone's answers too.
18:06:35 <UkoeHB> we are overtime on the meeting, but are there any other topics people wanted to cover before we wrap it up?
18:06:45 <plowsof> reg bp++ "audit": The deliverable is our (CypherStack) write-up which will include recommendations, notes, weaknesses, and issues (if any) of the BP++ paper. 
18:09:46 <UkoeHB> plowsof: thanks
18:09:57 <UkoeHB> ok that's the end of the meeting, thanks for attending everyone
18:09:59 <dangerousfreedom> UkoeHB: Not from my side. Thanks Koe.
19:06:32 <tevador> I read the meeting logs. I think there has been a misunderstanding. The proposal was not for error correction (EC) but for a polynomial-based checksum. The fact that it can also do EC is irrelevant. It has many advantages over hash-based checksums even without EC.
19:07:50 <hyc> that definitely was not well understood in the discussion
19:10:06 <rbrunner> What are the advantages?
19:12:56 <hyc> The checksum can detect all errors affecting 4 or fewer characters and will fail to detect more errors with a chance of less than 1 in 10^12
19:14:12 <UkoeHB> a hash-based checksum 'fails to detect more errors' with a chance of 1 in 10^19, for comparison (using 8 bytes)
19:14:30 <hyc> "Another advantage of BCH codes is the ease with which they can be decoded, namely, via an algebraic method known as syndrome decoding. This simplifies the design of the decoder for these codes, using small low-power electronic hardware. "
19:14:58 <hyc> so, fast verification?
19:15:38 <tevador> The proposed checksum is not 8 bytes but 8 characters, i.e. 40 bits.
19:16:23 <rbrunner> Ok, my bad. But that misunderstanding probably did not influence the discussion.
19:16:23 <tevador> Yes, much simpler and has guaranteed error detection capabilities.
19:17:32 <rbrunner> Maybe simpler, but we have the hashes already, don't we?
19:19:10 <tevador> A 40-bit hash-based checksum would probably also work, but you'd lose error detection guarantees.
19:19:17 <rbrunner> And well, a chance of 1 in 10^19 that e.g. 1 wrong character give the same hash, is that in need of improvement?
19:19:37 <tevador> 1 in 1^12 not 19
19:19:48 <tevador> 10^12
19:20:17 <UkoeHB> tevador: ah I misread character as byte
19:20:46 <rbrunner> I refer to UkoeHB's number about the reliability of hash algorithms, which he gave as 10^19. Is that worse with only a single wrong character?
19:21:02 <UkoeHB> rbrunner: I thought it was 8 bytes, not 8 b32 characters
19:21:13 <tevador> 10^19 is for 64 bits, 10^12 for 40 bits
19:21:38 <rbrunner> Ah, ok, now I see. Well, 10^12 is something of another story.
19:21:40 <UkoeHB> in that case, yes a polynomial would be superior to a hash
19:22:35 <rbrunner> Still makes the codebase bigger still, more code that can have bugs, can have weaknesses, and so on.
19:22:51 <UkoeHB> although I think it would be best to explicitly disable error correction, if that's possible, so no one tries to do something 'clever;
19:22:58 <tevador> It's about 8 lines of C code.
19:23:14 <rbrunner> Surprising.
19:23:34 <rbrunner> One way I guess? And again that much for the other way?
19:24:34 <rbrunner> Yes, I don't think the discussion went astray in this regard: Error-correction capability has worrying aspects.
19:24:46 <tevador> https://github.com/bitcoin/bitcoin/blob/5e82b9ba96b6c5614a1187382a086e5694dff544/src/bech32.cpp#L177-L215
19:24:55 <tevador> if you remove comments, it's 9 lines
19:26:26 <rbrunner> Alright, I was suspecting something in the size of a hash algorithm.
19:29:00 <rbrunner> Doesn't Polyseed also use those?
19:29:42 <tevador> it uses something similar, but a different finite field
19:29:55 <rbrunner> With EC capability?
19:31:59 <tevador> erasure is an error with known location but unknown value
19:33:50 <rbrunner> Ok. I think the UI/UX situation for seeds would anyway be much simpler than for addresses.
19:36:25 <rbrunner> You did not yet comment about the potential problems we suspect if wallets start to correct addresses.
19:37:46 <hyc> that's already off the table
19:37:48 <tevador> I don't recommend that to be implemented.
19:37:59 <hyc> since he stated this was never about error correction
19:39:45 <rbrunner> Fair enough, but as long as it's possible, some well-meaning wallet dev may implement it, and troubles start. Or am I mistaken here?
19:40:19 <rbrunner> They may think it's the best idea they ever had.
19:40:20 <hyc> in a 3rd party source base sure anything can happen
19:40:37 <rbrunner> Doing good for the user.
19:43:07 <UkoeHB> if error correction is possible then it's part of the API
19:43:15 <UkoeHB> whether or not core implements it
19:44:02 <tevador> People can also try to "correct" with hash-based checksum. You can't stop stupidity.
19:44:42 <UkoeHB> not for most errors in large strings
19:45:00 <tevador> You can produce *some* address that matches the checksum.
19:45:13 <rbrunner> Ah, come on, that's a bit unfair, to compare something that you can brute-force for correction with something that is *designed* to enable correction
19:45:44 <rbrunner> And then call people who that "stupid" :)
19:45:55 <rbrunner> *who do that
19:47:45 <rbrunner> But I agree, it's quite a difficult decision, guaranteed error detection versus possible dangers from somebody implementing error correction with a bad UI/UX ...
19:47:48 <tevador> Bitcoin uses it and I'm not aware of any wallets that do error correction for bech32 addresses. If the specs say it should not be done, sane developers won't do it.
19:53:04 <tevador> Here is another example of making jamtis weaker on purpose to prevent bad implementations: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4275011
19:53:12 <rbrunner> Hmmm, looks like they had a weakness at first attempt: https://bitcoin.stackexchange.com/questions/101117/what-problems-identified-with-bech32-addresses-have-been-resolved-with-the-updat
19:56:30 <rbrunner> " making jamtis weaker on purpose": "weaker" depends on how you weight the various aspects, seems to me, it's not an absolute, and stronger math and crypto is always better *overall*
19:56:51 <rbrunner> er, of course is *not* always better overall
19:58:37 <tevador> "weaker" is meant in the cryptographic sense, which it is
19:59:52 <UkoeHB> from my point of view, a design full of feature footguns is weaker than one that has pitfalls if you write insecure code... you can always write insecure code, but you can't always write new features that aren't possible
20:00:17 <hyc> huh?
20:01:09 <UkoeHB> a feature is 'something you can do with the API', a bug is arbitrary crappy code
20:01:40 <tevador> I'm all for designs that are less bug prone, but generally not at the cost of actual cryptographic weaknesses.
20:02:16 <rbrunner> Maybe a much simpler example, if a bit exaggerated? Q: Why don't we add a 32 bytes checksum, would be stronger? A: The addresses get unwieldy.
20:02:40 <rbrunner> Weighing one against the other
20:05:26 <tevador> Not the best example. Here the drawbacks are purely "someone might implement it wrong".
20:06:45 <rbrunner> "wrong" sounds so terribly negative. Somebody is tempted to use an available feature that they should not use, as per recommendation, for any perceived gain.
20:07:39 <rbrunner> If you use an error correction capable algorithm for acutally corecting errors, is it ok to call that "wrong"?
20:08:54 <hyc> if the API is called "foo_checksum" then you're misusing it
20:09:04 <tevador> rbrunner: Yes, if it's against the specs.
20:09:47 <tevador> Same as using a constant IV with AES encryption. The algorithm "allows it", but the result is unsafe.
20:10:17 <UkoeHB> hyc I mean API in an abstract sense - what is required to be conforming with other implementations. In the case of a checksum it is using the correct algorithm. If that algorithm comes with error correction, hey maybe I'll add that to my app. We definitely can't expect our 'recommendations' to hold weight for decades down the line.
20:12:51 <UkoeHB> tevador: using a random IV is a requirement of using AES safely (i.e. don't bother with AES at all if you use a constant IV), it isn't anything close to a recommendation
20:13:23 <one-horse-wagon[> If I were going to send a very large amount of monero to someone, there is no way I would depend on a check_sum hash to be correct.  I would use a bash command like --diff-- to make sure the two addresses are exactly the same.  Is there is no way to incorporate something like that into the coding?
20:15:04 <UkoeHB> According to this https://en.wikipedia.org/wiki/BCH_code the polynomial can be adjusted to control how many bits may be corrected. Can you reduce it to zero without losing detection guarantees?
20:16:34 <UkoeHB> one-horse-wagon[: yes wallets should do that
20:17:27 <hyc> to make sure *which* two addresses are exactly the same?
20:17:52 <tevador> UkoeHB: No. The algorithm can always detect "d" errors and correct "d/2" errors where "d" is the distance parameter.
20:21:54 <UkoeHB> I see
20:21:56 <tevador> one-horse-wagon[ the "RID" in the jamtis specs serves this purpose. If you check the 25 character RID, you have a guarantee it's the correct address (with a 2^120 security)
20:24:31 <tevador> UkoeHB: the way the guaranteed error detection works is by encoding the "message" in a space where correct codewords are separated by d+1 invalid codewords. This can always be made into an error correction algorithm by "rounding" ot the nearest valid codeword.
20:24:57 <tevador> rounding to*
20:25:20 <UkoeHB> huh interesting
20:26:31 <tevador> This also shows the dangers of the error correction. If the message has more than d/2 errors, you can round it to the wrong (but valid) result.
20:28:43 <rbrunner> And you can't detect the number of errors, I guess?
20:28:53 <rbrunner> (Stupid question from a crypto noob)
20:29:33 <rbrunner> or at least detect "I am over the limit"
20:32:00 <tevador> No, you can only see the distance from the nearest valid codeword. But it's generally assumed that fewer errors are more likely to occur.
20:32:12 <rbrunner> Anyway, as the summary for me personally, from what I learned in addition after the meeting's close, the two proposals are much closer than they first appeared
20:33:21 <rbrunner> With me as the almighty, all-deciding CEO of Monero I would probably give the nod to Tevador's design, with the idea of something like "respecting the design and the designer"
20:33:40 <tevador> a 40-bit truncated hash checksum is probably fine, only a bit clunky
20:34:21 <rbrunner> :)
20:36:05 <rbrunner> But I learned much from the discussion, and without doubt we will meet similar pros and cons and weighting difficulties again in the future
20:37:16 <tevador> BTW any MRL feedback on this? https://github.com/tevador/RandomX/issues/258
21:10:26 <UkoeHB> left a comment
21:11:02 <tevador> thanks