10:48:19 If fcmp++ makes reorgs more impactful, what is the status of non-pos finality research to mitigate this? Is there active work on consensus hardening (like "Publish or Perish" or something else) to protect the FCMP tree? 11:54:14 There is Share or Perish, which can be deployed as a soft fork with reasonably low costs (but only works against minority hashrate attacks): https://github.com/monero-project/research-lab/issues/146 12:00:39 tevador: Would this have avoided qubic type 18 block reorg ? 12:13:38 Yes. AFAIK they never actually had the majority of the hashrate. The 18 block reorg was just luck. 17:40:26 As koe mentioned at the last meeting, it is possible to encode (Jamtis) addresses as binary for use in QR codes. For example, Base32/62 could be used for its text representation; for QR codes, the ASCII characters monero: could be appended to the front of the raw address in bytes, and then that is encoded by the QR. 17:41:10 If my calculations are correct, this would result in smaller QR code sizes AND encoded address lengths, compared to just using Base32 for everything 17:42:27 It may be better to use monero: instead of xmr: as the 'identifier' at the start of it, since that would ostensibly be more distinct from random ASCII when the code is scanned by a device 17:43:37 monero: is what we use for URIs 17:43:51 The downside, of course, is implementation complexity 17:45:08 To make up for the more complicated QR code thing, we could always use the existing Base58 instead of Base62, as there are already so many code libraries that have implemented it. Three different encodings used is probably better than four 17:46:21 Plus the ASCII length reduction for Base58 versus Base62 is like something to the effect of 95% as good 17:46:58 I don't think binary QR codes are workable in practice. It needs to be a string to be a valid URI. 17:49:40 I could be wrong, but I think it can still be a string since binary QRs are seemingly interpreted as ASCII. It's just that the string isn't alphanumeric 17:52:33 It needs to pass URI validation rules, so most characters would need to be percent-encoded, which would nullify any space savings. 17:55:11 RFC 3986: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 18:01:39 Nuts :(( 18:05:45 base62 saves 9 characters compared to base58 (577 -> 568) 18:07:46 Actually, Monero uses a slightly less efficient variant of base58, so it's 12 characters (580 -> 568) 18:09:46 Ideally, addresses would fit in one IRC message, but I don't think it's possible without cutting features or security :( 18:10:13 The fact that Base58 doesn't include similar characters wouldn't be good enough to replace the remaining Base32 part though, right? 18:11:04 not without UX reduction (comparing case insensitive characters is easier) 18:36:59 where do u folks conduct meetings? :3 18:36:59 is it something open to the public? 18:36:59 im not familiar closely enough with the project to meaningfully contribute, but would be exciting to listen to it 18:37:41 that'd be here: #monero-research-lab:monero.social 18:38:43 meetings are on wednesdays at 17:00 UTC 18:39:26 Also, the meta repo for all dates and times :) 18:59:07 @redsh4de:matrix.org: what platform do u use for communication then? just text based meetups? 19:05:26 yeah, its all IRC/Matrix based 20:38:59 https://news.ycombinator.com/item?id=47897647 20:51:49 How bad is the fact that Jamtis addresses become linkable (e.g. 2 addresses that belong to the same wallet) if ECDLP is broken? 20:52:38 If you're talking about that article I sent, it's unrelated to Jamtis, I just thought it was interesting 20:52:44 Apologies if otherwise 20:52:50 This is largely unavoidable because the primary view tag still needs to be based on Curve25519 for performance reasons. 20:53:09 My comment was unrelated to the link you posted. 20:53:19 My bad, sorry 20:55:43 @jpk68:matrix.org: Read your private message please