Jump to content


Silver Member
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by BobWay

  1. I’m back to working on this project again. I’ll post background material as I run across it.
  2. @SquaryBone Thank's for inquiring. I just posted some updates here. I'm still a bit overwhelmed and am slowly catching up. If anyone had urgent issues please PM or post them and tag me so I get a beep.
  3. Wow it has been longer than I expected. Thank you everyone for sending all your good wishes. I've had a bunch of family related issues to handle over the past few months. Some were related to family members. Just the kind of things that every family has from time to time. But these issues outrank everything else for me. I don't mind talking about my issues, but the ones related to others I'm going to keep to myself. For those wondering, the doctors assure me that my prostate cancer is likely handled. They assure me this is true even though my PSA numbers are still higher than they should be. It turns out this past week I had my first PSA number drop! Woot! The working diagnosis is that I've had a strange case of prostatitis. I've had two months of different antibiotics and the second one seemed to turn the tide. I'll have lots more followup to make sure. But at least the discomfort is diminishing. One of the other long time consuming issues was that Janet and I have been basically transient for more than five years. This has included more city and apartment moves than I care to count. Unfortunately, our unpredictability has had negative impact on the rest of our extended family. So it became apparent that we needed to pick a permanent home base to settle into. Of course as anyone my age knows, these decisions become complicated when you have both aging parents to plan for and children you'd like to be close to. The end result is that we managed to move two more times. Finally we are almost settled into the place we intend to stay for a while. It's not super impressive, just a two bedroom condo, but we like it. My mother will be moving close to us in the near future. The combination will make a nice "home base" for the kids to come visit. Of course, when you close everything seems move-in-ready. But the move-in reality soon becomes an endless stream of home improvement projects to undertake. I'm still trying to sort out a 3-way light switch that looks like it was wired by a crazy person. There's no cabinet, closet space or furniture to unpack all our boxes into And here is a deck that needs to be rebuilt. The good news is that I have the internet working. Better still, my desk and computer are setup and I finally have a quiet office to work in! Woot! The plan is to get back to work on the Study Group if there is still interest. I'm digging out the decks and reworking the examples for practice today. In addition, I'll be reading the latest posts here in the book club and responding where I can be helpful. Feel free to message me if you have anything urgent to discuss. It's good to be back!
  4. Thanks for understanding. I do find as I wade back in that I have a lot of catching up to do again. Both on the actual news and the community's perceptions of the actual news. Of course on top of that there are huge amounts of rumors, speculation and riddles. I'm absolutely sure I don't have enough time to catch up on those.
  5. Thank you dr_ed and everyone else for sending your good wishes. I'm about to go have another PSA test today. Hopefully this will be the one that finally goes down. I should know by Thursday when I have an appointment with my doctor. But I am feeling better and have settled most of the issues and projects that have kept me away. So I'm looking forward to reconnecting with everyone here again. I'll also be working with Polly to get the study group back on track. Sorry to everyone for the delay.
  6. We'll definitely do something. Let me get my focus back first though.
  7. I find myself without the concentration to watch videos. Which is strange because I seem to have to concentration to read and type an enormous amount of text. :-) But when faced with discussions like ERC-20 tokens, lightning payment channels and other "novel" ideas, it all seems so 5 years ago to me. I'll try to watch this tomorrow. I need to get a little sleep now. I hope I was helpful.
  8. This is largely only true for corporates correct? It seems like the "workaround" DS was describing is the use of xVia to bridge xCurrent and xRapid so MG can quote Fiat to Fiat while completing via xRapid. See my other post on xNaming clarification. SWIFT runs a financial messaging system that is true. But xVia isn't the messaging system for RippleNet. Instead, each xProduct has an integrated messaging component that assures each financial party agrees to the terms of a transaction before any money moves. xVia is simply a hosted solution (and API) for business to use in originating payments that move through RippleNet (xCurrent+xRapid). Every Ripple xProduct allows the sender to specify fiat to (other) fiat payments. Those might be routed fiat/fiat or fiat/xrp/fiat depending on cost. So technically, RippleNet is integrated Messaging + Settlement. SWIFT is Messaging to be used in conjunction with traditional correspondent banking based settlement.
  9. That is really old information. It was true that the recommended UNL contained only 5 ripple operated validators for quite some time. But that changed one more people became able to reliably operate their own rippled validators. Currently the recommended starting UNL seems to be downloadable from here https://vl.ripple.com. I'm presuming that it is a signed blob so that it can be verifiably hosted elsewhere as well. This page documents who owns and operates those validators (UNL column). https://xrpcharts.ripple.com/#/validators
  10. Not at all like lightening network, Banks provide their own liquidity, still uses Nostro/Vostro, and xCurrent is simply tracking/directing/updating private ledgers of the movement/release of funds between the two or more institutions involved. After reading a bit more, seems they're bringing issued currencies and gateways on the XRPL into the mix, and that's mostly what they're referring to here. Ripple from its origination in classic RipplePay has had "trust lines" (accounts) in multiple currencies. It has often used the term IOU in reference to these accounting relationships. Bitcoin traditionally has not considered anything like this as part of its blockchain. However, with lightning, people have been discussing payment channels as if they were IOUs or trust lines that are settled later. So now I often hear bitcoiners rippling concepts as "like lightning". Of course it is generally futile to point out that these concepts predate lightning by 15 years or more.
  11. I can't for the life of me think of what they have misunderstood here. I'm sure the default UNL API call is referenced through an HTTPS based URL to avoid tampering. But I don't know of any other downloaded keys or certs. I don't know of Ripple signing other's certs either.
  12. Yes exactly! In practice it works really well. However, it must be configured within the spirit of what you've written. It is pretty easy to show that if you have zero overlap, or minimal overlap in network participants then their ledgers will diverge.
  13. Think of it the other way around. Anyone can make a UNL list. They don't have to ask permission from the validators to do so. So if you don't like Ripple's list, you just publish your own with the edits you want. It is then up to you to convince everyone else that your UNL starting list is better than Ripple's UNL starting list. If there is significant overlap between the two than they can easily coexist without consequences. If on the the other hand you propose a dramatically different UNL (worst case zero overlap), then you are simply proposing that a new transactional fork is being created. Yes, as you point out, like with BTC based new coin airdrops, anyone could create a new transactional fork of the XRP Ledger. It just becomes up to you to make everyone else care.
  14. Think of the Ripple suggested default UNL as two independent things. 1. It is a Validators ID == Public Key to node operator name map. This is what makes any particular validating node "known" and assures that any given UNL has only one "unique" entry for that node operator. Technically, Ripple as a validator operator has not necessarily had a single "unique" entry on the default UNL. But that has been an operational compromise the company is working to remove. 2. It is an attestation by Ripple that the particular validators on the list are reliably operated. Meaning they have consistent uptime staying insync with the others on the list. Nothing about inclusion on the UNL attests to the character of the rippled nodes operator or their business honesty. Nor does it consider whether or not those operators have any particular value stake (e.g. XRP holdings) in the network itself. it simply says, here are who these people are. Include them or remove them at your own discretion. If you start with a UNL of 100 and remove 95. Well that is likely bad. If you remove 2 or 3 you won't notice any effect at all. Now very interestingly (and like bitcoin) you don't submit transactions to validating nodes at all. Transactions are simply broadcast to every other rippled node. Those broadcasts include validating nodes as well of course. But in general, if you run your own rippled node (validating or not) you would sign and submit your transactions to your own node. It would then in turn broadcast them to the other nodes it is connected to (via IP addresses). Those nodes broadcast it further. During this process your transaction will make it to every rippled validator. However, by design to avoid DOS attacks, there is no proscribed validator --> IP address map.
  15. This is where I'm confused about the whole consensus mechanism overall. I understand you can have different pools (UNLs), but how do they all stay in sync? If one validator or group gets out of sync or behind, does it just grab a current ledger close and pick back up? How does this sort itself out? I think I addressed this in my previous post. Their astonishment is based purely on bad presumptions. If I specify 5 validators I will stay in agreement with them. If you specify 5 validators, you will stay in agreement with those. There is no underlying presumption that I want to stay in sync with the people you want to stay in sync with. (Think test net vs main net vs other net) Nor is there a presumption that I want to accept consensus proposals from individuals anonymous to me, even if they may be known to you. So suppose that your node (validator or not) crashes and falls out of sync with the others. When you bring it back up, it will simply begin doing what it always does. It looks for consensus proposals from the other nodes on its UNL. Once it sees a proposal that matches its consensus rules (80% of the UNL proposes the same thing) it accepts that as the next ledger. It then starts to look backward to see if it is missing any prior ledgers from its local database. If so, it begins downloading them to close any gaps in the record.
  16. My best answer to this - That's just Ripple's list, if the default UNL becomes a small minority the rest of the network disagrees with, there is no overriding protocol/code putting Ripple or it's UNL nodes as a higher authority to the rest of the network. I'm confused as to what happens when the nodes start disagreeing. ( I realize this is a deep deep dive into consensus protocol, if I need to go read up somewhere I'm happy to if anyone can recomend a link to follow) Binance Academy doesn't seem to understand even the most basic concepts. Each rippled node operates completely independently. This is no different from how bitcoind nodes operate. A node's UNL and its consensus rules are set by the owner/operator of that node through configuration options. A node's UNL and its rules define how that particular node decides whether or not it is in agreement with the rest of the rippled nodes it cares about. That last phrase is more profound than it may at first seem. If I run my own personal rippled node, the "unique" in my UNL (unique node list) means that I personal know who the operators of my specified UNL nodes are. Furthermore, it means that I personally am confident that the nodes I specify are not conspiring against me. This "uniqueness" requirement is how your rippled node protects itself against sybil attacks from anonymous conspirators. In effect, it just completely ignores those conspirators. Those who choose to participate in consensus also do so independently. Each participating node broadcasts its own proposal for the transactions to be included in the next ledger. There is no barrier to entry for participation. Anyone can broadcast their own proposals. However, NOBODY else is required by the protocol to care that you are broadcasting proposals. Each node operator makes a personal decision about the other node operators it cares to stay in agreement with. (This differs significantly from bitcoin's mining approach. It is also one of the more confusing characteristics to mining fans.) If you did a little deeper it is easy to see that there can be many different rippled "consensus" agreements operating at the same time. This is true even if everyone's nodes are running exactly the same rippled software. In fact, this is how the XRP Test Net and the XRP Ledger both operate simultaneously using exactly the same software. If you dig still deeper, it is pretty easy to see that if a set of rippled nodes all specify exactly the same UNL and 80% consensus setting, then every node in that set will remain synchronized with every other rippled node in that set. Note that the set of rippled nodes specifying a UNL is completely independent of the rippled nodes specified on the UNL So anonymously operated rippled nodes can say in prefect sync with a set of non-anonymously operated rippled nodes. However, by design, anonymously operated rippled nodes cannot participate in consensus. This characteristic tends to be the biggest annoyance to other cryptocurrency fans. However, this non-anonymity requirement leads directly to the XRP Ledger's consensus efficiency. In reality, the entire electrical burn rate of mining exist purely to allow anonymous nodes to participate in consensus. So this difference is fundamental. If a set of rippled nodes doesn't specify exactly the same UNL and 80% consensus setting it becomes non-trivial for most people to know/show if that set of nodes will remain synchronized in all circumstances. Ethan, David and others have set some bounds on what the UNL overlap must be. But that is a deeper and unnecessary discussion. If everyone starts with the same known UNL set, then subtracts or adds a few other nodes of their own choosing, it is likely they will stay in sync without problems. It doesn't actually matter who chooses the set that everyone starts with. The only requirements for that initial UNL set is that every node operator is both known and unique. (known is required to guarantee unique). In reality most people have little reason to modify the common UNL. However, it is possible for every rippled node to stay in perfect sync, but the network as a whole to still come to a grinding halt. This is true because it is possible for every node to decide independently that it does not have enough information to guarantee to itself that it is in agreement with the others. This can happen when more than 20% of the nodes on a given UNL (with an 80% consensus setting) all simultaneously fail. The halted state however, guarantees that no transactional forks can occur and that no transactions will need to be reversed. So deciding which nodes are reliable enough to include on any given UNL is important as well. That is why Ripple keeps statistics for all known validating (consensus proposing) nodes whether or not they are on the current recommended UNL. https://xrpcharts.ripple.com/#/validators If the reliability of a validating node drops or its operator takes it down, that node's entry should be removed from the UNL of every rippled node that depends on it. This can be done independently by each node's operator or in unison by changing some common UNL definition. As long as there is not a dramatic number of simultaneous validator failures these UNL edits are not time critical. Cobalt and other internal Ripple research integrate these UNL update decisions into the automated consensus process. But again, that is an advanced topic far beyond those who wrote the referenced hit piece.
  17. Wow @SamIam there is a lot of crap in that "report". Not sure I have the interest to tolerate reading it. I'm under the weather so feeling a bit grouchy. Any snark is targeted at the writers of the "report" @SamIam is questioning. Not toward Sam's queries xVia was billed initially as an interface for corportates so submit payments via RippleNet. Birla recently tweeted that it's a bridge between xCurrent and xRapid. Can you add anything to that? Has that always been the case? On the centralized consensus, my understanding - it's running on top of ILP and using a payment channel so upon close settlement over XRPL uses consensus. "Is XRP Ledger’s consensus mechanism decentralized?" Yes. The technology is documented in lots of places. This "report" doesn't seem to understand its most basic concepts. "What is clear is that RippleNet’s xCurrent and xVia are not using the XRP Ledger, so they have centralized consensus." How on earth is that clear? The statement doesn't make the least bit of sense. Consensus isn't even a concept that applies to xCurrent and xVia. Sometimes he has all the clarity of BG123. Wait...? That's a thought. Nah. In my understanding, xVia isn't a bridge between xCurrent and xRapid. Those connect together naturally through multi-hop rippling payments. xVia is basically a cloud hosted version of xCurrent. The original vision was to provide businesses and payment originators access to RippleNet (xCurrent) APIs, without their having to license and host the xCurrent software itself. I think of it this way: xCurrent == RippleNet software for Banks xRapid == RippleNet software for Exchanges xVia == RippleNet hosted APIs for Business "On the centralized consensus..." There really isn't any such thing as centralized consensus. RippleNet's ILP is a synchronized payment protocol. it relies on bi-lateral agreement between parties sharing an accounting relationship. The synchronization is handled by ILP's notary component. The notary is only responsible for time keeping. It doesn't handle any other significant part the the transactions. (balances or approvals) But yes, AFAIK you are correct. the xRapid parties settle using either XRPL payments or by closing XRP payment channels. I'm not up on the details of the latest partner implementations. Oops, pressed return too early. I'll continue in separate posts.
  18. Sorry to disappear for so long. The week turned out to be more involved than I thought. Just as a quick recap, I've been fighting prostate cancer. I had radiation treatment, but my PSA numbers have not responded in the way they were expected to. (down) Unfortunately, they have been trending up. This is quite puzzling to the doctor's because I caught the cancer early. It was also a less aggressive variant that should have responded to treatment easily. That has been coupled to some nagging discomfort in the area that won't seem to go away either. So last week was a bit stress inducing. I had two full body scans last Tuesday and Wednesday. The first was a bone scan and the second was a full body CT scan. The goal was to make sure none of the cancer had escaped and spread. Medicine being what it is, the scans had to be done, read by a radiologist, then relayed to my oncologist. I had to wait on the final results until this Tuesday. So in between, Janet and I decided to mitigate the stress by driving to Baton Rouge, LA to meet the awesome XRP Community there. Many thanks to @RippleWraith for setting up an awesome dinner meetup. And even more thanks to everyone who showed up despite the torrential rain and flooding happening last week. RippleWraith even brought an amazing birthday cake to top off the evening. It turns out, it is only an hour and a half more of pouring rain to make it New Orleans. So Janet and I spent my Birthday there. Her gambling (she won) and me drinking (I won!) We managed to get out of there Saturday morning just before the flooding got to NOLA. Turns out only six hours more rain to make it back to Houston! We ended up going straight to my mothers to pick up Puccini, then stayed over Saturday night to be there for Mother's Day on Sunday. Of course, the endless rain and driving broke something on the car. So Monday meant fixing that. Then staying over longer to see the doctor on Tuesday. Good news is, it turns out, all the scans are clean! That was a huge relief. We still don't know what is causing the numbers to stay up, but it is seeming likely that it may be prostatitis. I've got a long course of antibiotics to take now and more testing and followups later in the summer. So all in all, it looks like I'll survive. So now that I'm finally home and back online onward to the first study group session. I'll post about that in another thread. Sorry to keep everyone waiting. But at least, XRP has been trending up in the meantime!
  19. That is crazy inconvenient. Does that have something to do with the web socket connection? The client doesn't seem like it should need anything like that?
  20. Thanks @Hodor! I'll edit the original post to change the links.
  21. Many of the most confusing things about Ripple and XRP are related to poorly chosen names. I'm sure most people are familiar with this infographic that Ripple published. But it is important to realize that the above names are just the most recent choices. Prior to this, the company and products have been called many different things. Some of are detailed in links referenced above, but many are not. It is nearly impossible to talk about the subject and why people are confused without referencing prior names and how they have changed. Company Currency System Ecosystem Product ======= ======== ====== ========= ======= OpenCoin ripples Ripple The Ripple Network The Ripple Client Ripple Labs ripple Ripple Ledger The Ripple Network RippleTrade Client Ripple ripple RCL The Ripple Network RippleConnect 2.0 Ripple ripple ILP The Ripple Network RippleConnect 3.0 Ripple ripple ILP The Ripple Network The Ripple Solution Ripple ILP RippleNet xCurrent Ripple XRP XRP Ledger RippleNet xRapid Definitions =========== Ripple Consensus Ledger RCL The Interledger Protocol ILP Alternate Terms =============== ILP The Interledger Ledger / Connector ILP Open Internet of Value Connector
  22. So I’m done evaluating client software and planning what I want to share. I’ve also setup a bunch of demonstration accounts on the test net. I have a decent deck for the first session. I may add a couple of animations to it tomorrow just for clarity. So really, all that is left is to pick a date and time to get started. I can’t wait to see what y’all have come up with. I’m hoping we can work out a plan with two sessions each week about 12 hours or so opposite each other. That way, hopefully everyone will be able to find an acceptable time to participate live. If we do those two sessions about 2 days apart, then those that want to can review the material from the first session prior to attending the second. I’m going to start a couple of new threads so we’ll have a place to discuss the season details. I say a couple because I’m going to put some “back story” material into a Session 0 thread. I think many people will already know that material, but for those who don’t it should be helpful in setting context for Session 1. If anyone has time, I’m going to do some Zoom.us conferencing software testing tomorrow to make sure I’m prepared. I’ll post when and where in this thread and on Twitter. I’m hoping we can target a Session 1 date of Monday or early next week. I’d actually like to start earlier, but this is the one week of the year I seem to have booked up. Tuesday: Medical scan Wednesday: Medical scan Thursday: Baton Rouge XRP Meetup Friday: New Orleans (Birthday) Sunday: Mother’s Day
  23. Awesome! I'm ready to pick some dates and times. I'll post more shortly.
  24. Over the past few days I've setup some example ledger configurations and done a bunch of client testing. My goal was to find the best client to teach with. I'm going to presume that everyone I'm teaching is using the same client software. That is not a strict requirement, just a crutch to keep me sane. So to make things easy on myself, I'm going to start with the final version of the original Ripple client that I built myself. The main reason for this is that I have downloadable zips for Mac, Windows and Linux. https://github.com/BobWay/ripple-client-desktop/releases/tag/1.4.0-rc2-2 Once @r0bertz gets a similar set of builds working, I'll recommend everyone switch to his version. I'm also going to be teaching everyone using Ripple's Test Net as opposed to using the main XRP Ledger directly. There are several reasons for using the Test Net over the main XRPL. There is no barrier to entry. Everyone can create their own test net addresses complete with 10,000 test-XRP. We are going to be doing lots of different demonstrations, so you may end up with several different addresses. Giving everyone new test net addresses keeps your study group identity separate from any real money identity (addresses) you might already have on the XRPL or with an exchange. Part of my goals is teaching everyone what is private and what is public. It's best to keep real money out of the discussion until everyone has a solid background on the technology. Most importantly, I want to be able to demonstrate XRP bridge payments. In doing our exercises, I'm going to be "issuing" USD and other currencies on the ledger. Then we will post orders to buy and sell the fiat for XRP. This will allow us to send fiat to fiat payment through XRP as a bridge currency It turns out it is a very bad idea to mix "fake" fiat currencies with real XRP on the main XRPL. Clever outsiders may notice that: if they are able to acquire fake fiat from someone in the study group, they could then convert that to real XRP and cache it out through an exchange. Using the test net satisfies all the constraints and avoids any unintended consequences. However everything you learn will transfer directly to the main XRP Ledger by changing a single setting in the client. I will also be showing the Ripplerm client during demonstrations. This is a full-featured browser based client with a concise display. I'll open it six times simultaneously to show the live changes that happen to each address as multi-party payments ripple through them. https://github.com/ripplerm/ripple-wallet I'll also be using Bithomp's tools for reference, because they are awesome! https://bithomp.com
  25. Thanks, I didn't know that. But you are right, I think quitting and restarting might be faster. @r0bertz The one think I'd like to wrap my head around is where the client caches any of its non-wallet data. I like to run multiple clients at the same time. (often six or more) when the client was browser based, there were fewer issues because all the data was kept separated. Somehow, when it was built to run standalone some bugs crept in that seem to be related to sharing cached data.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.