Jump to content

mDuo13

Ripple Employee
  • Content Count

    447
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Regular

Profile Information

  • Gender
    Not Telling
  • Ripple Address
    ra5nK24KXen9AHvsdFTKHSANinZseWnPcX

Recent Profile Visitors

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

  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.
×
×
  • Create New...