Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank

Profile Information

  • Gender
    Not Telling
  • Ripple Address

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The only thing I can think of is that your validator is somehow unable to reach https://vl.ripple.com/ to download the updated validator list. (The previous bug was that servers would sometimes give up even trying to fetch the list; that should be fixed, but the symptom can occur if your server is still unable to get the list despite trying.) From the validator server, are you able to connect to the site to fetch the list manually? For example: wget https://vl.ripple.com/ If so, it should be possible to load the validator list from file as a temporary workaround. Here's an example from the PR that added that feature: https://github.com/ripple/rippled/pull/2744/files#diff-48a8459379995a830937c804745efe14R34 You'll still want to figure out why your validator isn't able to download the latest list (and switch it back to downloading the list automatically), though.
  2. Hi Bob. Welcome back, and congrats on kicking cancer's ass. It's been a while since we've talked, and that's a shame. I'm looking forward to talking more about the future of money and how we can make it good.
  3. No, he's talking about the original "Ripple" idea where people just track how much money they owe each other (in whatever denominations) and use those to pay their debts rather than exchanging physical assets or centrally-issued (digital or otherwise) notes. A core idea behind Ryan Fugger's "Ripple" was that you could net out a bunch of these payments with powerful computer system. The Ripple (now XRP) ledger built on top of this with the idea that if there was a generic token in the system, you could use that to automatically bridge all the gaps in credit.
  4. That is pretty sweet! I think you could improve usability if you provided links to highlight some of the more active markets. (Naturally, that's something that you'd have to maintain over time, but I think it would go a long way to getting people to seeing what it does.
  5. Not to encourage bumping ancient threads, but... I don't know what this means. https://developers.ripple.com/multi-signing.html Any given address can have up to 1 SignerList, which contains 1 to 8 signers. Each signer has a weight from 1 to 65535. The list also has a quorum with a value from 1 to 4294967295. The sum value of the signers' weights must be equal or higher than the list's quorum. If you disable the master key, then you'll only be able to use the multi-signing list (if you've set one) and regular key (if you've set one). See the "Cryptographic Keys" article for more info.
  6. Good catch. Fix forthcoming: https://github.com/ripple/ripple-dev-portal/pull/522
  7. I'm overjoyed that these docs are inspiring the community to start working on similar efforts. There's a lot of room for helpful content out there! You guys are doing great work. I plan to continue to lead by example here, and I do have access to some professionals at Ripple, but I'm also very excited to see what the community puts together. Let's BUIDL together!
  8. With just a few clicks, you can experience the process of sending (test net) XRP, alongside code samples and details of how to use RippleAPI for JavaScript to do the same: https://developers.ripple.com/send-xrp.html As always, we welcome your feedback and questions.
  9. Thanks for doing this research. It's useful for me to know that 5 characters is a good cutoff for making collisions very unlikely. I'll probably go on to use that as my convention in documentation. (I assume the 5 characters is not counting the starting "r" which is a freebie.)
  10. For the thing you're talking about, I think using a Webfinger service might actually be appropriate. (You could, potentially, advertise the webfinger service's URL in your xrp-ledger.toml file.) I think we'd want some more specs around things like URIs and how to structure the results, but this is all stuff I explored along with people like Bob Way and Steven Zeiler circa 2015, so it's not like it's untread ground. I still have a bunch of the stuff we drafted up back then, which I could share and we could update with the community's feedback but I'd like to take things one step at a time and get a good consensus around this TOML document first.
  11. I've created a proposal for a file that would replace the old "ripple.txt" way of reporting information about how you use the XRP Ledger. (For reasons including the fact that "XRP" isn't "Ripple"!) If adopted, I expect this could be a key piece in how validator operators verify their identity, and may also be useful for client applications for various other purposes. (For example, if the owner of an XRP Ledger address is verified, client apps could show provided contact info or description alongside that address.) For people who run validators or actively develop tools and applications on top of the XRP Ledger, your feedback is very important because this spec doesn't serve a purpose unless you find it useful! If you fit that description, please take a look and provide your input on the draft specification here: https://github.com/ripple/ripple-dev-portal/pull/507
  12. It takes that long to send your XRP to the exchange. It typically takes the exchange longer before they actually credit you for doing so. It could be minutes or hours before they've actually processed your deposit and your XRP is available for trading within the exchange's systems, depending on how they manage things. Most of this is just fixable slowness (especially for exchanges used to dealing with Bitcoin-scale confirm times) but there's also some legitimate caution there, to delay the speed at which scammers can flip assets and run.
  13. I think that "proposal" and "candidate set" are basically synonymous here. Have you read the "Intro to Consensus" article in the dev portal? That might be a more up-to-date, approachable way to learn about consensus. It has some diagrams you may find enlightening, like this one:
  14. ... and that means the Known Amendments page has been updated. rippled 1.2.0 will introduce (at least) 3 new amendments, which (if enabled following 2 weeks of support from 80+% of validators) introduce transaction processing changes. In this case, the changes are pretty small: fixTakerDryOfferRemoval fixes a bug where dry offers sometimes weren't properly removed when autobridging. Thanks to GitHub user demonstefan for contributing the code that eventually became this amendment! fix1578 makes fill-or-kill offers return a new tecKILLED code (as requested on this very forum) when they're killed. It also makes TrustSet transactions fail when they can't set the NoRipple flag, instead of "succeeding" without changing the flag. Both of these changes are meant to make the transaction engine just a little less tricksy. MultiSignReserve reduces the reserve requirement for signer lists so they occupy less XRP for just sitting there. Stay tuned for more information about the upcoming release and the features in it!
  • Create New...