Search the Community

I was going through the ledger looking at how Ripple.com sets up their accounts. Many of their accounts have 4 of 8 signatures required and master key disabled. Hypothetically, if the first four signers were all compromised, the original owners could still use the last four signers (5-8) to change signers 1-4. In this rare event, what's to stop thieves with signers 1-4 from removing/altering signers 5-8, essentially locking out the original owners completely? I speculate that they have signers 5-8 locked up in safes somewhere as a backup last resort and a 50% quorum so that they could 'save' the account in the event of 1-3 of the 'active' signers being compromised. As I understand it, once the master key is disabled and multi-sign is the only way to transact, there is no way to re-instate the master key ever. I've been looking through xrpl.org but there's zero mention of recovering a master key once it's disabled. Is this accurate?

I am trying to use Ripple multi-sig. I have followed docs https://xrpl.org/set-up-multi-signing.html, https://xrpl.org/send-a-multi-signed-transaction.html. I have used ripple testnet for all these tests. I am able to perform tasks like: Create accounts and add them as signers to one account Disable master key of the account in which I added. Finally when I try to withdraw funds from this account using signatures from these signers, I get error "error": "internal", "error_code": 71, "error_message": "Invalid signature.", The json which I tried to submit is provided. I have also tried to submit as blob using submit command which creates error "error": "invalidTransaction", "error_exception": "fails local checks: Transaction has bad signature.", { "method": "submit_multisigned", "params": [ { "tx_json": { "TransactionType" : "Payment", "Account" : "rNvoW4LG6wXVZm6RXbo7qyNRmQj4TNUmTz", "Destination" : "rsuUjfWxrACCAwGQDsNeZUhpzXf1n1NK5Z","DestinationTag": 384725397, "Amount": "1000000", "Fee": "1200", "Flags": 2147483648, "Sequence": 5,"SigningPubKey": "","Signers" : [ { "Signer" : { "Account" : "rGtMsMktyGKC8QeTb6phSSYLG7JWaB1Dir", "SigningPubKey" : "020d4888ba4f8cbb96fa5a2eead2e6bbc90ba94cadae29a4aebe2a7cc62c96b278", "TxnSignature" : "3045022100AC5BBDAAB33F50CEA6DB89DFC65CCDF306B346B3A5975AF8344260548870F3B9022079EEF9C2BFDD0930C6FC72D88DD48D80D97531F9A8349C5B6372E979D76FF603" } }, { "Signer" : { "Account" : "rhNfCZXnqoX35ndyhYgHxhjPy2xs5rg9Lq", "SigningPubKey" : "02b0f22c98a07257f0251d678a23be8e00b238180dde29a71fc3fabfe17740a5cc", "TxnSignature" : "3045022100F1651743DE011E213623C8DB46D35ED89088D0563CE7C399A45AD4BDB349B63002207255ADA9385538C3589D79DF814F9D93836908A09C02E73CDE5303E865963211" } } ]} } ] }

Blog URL: https://xrpcommunity.blog/reaching-out-to-those-abandoned-by-traditional-banking/ Billions of adults are considered un-banked. I discuss ILP's role in solving this problem & cover the latest XRP news in today's blog: 𝗪𝗵𝗼 𝘁𝗼 𝗙𝗼𝗹𝗹𝗼𝘄: To keep up to date on how fintech innovations are connecting the un-banked, I recommend following Chris Larsen and Mojaloop. 𝐑𝐢𝐩𝐩𝐥𝐞 𝐍𝐞𝐰𝐬: Modern Consensus interviews Forte's Kent Wakeford, the former COO of Kabam, about the new collaboration with Ripple. 𝐗𝐑𝐏 𝐍𝐞𝐰𝐬: Wietse Wind publishes a handy tool for composing multi-sign transactions; @baltazar223's Weekend Project inspires donations to the XRP Community Fund; @SchlaubiD makes a program available for download that enables sending XRP through MS Outlook; Bithomp adds a form to enable users to report suspicious or known scam/fraud XRP wallet information; DigitalNomadInvestor offers new XRP designs available for sale through his swag store; Two new exchanges indicate they will list XRP; and the "XRP Torch" was just passed from the US to Japan! I hope you enjoy the read: Please feel free to share my blog with a friend or share it on any other platform - and thanks for doing so! My blog announcement links on other platforms: Twitter Reddit r/Ripple Reddit r/CryptoCurrency Reddit r/CryptoMarkets Reddit r/xrp Reddit r/RippleTalk Reddit r/alternativecoin Bitcointalk - alt coin sub forum Bitcointalk - XRP speculation thread

Just today I published the documentation for a bunch of new feature stuff that's coming in rippled 0.31.0. (Right now we're still tracking down the last few bugs in the release candidates, but the feature set is finished and the release will be out probably any day now.) It's been a long road for multi-signing in particular, with the first preview promising that it was "coming soon" as of March 24, 2014. Yeesh! But this time, we really mean it: multi-signing is getting real. We're not... quite... there yet, though, and part of the reason is that 0.31.0 is the first time we're going to truly use the Amendments system for rolling out new network features in a decentralized fashion. This is a big step in our roadmap towards encouraging a decentralized web of trust in the validation network, because it means that the network will be able to smoothly roll out new features without interruptions or a central authority managing them. You can read more about Amendments on the Ripple Dev Center. But! There's one other thing before Multi-Sign happens, and that's an amendment called "Fee Escalation." We haven't talked it up as much, but this change has also been in a long time coming. A while back, you may recall that the cost to send a transaction increased from a typical price of of 10 drops to 10,000 drops of XRP. That's because we realized that, with the network as it was, it had become possible to intermittently DDoS the network without spending a fortune in XRP -- the transaction cost reacted slowly enough to changes in conditions that the network was already in trouble by the time the costs became unbearable. For many months, we've been running our validators with a band-aid fix, with the "load" multiplier artificially cranked up to 1000× in order to maintain network stability. That's why the first Amendment we support will be Fee Escalation -- a change that makes it actually possible to pay a higher transaction cost to make sure your transaction gets processed sooner. Now, when there are a lot of transactions in the current ledger, the server will start queuing up additional transactions for the next ledger instead of trying to squeeze them all in at once -- and the order will be determined by how much XRP those transactions destroy. Not only that, but you can still squeeze into the current open ledger if you pay even more XRP -- but the requirement scales exponentially, so it won't be worth it for long! The long and short of it is that the network should be more resilient against DDoS attacks, while affording more flexibility in the amount of XRP you spend sending transactions (based, presumably, on how urgent your transactions are). With any luck -- and this is not a guarantee, but I'm pretty sure it'll happen -- we'll be able to turn off the artificial "1000×" load knobs and return the minimum transaction cost back down to a truly miniscule amount. See the "Open Ledger Cost" section in the documentation for the details. That finally brings us back to Multi-Signing. It's going to be a few weeks out even after the release gets finalized, so you'll have plenty of time to figure out how it works in order to start multi-signing the instant the feature goes live. In fact, if you're really excited to try it out, you can practice how to multi-sign a transaction using rippled in stand-alone mode. You can also test out other stuff in stand-alone mode, without having to interact with the real network, whether you want to replay old ledgers or test out new features. (Stand-alone mode is not a new feature, but the new documentation should make it much easier to use.) This has been a big project (over 40 commits just to documentation!) and there are a few more changes not even mentioned here. (There might even be some minor improvements to rippled 0.31.0 that haven't made their way into the docs yet.) So, let's not quite declare victory before the release is live -- but get your funny hats and party poppers ready, because version 0.31.0 is going to be a big deal. As always, feedback is deeply appreciated, and I'm glad to offer clarifications for anything that doesn't make sense to you. And, just like rippled itself, our documentation is open-source, so you don't have to be a Ripple employee to contribute!