00:16:52 https://github.com/PurpleI2P/i2pd_docs_en/pull/95 00:16:53 reviews needed 00:18:11 everything looks good to me but I haven't tried 00:24:24 <321bob321:monero.social> https://github.com/HardenedSteel/i2pd_docs_en/blob/patch-1/docs/tutorials/monero.md 00:25:17 <321bob321:monero.social> let me send to the banned one 03:01:55 Are there any browser wallets like metamask but for monero? 03:11:59 bufo nope. 03:25:01 MyMonero 🤔? 03:25:07 Will the fcmp++ hardfork support hardware wallets? I know that seraphis/jamtis might not 03:26:55 Mymonero is not a browser extension and the wallet hasn't been maintained in forever (https://github.com/mymonero/mymonero-web-js) 03:28:53 On this note, I don't like seraphis/jamtis potentially not supporting hardware wallets. What happens to people who have cold storage with a ledge since 2014? Will they lose their funds or be force to throw out their hardware wasting their money? 03:29:27 On this note, I don't like seraphis/jamtis potentially not supporting hardware wallets. What happens to people who have cold storage with a ledger since 2014 for example? Will they lose their funds or be force to throw out their hardware wasting their money? 03:31:58 I know ledger didn't support monero on release and it wasn't out 2014, but this doesn't invalidate my point. If a hardware wallet can become obsolete over time with monero, doesn't this mean monero is not backwards compatible? 04:31:56 > doesn't this mean monero is not backwards compatible? 04:32:29 Of course it's not backwards compatible. That's the definition, the whole purpose of a hardfork, to be *not* backwards compatible, no? 04:32:37 Or maybe I misunderstand 04:33:42 Well, of course not the whole purpose, but one very important property 04:34:22 Otherwise it would be a "softfork", and we don't do those here with Monero :) 05:01:37 <321bob321:monero.social> hardfork every 2 months we do :) 07:25:48 bufo:monero.social: mymonero is under active development, as far as I know mymonero users seeds wasn't bruteforced (weak crypto knowledge by devs ) and simiilar issues unlike other wallets 08:03:11 Unfortunately we have choice between full privacy (maybe with Forward secrecy) and supporting hardware wallets, that represent maybe 1% of the users. I agree this is very annoying for hardware users because they'll have to know that they should move their funds to a software wallet before the hard fork. A proper warning months prior to the hard fork should be made, but there are n o guarantees everyone will hear about it 08:03:29 or* 08:03:58 Citation: days since user reports v17.3.2 gui not working 08:21:38 Samourai Wallet co-founder pleads not guilty, released on $1M bond 08:22:16 Uniswap Labs received a Wells notice — a letter informing a company or individual that the United States Securities and Exchange Commission is planning to bring an enforcement action against them. 08:25:23 https://www.elliptic.co/blog/our-new-research-enhancing-blockchain-analytics-through-ai 09:10:54 for visibility: featherwallets incident report (tldr due to reasons explained in the report, there was a unannounced hard fork and everyone has to update to the latest) https://featherwallet.org/changelog/ 09:13:17 <321bob321:monero.social> Critical y2k bug fix 09:20:26 nice write-up ! 09:21:35 i know localmonero recommend feather to users so alex should be aware 09:28:12 Alex | LocalMonero | AgoraDesk: i know LM recommend feather, just making sure you are aware of the incident report @ https://featherwallet.org/changelog/ 09:29:15 Morpheus: >Dan 🤐 | alderman (Is not the man & Braxman Tomsparks Advocate ) noticed your node(s) are offline 09:29:44 <123bob123:matrix.org> Naughty 09:37:39 whats the best VPS for a pruned node? 10:05:32 Hey man 10:05:57 The node ran out of space in disk 10:06:06 I have to deploy another one 12:56:39 I think you underestimate the size of this issue. Hardware wallet users are likely the ones with the most monero even if they represent a small proportion of monero users. If these users are forced to use a software wallet instead, these users will probably just switch coins out of mistrust for monero 12:57:38 What makes something like bitcoin great is despite all its weaknesses, someone who stored their coins in a hardware wallet a decade ago can guarantee their coins will be there today. If what you propose is true, this is disastrous 13:07:24 I refer to hardware wallets here. With previous hardforks there were no issues with keeping your monero on a hardware wallet and updating, but with seraphis/jamtis it's looking like users will have to change wallets otherwise their coins are gone. I think this is disastrous as there will be users who will not touch monero in years to come and if these people return to see their wa 13:07:25 llets be obsolete, there will be no other option than to leave monero for something more reliable... 13:41:46 bufo: Who told you hardware wallets will not be supported in the next network upgrade? Section 5.2 of https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf says 13:41:59 > Hardware wallets maintain their support due to not needing to perform the membership proof, solely the Generalized Schnorr Protocol after the fact. The Generalized Schnorr Protocol is smaller than the current CLSAG proofs, and is accordingly assumed to be well within the allowed memory footprint. 13:42:27 I'm talking about jamtis and @rbrunner7:monero.social said hardware wallets may not be supported 13:42:54 It's good to know fcmp++ will support hardware wallets 13:43:10 When did he say that? 13:44:57 https://github.com/seraphis-migration/wallet3/issues/41 13:45:00 https://matrix.monero.social/_matrix/media/v1/download/monero.social/gmuKuexVFQUfvZHqagTrxYhM 13:46:10 In #no-wallet-left-behind:monero.social too 13:48:46 It sounds like rbrunner doesn't know if current hardware wallets will be supported since the specifications of the RAM of each model of hardware wallet hasn't been collected. I would agree that this issue should be cleared up. I ctrl-F for a reference to hardware wallets in the "official" Seraphis paper and I couldn't find anything: https://github.com/UkoeHB/Seraphis 13:49:36 Is there anything on how much expected hardware specs seraphis requires? Ram, cpu, ...? 13:49:50 The firmware or apps of hardware wallets need to be updated with Monero hard forks usually since the transaction format changes. Hardware wallets needed to be updated for the August 2022 hard fork. 13:51:37 There are two references to hardware wallets here: "Seraphis Address Schemes" https://github.com/monero-project/research-lab/issues/92 13:52:42 Here are some performance benchmarks for Seraphis, but these are mostly verification time. And they might be moot because FCMP++ would have different performance numbers: https://github.com/monero-project/research-lab/issues/91 13:53:47 Verification time is the time it takes a node to verify the validity of a transaction. Proving time is the time it would take a machine to create the proofs in a transaction it is construction AFAIK. 13:55:00 Useful resources. Thanks for these 14:06:36 I don't see any reason why hardware wallets should not work with FCMP/Jamtis. They will obviously need a firmware update. 14:33:27 bufo: tevador is the main designer of Jamtis. So probably hardware wallets will be supported by the foreseeable network upgrades, but we should confirm that each model has enough RAM to do the proving steps inside the device. 14:36:47 When I wrote the following almost 1.5 years ago in that linked post I was merely speculating about possible problems with hardware wallets, and at least as far as I am concerned no new hard knowledge came to me in the meantime: 14:36:54 > How it looks with hardware wallets is hard to say. They probably don't have problems already with merely addresses, but maybe with firmware capacity to hold the code for supporting Seraphis and Jamtis in general. 14:39:35 In a way, it's only natural. One of the crucial parts of Monero support in hardware wallets is in the wallet's firmware. The Monero devs (usually) don't write such firmwares or parts thereof, the wallet manufacturers do. Seems to me their devs would be in a better position to answer with authority - if it was clear already exactly what they have to implement. 14:40:43 And things on that front are quite a bit in flux right now ... 18:00:12 bufo: Hardware wallets will have to update to it. The new proof should comparable in time/space complexity to the current CLSAG (so any current HWW should remain possible). 18:00:30 If a HWW doesn't update, you'd extract your keys and restore it on a wallet which did update. 18:01:09 SyntheticBird: We absolutely do not have a choice of one or the other and everyone with a non-trivial amount of cryptocurrency should have a HWW. 18:01:32 If we dropped HWW support, my job would be a lot easier. Part of the challenge was making a design still possible on a hardware wallet. 18:01:37 It was a prerequisite for any proposal. 18:02:50 The Seraphis proposal moves to JAMTIS and would raise memory usage due tot he additional keys. That should be manageable. If it does cross a threshold, sending to JAMTIS would no longer be possible. 18:03:05 Under the FCMP++ proposal, old addresses remain fully usable. HWW would just make those/only send to those. 19:01:00 I guess I’ve never looked into that part of the JAMTIS proposal—how is migration of old addresses to new addresses supposed to work? Would you have to type in the legacy address info into something that would convert it to JAMTIS? 19:05:16 selsta part-time monero development (3 months) has moved to funding! https://ccs.getmonero.org/proposals/selsta-13.html 19:10:23 preland: Your wallet app would tell you the new Jamtis addresses. You need secret keys to derive them; you can't convert a current address into a Jamtis address only based on the info that is contained in the current address itself. 23:05:21 New wallets would display new addresses 23:05:26 Old wallets could still be sent to 23:05:50 (if under the FCMP++ proposal, Seraphis is a hard migration) 23:07:59 There isn't a migration of old addresses to new addresses. There's just both addresses, and a new protocol to send to addresses (old or new, handled entirely internally to the wallet).