onledger.net
6.8K posts
@offledger
on ledger @ xahau ledger - All photographs of mine are copyrighted © and no permission is given for their use.
🚀 Running Evernode natively! @EvernodeXRPL isn’t just theory... it runs. Client fully synced, contract execution enabled, real HotPocket node live 🔥 Let’s bring ideas to life on the most advanced decentralized compute layer. #Evernode #Xahau #XRPL #DePIN #HotPocket
Evergram is live. Fully encrypted messaging for Web3. No central message database. End-to-end encryption by default. Try it via Xaman xApp or web: evergram.app
About three weeks ago I posted an amendment that would resolve a locked-out multi sign setup, causing one of our community members to be locked out of 50k XRP. If we allow tech to bail on users this way, we're failing the ecosystem (in my opinion). Three weeks later not much has happened. There's a proposal for a different approach, that (imo) doesn't cut it. Why? There are a few approaches to fixing XRPL accounts that get stuck because their signers independently changed their own key setup: - Ban invalid signer configs at transaction time. Doesn't work. The lockout happens across multiple accounts over time, each transaction was valid when submitted. You can't prevent it without restricting what people do with their own keys. - (Counterproposal by Ripple staff) Let a disabled master key still work as a signer on someone else's account. Gets the job done for already-stuck accounts but breaks a core assumption: disabled means disabled. If you turned off your master key because it leaked, you don't want it suddenly usable again in some other context. - (Our approach) Nested multi-sign. Walk the signer-of-signer chain recursively, detect cycles, relax quorum where needed. Recovers stuck accounts without changing what "disabled" means. DoS concerns are real but solvable with a global signature verification cap per transaction (Batch already allows 288 sig verifications today, nested multi-sign caps at 64). I strongly believe option 3 is the right path. It's the only one that actually fixes things without weakening security guarantees. PR: github.com/XRPLF/rippled/… XLS: github.com/XRPLF/XRPL-Sta… ⏳
About three weeks ago I posted an amendment that would resolve a locked-out multi sign setup, causing one of our community members to be locked out of 50k XRP. If we allow tech to bail on users this way, we're failing the ecosystem (in my opinion). Three weeks later not much has happened. There's a proposal for a different approach, that (imo) doesn't cut it. Why? There are a few approaches to fixing XRPL accounts that get stuck because their signers independently changed their own key setup: - Ban invalid signer configs at transaction time. Doesn't work. The lockout happens across multiple accounts over time, each transaction was valid when submitted. You can't prevent it without restricting what people do with their own keys. - (Counterproposal by Ripple staff) Let a disabled master key still work as a signer on someone else's account. Gets the job done for already-stuck accounts but breaks a core assumption: disabled means disabled. If you turned off your master key because it leaked, you don't want it suddenly usable again in some other context. - (Our approach) Nested multi-sign. Walk the signer-of-signer chain recursively, detect cycles, relax quorum where needed. Recovers stuck accounts without changing what "disabled" means. DoS concerns are real but solvable with a global signature verification cap per transaction (Batch already allows 288 sig verifications today, nested multi-sign caps at 64). I strongly believe option 3 is the right path. It's the only one that actually fixes things without weakening security guarantees. PR: github.com/XRPLF/rippled/… XLS: github.com/XRPLF/XRPL-Sta… ⏳
