05:00:39 i​amnew117:matrix.org: hello there is an meet today right ? https://github.com/monero-project/meta/issues/1350
05:00:39 i​amnew117:matrix.org: can anyone tell me timming i am very new to this so not sure
05:42:28 i​amnew117:matrix.org: my bad i am an retard for not readin title properly sorry
16:53:55 r​brunner7:monero.social: Meeting in a bit more than 1 hour, when it will be 18:00 UTC. Beware of the DST start if you are in the US.
17:59:45 r​brunner7:monero.social: Meeting time. Hello! https://github.com/monero-project/meta/issues/1350
18:00:05 j​effro256:monero.social: Howdy
18:00:08 v​tnerd:monero.social: Hi
18:00:10 j​pk68:matrix.org: Hello
18:00:39 j​berman:monero.social: *waves*
18:01:30 s​needlewoods_xmr:matrix.org: Hello
18:02:02 j​effro256:monero.social: Seems like we lost a contributor just a few moments ago
18:02:24 r​brunner7:monero.social: Nice round today. So what are the reports from last week?
18:02:45 r​brunner7:monero.social: jeffro256: Yeah, looks like it.
18:03:25 UkoeHB: Hi
18:03:50 r​brunner7:monero.social: UkoeHB: Welcome back :)
18:03:55 j​effro256:monero.social: Hi koe!
18:03:57 v​tnerd:monero.social: Tracked down the tx-notify issues on both stressnet and mainline. Upcoming work is to update the lws+lwsf patches to the new changes in fcmp++-stage
18:05:14 s​needlewoods_xmr:matrix.org: According to my investigation, out of the 53 [wallet rpc error codes](https://github.com/monero-project/monero/blob/master/src/wallet/wallet_rpc_server_error_codes.h), only 14 of them need to be handled/propagated by the Wallet API
18:05:54 j​effro256:monero.social: Me: Rebased fcmp++-stage against master to prepare for beta stressnet: https://github.com/seraphis-migration/monero/tree/fcmp%2B%2B-stage-new-3-7-2026. Writing stressnet-specific PRs (stressnet window size change, RPC config changes, etc) locally against it, also to prep for beta. Beefing up testing for hot/cold wallet PR.
18:05:57 r​brunner7:monero.social: SNeedlewoods: Sounds like good news for the approach
18:06:19 j​berman:monero.social: Had some discussion with koe re: integration audit plans (excited to have koe back!!), koe proposed combining phases 1 & 2 together since phase 1 is a fairly small amount of work. I'm currently preparing the PR's for phase 2 right now, and aiming to complete that today & begin audit comms tomorrow
18:07:27 UkoeHB: Me: rereading ztm2, reviewed the current state of fcmp++ with jberman’s help
18:08:06 s​needlewoods_xmr:matrix.org: I still didn't do your proposal justice, went with my `exception_ptr` idea so far, but I'm planning to answer on the issue you created once I get my notes done
18:08:26 r​brunner7:monero.social: More eyes on FCMP++ are certainly very welcome
18:09:55 UkoeHB: Planning to read the carrot paper and review the carrot_core PR so it is closer to mergeable when audits are done. Then try to figure out multisig
18:10:16 UkoeHB: What are the review/audit intentions for carrot_core?
18:12:02 j​effro256:monero.social: Cypherstack audited carrot_core recently: https://github.com/cypherstack/carrot_core-audit/
18:13:18 UkoeHB: Thanks, missed that one. Are there any other carrot-related audits?
18:14:30 j​effro256:monero.social: Not at the moment, but it would probably be worth auditing some of the transaction construction code in carrot_impl at some point
18:15:26 UkoeHB: Ok. Do you think it would still be worthwhile for me to review carrot_core? I will at the very least do a partial review to understand the code.
18:15:45 j​berman:monero.social: There were these as well: https://github.com/jeffro256/carrot/tree/master/audits
18:19:29 r​brunner7:monero.social: Maybe that answer about review will get answered in a bit.
18:19:29 r​brunner7:monero.social: If we are through otherwise with the reports, I have something coming out of my journey into Polyseed that I would like to put on the table.
18:19:41 r​brunner7:monero.social: It started with this comment from Tevador: https://github.com/tevador/polyseed/issues/13#issuecomment-4007864335
18:20:26 r​brunner7:monero.social: It seems that there is an important difference between now and Carrot, that the main "secret" is a point on the one hand, and just 256 bits (a scalar?) on the other hand
18:20:53 r​brunner7:monero.social: And that this will have consequences about handling of seeds, and the need or not to reduce
18:21:21 j​effro256:monero.social: Ah yes ^ the spec reviews too
18:21:22 j​effro256:monero.social: koe: yeah if you are going to be looking over the code anyways, it would appreciate any feedback on it!
18:21:57 r​brunner7:monero.social: I worry that this has the potential to cause trouble with no end when restoring from seed, because the code may do either a reduce too much, or miss one
18:22:13 UkoeHB: jeffro256: ok
18:22:57 j​berman:monero.social: > I would advise against supporting legacy seeds with new wallet types unless we think it's OK to require users to manually input their hierarchy type (legacy/Carrot/Jamtis) when restoring a wallet
18:22:59 j​berman:monero.social: I have thoughts on this comment by tevador. First off, even if we didn't support legacy seeds with new wallet types, there has to be a way to differentiate if a user is restoring a legacy wallet or a Carrot wallet into perpetuity
18:23:16 j​berman:monero.social: I think using a feature bit may make sense for Carrot
18:24:08 r​brunner7:monero.social: Yes, that's a slightly different question
18:24:41 j​berman:monero.social: Second off, I'm in favor of continuing support for the legacy seed type primarily so that people who don't want to use the new view balance key have the option to not use it
18:24:55 j​effro256:monero.social: I've been thinking about this, and I'm getting closer to saying that it doesn't really matter for security, since the original entropy is only 128 bits. Reducing probably doesn't affect the security a non-negligible amount since the scalar space is ~232 bits, so even though the reduction "removes" ~4 bits, the probability that many 32 bit secrets, generated by 128 seeds, reduce to<clipped
18:24:57 j​effro256:monero.social: the same scalar is pretty small
18:25:11 j​effro256:monero.social: But plz take it with a grain of salt, I'm just spit balling
18:25:41 r​brunner7:monero.social: Do people see the potential for confusion, wrong wallet restores, etc, that I see?
18:26:14 j​effro256:monero.social: I could definitely see a possibility for some implementation weirdness
18:26:47 r​brunner7:monero.social: If you have to decide whether to reduce or not, and the correctness of the info given about the type of seed decides whether the restore succeeds, that's pretty fragile IMHO
18:27:24 j​effro256:monero.social: It does, although it would be nice to have a seamless upgrade with the same seed phrase. Although that may make the people against OVKs uncomfortable
18:27:35 j​berman:monero.social: If we have a way to differentiate legacy and Carrot seeds (which I think we will need no matter what), then I think Carrot wallets always XOR'ing when a passphrase is provided makes sense (i.e. the mechanism for Carrot seed restore when passphrase is provided is the same even regardless of whether or not an encrypted feature bit set. the benefit of the encrypted feature bit is tha<clipped me
18:27:35 j​berman:monero.social: t if it's set, then wallets should require a passphrase input)
18:28:17 r​brunner7:monero.social: Hmm, we have several things inter-relate with each other here.
18:28:59 r​brunner7:monero.social: That's again a potential pittfall, if we suddenly have *two* methods how to apply seed offsets, and wallets can disagree which to apply
18:30:48 r​brunner7:monero.social: I have a concrete proposal for discussion: To become less fragile, let's "sacrifice" 4 bits of Carrot master secrets by reducing them as if they were points, and then continue to use subtracting seed offsets for *all* types of secrets/keys
18:31:00 j​berman:monero.social: I don't see how to achieve a seamless upgrade with the same seed phrase
18:32:14 j​babb:cypherstack.com: the people uncomfortable with OVKs can just not use them
18:32:25 UkoeHB: rbrunner: points use 256 bits, scalars are 253 bits
18:32:39 j​effro256:monero.social: New addresses replace old addresses in UI, the generate-addres tier works for new addresses, old addresses still work though, if funds are all held in new addresses, then OVKs can be used
18:33:04 j​effro256:monero.social: They don't seem to understand that ;)
18:33:11 r​brunner7:monero.social: UkoeHB: Now I am pretty confused
18:33:53 r​brunner7:monero.social: Maybe I am just using terminology wrong
18:34:09 r​brunner7:monero.social: "Reduce" leaves a smaller number, right?
18:34:42 j​berman:monero.social: hmm, I don't know if I'd call this seamless. For one, wallets will still need to scan both for legacy and new, no? For two, I'd argue replacing addresses in the UI is a pretty major UX change
18:34:48 UkoeHB: A point is two coordinates, a single coordinate is 255 bits and the second coordinate is signified by a sign bit.
18:35:21 UkoeHB: So both require reduction
18:35:47 j​effro256:monero.social: You can share the private view-incoming key if you know that you're using an old Polyseed
18:36:41 r​brunner7:monero.social: Is at least my assumption correct that if we just go ahead and reduce Carrot master secrets we lose 4 bits? Which we may deem acceptable in the interest of making things less brittle
18:36:42 j​effro256:monero.social: Replacing the addresses being a big UX change is fair. For someone who doesn't expect it, but memorizes the characters in their addresses, that could be scary
18:37:25 r​brunner7:monero.social: Looks like there are at least 3 important issues to discuss surrounding Carrot keys ...
18:37:44 j​effro256:monero.social: You don't even lose 4 AFAICT since the original entropy is 128 bits, much less that the total scalar space of 232 bits
18:37:54 j​berman:monero.social: The default user isn't sharing private view keys with anyone, and I'm saying seems the local wallet would have ~2x'd scanning work
18:38:18 r​brunner7:monero.social: With Polyseed only, right? Legacy seeds can produce the full 256 bits
18:38:34 j​babb:cypherstack.com: I had assumed that we'd basically add scanning of carrot addresses alongside the legacy scanning but had hoped we could just cleanly adopt and move to carrot at hf. but that won't be happening, will it?
18:38:58 j​babb:cypherstack.com: that is, we will be scanning legacy and carrot post-hf?
18:39:26 r​brunner7:monero.social: Oh, so it's 256-232=24 bits we are talking about?
18:39:27 j​effro256:monero.social: Think of it like this, if the seed phrase was only 10 bits (1024 possible combos), then reducing would like almost certainly have 0 effect on the number of possible secret keys, since the probability of 2 of the 1024 32-bit secrets reducing to the same scalar is near 0
18:40:27 j​effro256:monero.social: Yes, legacy would have a reduction of ~4 bits, which still means they beat Polyseed by about 104 bits :)
18:40:58 UkoeHB: 232? Now I’m the one confused lol
18:41:30 j​effro256:monero.social: I'm saying that the wallet would automatically share the private view-incoming key with the 2 key hierarchies, so the scanning work stays the same
18:41:32 r​brunner7:monero.social: So there is not much to worry about losing bits, essentially, and we can discuss trade-offs. Like the somewhat illogical step of reducing something that does not need reducing, technically.
18:41:47 j​effro256:monero.social: Sorry, 252
18:42:06 j​berman:monero.social: Ahhh, I follow
18:42:28 UkoeHB: jeffro256: 253, no? Unless I wrote it wrong in ztm2
18:42:36 j​effro256:monero.social: So legacy beats Polyseed by 124, excuse me. The point is that the reduction doesn't really matter for security I believe
18:43:10 j​effro256:monero.social: Uhhhh you're probably right, I'm going off of memory rn
18:43:15 j​effro256:monero.social: Whatever size l is
18:43:47 r​brunner7:monero.social: I think we would really profit if we don't let full 256 bit numbers occur anywhere, at any time, if it is about the "master secret". Easy to check, easy to handle, hard to produce bugs and wrong restores etc.
18:43:49 j​effro256:monero.social: It's 252 plus change
18:44:04 r​brunner7:monero.social: Yeah, it's not about "full" bits :)
18:44:23 UkoeHB: If the entropy is ~128 bits, then reducing an expanded 256 bits to 253 will lose half the reduced bits, so ~2 bits.
18:44:50 j​berman:monero.social: Ok I concede on the point of scanning not needing to be ~2x'd if legacy seeds were upgraded to Carrot seeds
18:45:20 r​brunner7:monero.social: By the way, subtracting instead of XOR also for Carrot has the small advantage that really paranoid people can subtract more than once
18:45:45 r​brunner7:monero.social: And produce progressively more filled families of decoy wallets
18:46:09 r​brunner7:monero.social: (But only with legacy seeds maybe?)
18:46:17 j​berman:monero.social: The UX challenge of having both legacy addresses and Carrot addresses from one seed seems tricky still in my view
18:46:51 r​brunner7:monero.social: Yeah, that could cause confusion on a whole new level
18:47:10 r​brunner7:monero.social: I am not sure the trade-offs are good for such combined wallets
18:47:19 j​babb:cypherstack.com: in an ideal world at hf we could just by convention move to carrot addressing and so by convention be able to not have to scan legacy past that point
18:47:22 r​brunner7:monero.social: Even if possible in theory
18:47:34 j​babb:cypherstack.com: unfortunately wallets are going to need additional controls
18:47:37 j​berman:monero.social: I wouldn't necessarily call this a real advantage. You can hash a passphrase as many times as you want too and derive n seeds from a ciphertext that way
18:47:56 UkoeHB: jbabb: existing addresses posted in the wild need to remain functional
18:48:18 j​berman:monero.social: > existing addresses posted in the wild need to remain functional
18:48:19 j​berman:monero.social: ya this is a critical aim with the hf
18:48:25 j​babb:cypherstack.com: very true, it's nonsensical really to suggest we'll be able to stop scanning legacy
18:48:40 j​babb:cypherstack.com: some wallets will choose to only use legacy, some will move to carrot, some will support both
18:48:51 r​brunner7:monero.social: But still we don't have to support "mixed wallets", with two sets of keys, right?
18:49:07 r​brunner7:monero.social: It's all already complicated enough, if you ask me.
18:49:13 UkoeHB: Monero has a history of only supporting old stuff to the extent of backwards compatibility, but not to the extent of full ongoing support.
18:49:32 j​babb:cypherstack.com: practically, yes
18:49:41 UkoeHB: So never producing new legacy addresses seems appropriate.
18:50:11 r​brunner7:monero.social: It took only one tiny feature bit ("Encrypted?") and different wallets doing different things with it to create a mess with Polyseed
18:50:45 r​brunner7:monero.social: We have wallets failing to restore an encrypted Polyseed silently, without any warning.
18:51:01 UkoeHB: Old seeds will always scan both legacy and carrot, new seeds only scan carrot, and the core wallet UI only presents new carrot addresses (but tx history and address balances include legacy).
18:51:36 j​babb:cypherstack.com: +1
18:52:43 j​berman:monero.social: I think it will raise the controversial elements of the hf (specifically the ovk) a significant degree by not supporting the creation of legacy seeds after the hf in core software. I'm also fairly certain wallets in the ecosystem emerge that support new legacy seeds
18:53:07 r​brunner7:monero.social: Agree.
18:53:20 r​brunner7:monero.social: Basically impossible to prevent.
18:53:37 j​babb:cypherstack.com: a monero-wallet-cli flag to enable legacy seeds/addresses would suffice
18:53:56 r​brunner7:monero.social: We also have hardware now that produces Monero keys and addresses, I believe
18:54:33 r​brunner7:monero.social: I am more thinking about smartphone wallet apps, that are in competition regarding supporting features.
18:54:47 r​brunner7:monero.social: The more, the better sometimes.
18:54:47 j​effro256:monero.social: I'm somewhat fine not supporting the new key hierarchy in Polyseed, forcing the user to move over to a new seed phrase to get the new features. However, I'm much more worried about hardware wallets. Ideally, a HW user should NOT need to change their seed phrase to use new feature s
18:56:22 j​berman:monero.social: I think supporting both legacy + carrot addresses from 1 seed will carry a load of complexity wallets will need to deal with, both from a UI perspective and internal code
18:56:48 UkoeHB: jbabb: instead of a flag, the cli wallet API could include ‘new legacy_address’ in addition to ‘new address’ creating carrot addrs.
18:56:50 r​brunner7:monero.social: Again, agree. I personally would like to just shoot that down :)
18:57:05 r​brunner7:monero.social: (to jberman )
18:57:07 UkoeHB: And new legacy_address would error for new seeds
18:57:43 j​babb:cypherstack.com: UkoeHB: +1. rbrunner7, this and anything accessible via wallet2 will suffice for Cake and Stack at least, which both use wallet2 via MrCyjaneK's monero_c project (which he's updating for stressnet with Cake too btw)
18:58:01 j​babb:cypherstack.com: it shouldn't be monero-project/monero's job to maintain support for every experimental wallet's format, but vice versa: imo it's all the other wallets' job to reproduce monero-wallet-cli behavior, not the other way round
18:58:10 j​effro256:monero.social: Do you plan to tell HW users that they simply don't get the new features because of the complexity for us?
18:58:13 j​babb:cypherstack.com: if polyseed even "officially" adopted in "core" software? is in in-scope yet?
18:58:17 j​babb:cypherstack.com: is*, sorry.
18:58:23 j​pk68:matrix.org: UkoeHB: Why make legacy_address error? I have no problem with Carrot or anything, just wondering
18:58:41 j​effro256:monero.social: FWIW, a lot of code in the Carrot integration was written in mind to support hybrid key hierarchies
18:58:58 j​babb:cypherstack.com: is polyseed even "officially" adopted in "core" software? is it "in-scope" yet?*
18:58:59 UkoeHB: jpk68: because new seeds would only be expected to scan with the carrot method
18:59:17 UkoeHB: An expectation required for cross-wallet compatibility
18:59:36 j​berman:monero.social: I think that's completely fine yes. It's also not just the complexity, it's also the controversy surrounding the ovk. I think it's 100% reasonable to say if you want an ovk, create a new wallet and transfer funds to it
18:59:50 r​brunner7:monero.social: "Do you plan to tell HW users that they simply don't get the new features " That's formulated a bit harshly, no? They are one new address generation and sweep away from the new features
18:59:52 j​pk68:matrix.org: UkoeHB: Fair point
19:00:57 j​effro256:monero.social: Is it reasonable to tell HW users to change seed phrase when A) people hold BTC, ETH, LTC, DASH, etc other coins on their wallet, and B) it defeats the entire point of a HW to be messing with seed phrases?
19:01:24 r​brunner7:monero.social: I can only repeat that we managed to produce a fine mess with something as simple as a Polyseed feature bit, because of different wallet implementations. Aren't people here as pessimistic as I am regarding possible trouble? :)
19:02:13 j​babb:cypherstack.com: rbrunner7: is that all of our jobs to clean up and support going forward, though?
19:02:22 j​effro256:monero.social: They're aren't one sweep away if A) they hold other coins, or B) if they plan to support old addresses they have posted elsewhere
19:02:28 UkoeHB: jberman: can you elaborate why old seed wallets defaulting to making new carrot addrs would be problematic? (with the caveat of a minimal API to generate legacy addresses)
19:02:34 j​berman:monero.social: They created a seed without the ovk in the first place, I think if they don't want the ovk, they'd would be ok with not having it, and if they want the ovk, they'd be ok with taking an extra step
19:02:50 r​brunner7:monero.social: jeffro256: The HW could produce a new Carrot secret from the one master HW multi-coin secret?
19:03:07 r​brunner7:monero.social: Treating Carrot basically like a new coin
19:03:09 j​effro256:monero.social: rbrunner7: exactly
19:03:28 r​brunner7:monero.social: Thus I don't see the problem...?
19:04:18 j​berman:monero.social: @UkoeHB: if a user already sees address X in their wallet, and then stops seeing that address, and/or the UI is telling them "use Y address instead", I think that is a confusing pain point to illustrate cleanly to users
19:04:26 j​effro256:monero.social: Sorry, the new coin part seems like unnecessary cruft, but otherwise, yes
19:05:02 r​brunner7:monero.social: Anyway, seems to me we have so many complex open issues that we most probably won't reach our famous "loose consensus" about any of them today
19:05:07 j​berman:monero.social: Or are you saying, if UI has already displayed X addresses, don't change anything with X addresses, and just show new Carrot addresses when creating new addresses going forward
19:05:29 UkoeHB: Yes only make new addresses as carrot.
19:05:47 r​brunner7:monero.social: We had x people freaking out because one HW wallet did not support the display of integrated addresses, remember?
19:06:02 UkoeHB: Displaying wallet history has to continue displaying legacy addrs.
19:06:26 j​effro256:monero.social: The device can still inform users of a change TBF. It can either be a bit stored in persistent storage on-device, or the hot wallet can call some endpoint if the HW device is old, but the wallet cache stores that the user hasn't accepted the dialouge yet
19:07:53 j​effro256:monero.social: That's just a straight up bug in the Ledger wallet, not a conscious design decision. I don't see how that's relevant
19:08:15 UkoeHB: The cli can display a warning/notice message when ‘address’ returns a legacy addr for old seeds. To inform the user that carrot is available. And maybe add a cli command to switch ‘address’ display to carrot (saved in wallet data, has to be re-set on restore).
19:08:25 j​berman:monero.social: @UkoeHB: continuing to display already displayed legacy addresses is better than what I originally thought. Imo it's still a bit of a gross thing to fully deal with if all wallets don't already converge on exactly what they display to users
19:09:07 r​brunner7:monero.social: jeffro256: It's not technically relevant, but it illustrates how users react if they don't understand something. Like addresses that seem to change at a given point in time, if I understand the proposal correctly
19:09:41 UkoeHB: jberman: a bit of grossness seems inevitable. One big point of carrot over jamtis was ~seem less transition of existing seeds, no?
19:10:07 j​berman:monero.social: The next tricky aspect to manage is storing both already displayed suabaddress index maps of legacy and carrot, and correctly only using Carrot addresses on new. The latter will also require a synced wallet to handle properly
19:10:56 j​berman:monero.social: The biggest point as I understood it was backwards compatibility so legacy seeds still received major new benefits of Janus protection, forward secrecy, etc.
19:11:03 j​effro256:monero.social: Fair enough. But the Leger integrated address issue is where the users are absolutely correct in that is a bug, there's not necessarily confusion there AFAICT. The only "confusion" is the fact that sending to an integrated address on a Ledger simply isn't verifiable
19:11:15 j​berman:monero.social: And that legacy was indistinguishable from Carrot on chain
19:12:35 r​brunner7:monero.social: I respect jeffro256 's dedicated efforts to support "hybrid" wallets with 2 sets of keys, but really ... do you think that complex address display trick described here will *ever* really work reliably over the whole wallet app ecosystem?
19:12:55 j​effro256:monero.social: UkoeHB: okay there's 2 components. There's CARROT, which is the addressing protocol, i.e. how to send XMR from sender to receiver, and how to send XMR to self. Then there's the new key hierarchy, which is recommended in the CARROT spec. No one needs to do anything whatsoever to use CARROT. In fact, CARROT is being used actively on the Alpha Stressnet right now. We're talking about<clipped
19:12:57 j​effro256:monero.social: how to introduce the new key hierarchy
19:13:25 UkoeHB: Ah, fair. And legacy addrs continuing to work. But I think it’s unreasonable to say carrot requires full wallet replacement just because of UX awkwardness. Anyone with serious wallet security will have a big pain replacing their seeds (eg people storing in lock boxes, hardware wallets, etc).
19:13:41 j​babb:cypherstack.com: well we have to have two sets of keys anyways, it's about how to present them
19:13:56 j​babb:cypherstack.com: we can't control wallets that want to keep presenting only legacy. "monero-wallet-cli-classic"
19:14:22 j​babb:cypherstack.com: we have to have two sets of keys for legacy seeds*
19:14:27 j​babb:cypherstack.com: for pre-existing wallets, that's a given
19:14:53 r​brunner7:monero.social: Yes, but you don't have to "switch" anything with address display if we don't support hybrid wallets, if I think about it correctly.
19:15:09 r​brunner7:monero.social: And *that's* were it seems I and jberman see a big tangle of complexity
19:17:05 j​berman:monero.social: There could be a way to create a Carrot-maxxed wallet from an existing master bip39 seed with a UI toggle
19:17:30 r​brunner7:monero.social: How about one person saying "I sent you the XMR, to this address" and the other person says "What? I cannot see such an address at all"?
19:17:36 UkoeHB: rbrunner7: you have to switch either way, it just depends where the switch occurs.
19:17:57 UkoeHB: The cli has to support both UIs.
19:18:05 r​brunner7:monero.social: Ah, no that particular example won't happen if the wallet app works correctly
19:18:09 UkoeHB: Either separate UI or merged.
19:18:31 r​brunner7:monero.social: Not sure what you mean with "separate UI". The addresses have the same format?
19:18:44 r​brunner7:monero.social: Display of secrets differs of course
19:19:06 j​babb:cypherstack.com: the cli will have to present whether an address is legacy or carrot
19:19:31 r​brunner7:monero.social: Really?
19:20:05 j​babb:cypherstack.com: ha, maybe not, actually.
19:20:07 r​brunner7:monero.social: It must be able to tell you what kind of wallet you have, yes. But addresses?
19:20:52 j​effro256:monero.social: For the basic user, I'd imagine that they don't really care which address is of which type
19:22:52 UkoeHB: It would be useful to describe each of the two ‘solutions’ in detail (CLI modifications, UX flows) so they can be compared fully. New GitHub issue?
19:23:24 r​brunner7:monero.social: UkoeHB: Sounds like an idea.
19:24:02 j​berman:monero.social: +1
19:24:38 r​brunner7:monero.social: Now we just need a volunteer to write that ..
19:24:39 j​babb:cypherstack.com: ha, maybe not, actually. edit: definitely not, sorry. I was considering a merged UI but that also wouldn't be required.
19:25:15 UkoeHB: rbrunner7: I can do it
19:25:23 j​berman:monero.social: fwiw, the Carrot spec even says section 2.2 is for New wallets only "Existing Monero wallets will not inherit these features, unfortunately" .. it would definitely be a deviation from the info out now that existing wallets will gain the new feature set
19:25:36 r​brunner7:monero.social: Splendid, UkoeHB!
19:25:48 r​brunner7:monero.social: Might help you to get into Carrot, in fact
19:26:02 j​berman:monero.social: (and that all wallets would have ovk's after the fork)
19:26:31 r​brunner7:monero.social: Well, you could make it an extra step "Create a hybrid wallet", no?
19:26:43 j​effro256:monero.social: I can also write up a more detailed version of what I've been trying to describe since I've been the one harping on it. Then we can compare / improve both
19:27:09 r​brunner7:monero.social: Even better. After all, much is at stake here.
19:27:24 j​effro256:monero.social: I guess it depends on what your definition of a wallet is, but yeah I can see why that would be confusing
19:27:27 r​brunner7:monero.social: Not only technically, but also regarding UX, that much should be clear now
19:27:49 j​berman:monero.social: Another annoying UX quirk is that the ovk doesn't even capture all of your txs because you can have mixed legacy txs
19:28:04 j​berman:monero.social: so it would be a watered down addition of the feature set
19:28:18 j​effro256:monero.social: Maybe could be worded as "*Without deriving new material*, existing Monero wallets will not ..."
19:28:34 r​brunner7:monero.social: Hmm, is that correct? That sounds bad, the OVK failing with hybrid wallets
19:29:00 j​effro256:monero.social: Yes, until you spend the funds sitting in legacy addresses
19:29:52 r​brunner7:monero.social: Coin control to the rescue, for everybody :)
19:30:50 r​brunner7:monero.social: Ok. That might be our longest meeting ever :) I think despite much left to discuss, and even more to finally decide, we can close the meeting proper, and continue to discuss during the week, or at the next meeting at the latest.
19:31:03 r​brunner7:monero.social: Thanks everybody for attending, read you again next week!
19:31:40 r​brunner7:monero.social: Interesting times indeed
19:31:48 s​needlewoods_xmr:matrix.org: thanks everyone, cu
19:31:54 j​pk68:matrix.org: :)
20:52:20 plowsof: Thanks for charing rbrunner, welcome back UkoeHB (thnx for sharing updates under your ccs, they are read)
20:52:32 plowsof: Chairing rather
20:53:56 r​brunner7:monero.social: You are welcome. And yeah, I hope I will never char a meeting :)