<h​ardenedsteel:monero.social> PurpleI2P/i2pd_docs_en #95

<h​ardenedsteel:monero.social> reviews needed

<h​ardenedsteel:monero.social> everything looks good to me but I haven't tried

<3​21bob321:monero.social> github.com/HardenedSteel/i2pd_docs_…ob/patch-1/docs/tutorials/monero.md

<3​21bob321:monero.social> let me send to the banned one

<b​ufo:monero.social> Are there any browser wallets like metamask but for monero?

bufo nope.

<t​ired_turtle:monero.social> MyMonero 🤔?

<b​ufo:monero.social> Will the fcmp++ hardfork support hardware wallets? I know that seraphis/jamtis might not

<b​ufo:monero.social> Mymonero is not a browser extension and the wallet hasn't been maintained in forever (github.com/mymonero/mymonero-web-js)

<b​ufo:monero.social> 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?

<b​ufo:monero.social> 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?

<b​ufo:monero.social> 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?

<r​brunner7:monero.social> > doesn't this mean monero is not backwards compatible?

<r​brunner7:monero.social> Of course it's not backwards compatible. That's the definition, the whole purpose of a hardfork, to be *not* backwards compatible, no?

<r​brunner7:monero.social> Or maybe I misunderstand

<r​brunner7:monero.social> Well, of course not the whole purpose, but one very important property

<r​brunner7:monero.social> Otherwise it would be a "softfork", and we don't do those here with Monero :)

<3​21bob321:monero.social> hardfork every 2 months we do :)

b​ufo: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

<s​yntheticbird:monero.social> 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<clipped messa

<s​yntheticbird:monero.social> o guarantees everyone will hear about it

<s​yntheticbird:monero.social> or*

Citation: days since user reports v17.3.2 gui not working

Samourai Wallet co-founder pleads not guilty, released on $1M bond

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.

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) featherwallet.org/changelog

<3​21bob321:monero.social> Critical y2k bug fix

nice write-up !

i know localmonero recommend feather to users so alex should be aware

<p​lowsof:matrix.org> Alex | LocalMonero | AgoraDesk: i know LM recommend feather, just making sure you are aware of the incident report @ featherwallet.org/changelog

<p​lowsof:matrix.org> Morpheus: >Dan 🤐 | alderman (Is not the man & Braxman Tomsparks Advocate ) noticed your node(s) are offline

<1​23bob123:matrix.org> Naughty

<r​4v3r23:monero.social> whats the best VPS for a pruned node?

<c​ryptomorpheus_:matrix.org> Hey man

<c​ryptomorpheus_:matrix.org> The node ran out of space in disk

<c​ryptomorpheus_:matrix.org> I have to deploy another one

<b​ufo:monero.social> 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

<b​ufo:monero.social> 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

<b​ufo:monero.social> 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<clipped message>

<b​ufo:monero.social> llets be obsolete, there will be no other option than to leave monero for something more reliable...

<r​ucknium:monero.social> bufo: Who told you hardware wallets will not be supported in the next network upgrade? Section 5.2 of github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf says

<r​ucknium:monero.social> > 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.

<b​ufo:monero.social> I'm talking about jamtis and @rbrunner7:monero.social said hardware wallets may not be supported

<b​ufo:monero.social> It's good to know fcmp++ will support hardware wallets

<r​ucknium:monero.social> When did he say that?

<b​ufo:monero.social> seraphis-migration/wallet3 #41

<b​ufo:monero.social> matrix.monero.social/_matrix/media/…ero.social/gmuKuexVFQUfvZHqagTrxYhM

<b​ufo:monero.social> In #no-wallet-left-behind:monero.social too

<r​ucknium:monero.social> 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: github.com/UkoeHB/Seraphis

<b​ufo:monero.social> Is there anything on how much expected hardware specs seraphis requires? Ram, cpu, ...?

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> There are two references to hardware wallets here: "Seraphis Address Schemes" monero-project/research-lab #92

<r​ucknium:monero.social> 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: monero-project/research-lab #91

<r​ucknium:monero.social> 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.

<b​ufo:monero.social> Useful resources. Thanks for these

I don't see any reason why hardware wallets should not work with FCMP/Jamtis. They will obviously need a firmware update.

<r​ucknium:monero.social> 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.

<r​brunner7:monero.social> 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:

<r​brunner7:monero.social> > 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.

<r​brunner7:monero.social> 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.

<r​brunner7:monero.social> And things on that front are quite a bit in flux right now ...

<k​ayabanerve:matrix.org> 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).

<k​ayabanerve:matrix.org> If a HWW doesn't update, you'd extract your keys and restore it on a wallet which did update.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> It was a prerequisite for any proposal.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> Under the FCMP++ proposal, old addresses remain fully usable. HWW would just make those/only send to those.

<p​reland:matrix.org> 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?

selsta part-time monero development (3 months) has moved to funding! ccs.getmonero.org/proposals/selsta-13.html

<r​brunner7:monero.social> 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.

<k​ayabanerve:matrix.org> New wallets would display new addresses

<k​ayabanerve:matrix.org> Old wallets could still be sent to

<k​ayabanerve:matrix.org> (if under the FCMP++ proposal, Seraphis is a hard migration)

<k​ayabanerve:matrix.org> 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).