Reddit Posts
Mentions
Since it works on other browsers and with other wallets, your device and firmware are fine, so the "update Ledger Live" advice won't touch this one. The fault is specifically in the Chrome <-> Rabby WebHID handshake. Two things to try, in order: 1. Another extension is probably grabbing the Ledger first. Only one Chrome extension can hold the HID device handle at a time, so if MetaMask or any other wallet extension is enabled, it can claim the Ledger before Rabby gets a chance. Disable every other wallet extension, fully quit Chrome (not just the window), reopen, then connect in Rabby. 2. If that doesn't do it, the stored HID permission for Rabby is likely stale. Go to chrome://settings/content/hidDevices, remove the Ledger entry, then reconnect so Rabby re-requests the device fresh. If both fail, spin up a clean Chrome profile with only Rabby installed. That isolates it from any extension conflict in about a minute and tells you instantly whether it's a conflict or something else. And make sure the Ethereum app is open on the Ledger with blind signing on when you hit sign.
What you're describing is essentially a DIY version of the FIDO2/WebAuthn standard. While the idea of using a simple ESP32 for signing is great for hobbyists, there are a few critical reasons why this isn't the industry standard yet: 1. Secure Enclaves vs. General Purpose MCUs: A standard ESP32 stores private keys in flash memory, which is vulnerable to physical dumping. Professional hardware keys (like YubiKey) or Ledger/Trezor devices use Secure Elements (EAL5+) that are physically tamper-resistant. 2. Standardization & Fragmentation: We already have WebAuthn for "gasless" logins. The issue isn't the tech, but the adoption. Each site would need to implement support for your specific serial command protocol unless it follows existing HID (Human Interface Device) standards. 3. The "On-Chain" Necessity: Web3 requires on-chain "login" (or rather, wallet connection) not for the sake of the login itself, but for state verification. If a dApp needs to know you own a specific NFT or have a certain balance to grant access, it *must* check the blockchain. 4. User Experience: Asking an average user to plug in a microcontroller and manage serial commands is a high barrier to entry compared to a simple FaceID/TouchID prompt (which also uses the device's internal Secure Enclave via WebAuthn). It’s a solid concept for a sovereign setup, but for mass Web3 adoption, the industry is moving toward Account Abstraction (ERC-4337) and Passkeys to hide this complexity entirely.
If I’m not mistaken, wouldn’t it be the same as when they confiscated all of the gold? If you wanted to be a sucker and hand it over, you did. Some people gave up some of it. Some gave up none and HID it.
I don't think this take is true. If I remember correctly, Satoshi used the random number generator from OpenSSL. He didn't write his own. **Given that:** The broken algorithm that was exposed by Snowden, Dual\_EC\_DRBG, was not accepted by the cryptography community and they were skeptic about it. I mean, it's really dumb of the NSA to keep the guessing of a random number path predictable based on 16-bit unknowability + 2 constants undisclosed. This is nothing new, since DES encryption, the cryptography community has known the idea of "nothing-up-my-sleeve number", and IBM was criticized for their unexplained choice of a random table in DES encryption procedure, which was done for an honest reason, to prevent Differential Cryptanalysis as discovered by Shamir. Same problem applies to Dual\_EC\_DRBG, where some unknown numbers and unexplained were pulled out of NSA's butt and no one explained it... and people were supposed to just take it for granted as secure? I think only noobs fell for this. OpenSSL didn't, especially that OpenSSL used full entropy to generate random numbers (and HID wallets didn't exist). So this idea that Satoshi single-handedly avoided the broken "randomizer" is not really based on reality. In fact, Satoshi has done a few things that come from lack of understanding of cryptography, including using RIPMD160 to shorten the Base58 address after SHA256. Just cropping SHA256 would've been enough. I don't blame him though, it doesn't really matter. He did a good job overall.
No quiero shillear nada. Ahora mismo ando metido en KIRA, NINJA, FI, HID, CUDOS. 2 memes, 1 con proyecto de futuro y las otras dos proyectos con mucho riesgo. Si sale bien pues ale… sino pues ggwp xD
With HID/hardware wallets, what is the definition of a wallet in this case? Just the single address that the contract is interacting with, or literally the whole wallet with all derived addresses? For example, lets say you are using a Ledger wallet for all your ETH/ERC20 funds. If a malicious contract with unlimited allowance would be signed for DeFi token A on ETH address #1, could it potentially risk your funds on all ETH addresses (#2, #3, #4.. etc.) that are derived from the same Ledger seed, or would the risk be contained for just the tokens on ETH address #1?