Jump to content

mDuo13

Ripple Employee
  • Content Count

    447
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by mDuo13

  1. Two announcements to the dev blog today: rippled 1.2.4 has been released. Yes, it's another hotfix. This one should hopefully fix the validator list expiry problem noted in this thread once and for all. The MultiSignReserve amendment is now enabled, so you can go and update your signer lists to save a few sweet, sweet XRP. Depending on how many signers you have on your multi-signing list, this cuts the reserve requirement down by 10 to 45 XRP! (Used to be 15-50 XRP; now it's always 5 XRP.)
  2. To my understanding, validators only send "yes" votes, so a missing vote means "no." That's not been true for a few versions now. The SHAMapV2 amendment is commented out because of this (same w/ OwnerPaysFee and Tickets). We've had numerous discussions within Ripple on how we could improve the amendment voting process, but it's a more challenging problem than most people initially think. If you change the default to "no", then even minor fixes probably won't get enabled without a lot of collective effort. Validator operators might be more active than gateway operators, who are staggeringly nonresponsive regarding new features¹, but it's still a big ask to get everyone to go in and manually add "fix1XYZ" to their configs and restart every time there's a release with fixes to transaction processing. If you add an "abstain" option (either explicit or treating non-votes as abstentions) then you have to figure out how that affects the necessary quorum for a majority. If abstentions are subtracted from the necessary total, then it could take very few explicit votes to get a majority, which makes voting "abstain" functionally very close to voting "yes". But if the necessary total doesn't change with abstentions, then voting "abstain" is identical to voting "no". The current system works very well as long as all amendments in the code that validators are running are fully implemented and sane. (Historically, Ripple hasn't been great about this, as evidenced by SHAMapV2. In the time since adding more external validators to the list, we're being much more careful about it.) Even if validators update without thinking, the two-week approval process provides a safeguard for validators to see, investigate, and potentially vote against new amendments they're not ready for. On top of that, going forward, Ripple aims to publish information earlier in the process of developing new amendments, so what happened with Checks won't be the norm. I do agree that "veto" is not really the right word for the setting in the config file, when it really means "vote no". If we do an update to the config file format, I'll push to change it to something a bit more intuitive. ¹ For example, when DefaultRipple got added, there was at least one gateway who never enabled it despite continuing to operate for quite a while, even after being contacted several times. Because of the way the NoRipple settings worked out, their legacy customers were still able to send and receive IOUs as normal, but new customers couldn't send to other new customers because the gateway was enabling NoRipple by default on new trust lines.
  3. I don't have the answers here, but if you're trying to look up an AccountRoot object, be sure you include the space key 0x0061 before hashing. (See AccountRoot ID Format and the corresponding pages for other object types. The Hash Prefixes table may also be useful for figuring out other hashes, though if you have the hash itself, that already takes it into account.)
  4. https://developers.ripple.com/blog/2019/corrections-to-data-api-xrp-charts-metrics.html tl;dr: yep, it was a Data API problem overcounting the number of ledgers. We've reprocessed the data so it should now show the correct metrics.
  5. Thanks, fixed the link. As for the BUIDL link, honestly, that article was the best explanation I could find for the "BUIDL" meme. (Seriously, get me a better one and I'll replace it.)
  6. The Ripple Dev Blog has moved. The new blog location has been inaugurated with a feature article about Interledger, and we plan to continue posting new blog articles at a higher rate than we previously have. *crosses fingers* Check out that Interledger article here: https://developers.ripple.com/blog/2019/interledger-checkin.html If you have any technical topics you'd like us to cover or other things you'd like to see from the Ripple Dev Blog, feel free to reply here and we'll do what we can to address them. (As usual, we cannot provide financial advice, forecast moon when the price of XRP, reveal confidential info about partners, comment on litigation, etc.) We can and are happy to talk about open source technology, the XRP Ledger's many features and potential uses, and provide insight into where Ripple's devs see fintech going in general over the next few years.
  7. I find that developers who have the most experience building stuff on the XRP Ledger tend to share their pet projects on this forum, on Twitter, and on Reddit. So that's one way to find them. But in general, developers with blockchain / DApp development experience are in very high demand and are pretty rare. In my experience, it's more effective to hire developers with good general purpose skills and experience who are eager to learn new things. Many of the devs I've met at Ripple didn't have much XRP Ledger experience before they were hired, but came from various technical backgrounds and learned the specifics on the job. Some background skills that can come in handy: Programming languages: JavaScript, C++, or others, but those two are the best for XRP Ledger development. I've seen some cool things in Ruby, Python, and C# as well so I wouldn't count almost any language out. Economic theory / understanding of the financial system. Most devs don't have much understanding of this, but more are learning. Stuff like understanding what ACH and SEPA are, what are remittances, what are securities, what's front-running, etc. This is important for roles other than devs, too—One of the most important challenges for any money/cryptocurrency/financial business is understanding the laws that are relevant to your jurisdiction well enough to make a reasonable argument that you are complying with them. Information security. Understanding how to use digital signatures securely, how to evaluate different algorithms, how to manage keys and passwords safely, etc. Elliptic curve cryptography is cool, but you don't necessarily need to know that much about the innards of the algorithms, just enough to evaluate which ones to use when and how. Scalable, robust system architecture and design. Not everything belongs on a blockchain. Usually, the best architecture for a given project uses some more "traditional" technologies like databases. So understanding that, and how to balance and scale that stuff is very relevant. User interface design / user experience testing. If a human is going to interact with your software at some point, you should have an idea of how to make their experience as positive and effective as possible. Frequently that means testing how users interact with it, designing with specific user goals in mind, etc. All manner of soft skills. You need to be able to communicate with your colleagues and others outside your business, to share what you're working on, provide constructive feedback and encouragement, to coordinate and build agreement on how to connect pieces that are being built by different people or companies. Soft skills are how you make sure that you and everyone you work with can do their best work. Overall, the highest quality developers are the ones who are motivated to make a quality product and patient enough to stick with it. Best of luck finding someone who fits that description! (No apologies if we get to them first.)
  8. If you want the details, @devnullprod's summary of the peerfinder and overlay network code is a good source. (I can't guarantee it's 100% accurate, but by and large I think it is.) As for other info about the anti-spam measures and stuff, I'm not totally sure. I think each server is mostly willing to provide whatever ledger data they have to any peers, relay validations, etc. as long as the signatures check out and the server is not currently overloaded. If a server gets busy then it starts refusing certain requests. I'm not sure about any automated mechanisms to block abusive / extremely spammy peer connections, but I think there are some because I remember hearing that information about which peers to block is one of the things that clustered servers share with one another.
  9. When a server receives a new, valid transaction, whether from a peer or from an API submission process, it does something like the following: Compare the transaction's XRP cost and to the local load cost (based on how busy the server is) If the cost is too low: Discard the transaction for now If the cost is sufficient: Compare the transaction's XRP cost to the open ledger cost (based on how many transactions are in the current ledger vs. how many are expected to be) If the cost is sufficient: Apply the transaction to the open ledger If the cost is too low: Pre-checks the transaction to see if it's likely to succeed and is allowed to be queued If so, queues the transaction (if the queue is full, possibly kicking another, cheaper transaction, out of the queue) Otherwise, discards the transaction If the server applied the transaction to the open ledger or queued it: Broadcast the transaction to the server's direct peers. Each of those servers repeats this process from the beginning, which spreads the transaction throughout the network. There are some slightly more complicated details of how the server decides when to relay a transaction (what failures are retriable, don't send transactions right back to the peer you got them from, etc.) but that's the gist of things.
  10. The forum should be back up today. (We'll see how long it lasts.)
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Good catch. Fix forthcoming: https://github.com/ripple/ripple-dev-portal/pull/522
  17. 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!
  18. 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.
  19. 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.)
  20. 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.
  21. 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
  22. 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.
  23. 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:
  24. ... 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...