Jump to content


Silver Member
  • Content Count

  • Joined

  • Last visited

  • Days Won


BobWay last won the day on April 20

BobWay had the most liked content!

About BobWay

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Interests
    Software Engineering, Cryptocurrency, Money Systems, Rippling Transactions
  • Occupation
    (Stealth Mode Again)
  • Country
    United States
  • Ripple Address

Recent Profile Visitors

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

  1. 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!
  2. 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?
  3. Thanks @Hodor! I'll edit the original post to change the links.
  4. 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
  5. 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
  6. Awesome! I'm ready to pick some dates and times. I'll post more shortly.
  7. 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
  8. 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.
  9. I'm presuming that a lot of the people in the study group have a solid understanding of XRP and Ripple the company. But I ran across some great background articles by @Hodor That I'd recommend everyone give a read if you haven't seen them before. https://xrphodor.wordpress.com/2018/04/09/a-history-of-xrp-ripple-part-1-2011-2013/ https://xrphodor.wordpress.com/2018/04/13/a-history-of-xrp-ripple-part-2-2014-2016/ https://xrphodor.wordpress.com/2018/04/17/a-history-of-xrp-ripple-part-3-2017/ I don't plan on discussing the timeline in detail in the group. But you will hear me referring back to Ripple's history from time to time. I also found the below infographic reasonably consistent with my experience. https://www.bankingtech.com/2018/01/infographic-history-of-ripple-coin/ If you haven't run across the original "classic ripple pay" site, I encourage you to watch the short video there. https://classic.ripplepay.com
  10. Well I actually only used your name because you put it in the example. Not because I have any magic intel on your personal finances. But just for clarity, let's change the name to "Alice" in my prior post. Alice is an entity that is represented in the XRP Ledger. Alice's address is r123456... Bitstamp is also an entity on the ledger. Bitstamp's address is rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B Alice has USD, EUR & BTC accounts with Bitstamp on-ledger. Alice also has USD, EUR, and BTC accounts with Bitstamp on their off-ledger exchange. Each of those 6 accounting relationships has its own balance and transaction history (that is what an "ledger account" is) There is nothing conceptually different between Alice's off-ledger accounts and her on-ledger accounts. It is trivial for Alice to send USD from on-ledger to off-ledger and back. Bitstamp's (connector) integration assures that when Alice's on-ledger USD balance goes down by $10, her off-ledger USD balance goes up by $10. Optimally, that would be a single atomic transaction that synchronized through ILP primitives. In practice, it's close enough. I'm not sure exactly what point you were trying to make, so let write out a fuller chart of accounts to be more specific. Of course, there are more accounts in each system than the accounting relationships I listed above. Alice's "Chart of Accounts" would show: Alice's Asset Accounts USD: Bitstamp on-ledger EUR: Bitstamp on-ledger BTC: Bitstamp on-ledger USD: Bitstamp off-ledger EUR: Bitstamp off-ledger BTC: Bitstamp off-ledger (Might also include Bank accounts and cash-in-pocket) Alice's Liability Accounts Alice's Equity Accounts USD EUR BTC Bitstamp's Chart of Accounts would show: Bitstamp's Asset Accounts USD: In bank account EUR: In bank account BTC: on blockchain Bitstamp's Liability Accounts USD: Alice on-ledger EUR: Alice on-ledger BTC: Alice on-ledger USD: Alice off-ledger EUR: Alice off-ledger BTC: Alice off-ledger Bitstamp's Equity Accounts USD (fees are credited here) EUR (fees are credited here) BTC (fees are credited here) As an example, let's talk about Alice depositing USD at Bitstamp via bank wire: When Alice deposits USD at Bitstamp Bitstamp debits their USD Bank account Bitstamp credits USD: Alice off-ledger account Alice debits her USD: Bitstamp off-ledger account Alice also credits her USD equity account, because she owns those funds. When Alice transfers USD at Bitstamp from off-ledger to on-ledger Bitstamp debits USD: Alice off-ledger account Bitstamp credits USD: Alice on-ledger account Alice debits her USD: Bitstamp on-ledger account Alice credits her USD: Bitstamp off-ledger account. The point I'm trying to make is that there is no accounting difference between what a trustline does and what any other implementation of an accounting relationship does. You could say that, but really Alice doesn't have to care. She doesn't have a relationship with Bitstamp's hot wallet. She might see that originating payments to her, but that is only for operational security. It isn't something conceptual that Alice should have to care about. Given the chance, I'd hide the hot wallet from Alice by giving it the same display name as the cold wallet. The rest is just operational details for technical geeks. You've described what happens correctly, so I'm not sure what you are uncertain about? The main bit of confusion seems to be the term "actual reality". The concept of "issuing" anything is purely a metaphor. Nothing new is created. Only a balance changes. So when we setup an account relationship as you described. If I send you 100 USD the balance changes to show that now I owe you 100 USD. When you send 100 USD to me, the balance changes to show that we are now "settled" (we have a zero balance). There is never another step that says, "I have these issued IOUs from you totaling $100. And you have these issued IOUs from me totaling $100. Let's decide that they are equal and tear up the IOUs." As you point out, absolutely nothing is implemented like that. You can tell a story using that as a metaphor if you find it useful. But in practice, I've found the metaphor of "issuing IOUs" to be more a hinderance than a help. Thanks for this! I'm going to take a look.
  11. Generally I would just say, Sukrim is an entity that is represented in the XRP Ledger. Sukrim's address is r123456... Bitstamp is also an entity on the ledger. Bitstamp's address is rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B Sukrim has USD, EUR & BTC accounts with Bitstamp on-ledger. Sukrim also has USD, EUR, and BTC accounts with Bitstamp on their off-ledger exchange. Each of those 6 accounts has its own balance and transaction history (that is what an "ledger account" is) How Sukrim logs into Bitstamp's exchange, queries rippled and signs his XRP Ledger transactions is no business of mine. That sentence shows what a disaster the naming choices actually were. In reality. A RippleState object is a single thing also known as a trustline. (because "RippleState" is even more confusing than "trustline"). The trustline connects two entities thereby creating an "accounting relationship" between them. A trustline has two identical sets of parameters. One set for each of the two participants. Together, all the parameters define the agreed upon, ledger moderated, business relationship between the two participants. Each accounting relationship aggregates the business transactions that happen between the two participants. Resulting in a single shared: transaction sequence current balance Of course each accounting relationship can be viewed from the perspective of either party. So more properly, "a RippleState object represents two" symmetrical accounts, one in each of the participant's separate bookkeeping systems. An asset account for one participant, in their system, is A liability account for the other participant, in their system A account debit in one participant's journal entry is ALWAYS associated with a account credit in the other participant's journal entry. Of course, it is impossible for me to issue you USD, while at the same time you issue me USD. Two issuances can't exist at the same time, because there is only a single relationship and balance. And it turns out the terms "issuer" and "issuance" are a disaster as well. It turns out, in the rippled API the term "issuer" really means the person on the other end of the trustline. It has absolutely no semantics related to who issued what to whom. Nor does rippled care who is redeeming what with whom. Nor does it know if one party deposited money with the other prior to the party "issuing" an asset redemption obligation. Or conversely, if that party merely borrowed money first and is "issuing" an IOU promising to repay at some later date. rippled really just does synchronized bookkeeping among multiple parties. What the balances on those accounts represents is PURELY defined by the business relationship negotiated at the time the trustline was created.
  12. In working with clients over the past couple of days, I dug back into my archives and found some personally built versions of the Ripple desktop client from back in 2015. This should be fundamentally equivalent to the rippex.net version above. However, I also found the linux versions. I uploaded them to my GitHub account in case anyone is interested. https://github.com/BobWay/ripple-client-desktop/releases/tag/1.4.0-rc2-2 In the end, the best version to use is going to turn out to be @r0bertz updated version. But until then, the older versions should work well enough. There are some known bugs in the old client. Almost all of them relate to the page not refreshing correctly. In every case, the solution is simple but annoying. Simply quit the application and re-open it again. Everything should look fine after you do so.
  13. In 5 years of explaining Ripple and the XRP Ledger to people, not a single person has disagreed with me when I described a "trust line" as "an accounting relationship". An accounting relationship is an agreement between two entities (Alice & Bob) whereby both agree that one of the following is true: Alice owes Bob money (equivalent) Alice is holding money for Bob Bob owes Alice money (equivalent) Bob is holding money for Alice The balance between them is ZERO (equivalent) Alice and Bob's accounting relationship is settled. Account relationships are easy to describe in bookkeeping terms Alice is holding money for Bob Bob's nostro account This is an asset account in Bob's bookkeeping system The nostro account ledger carries a debit balance. Alice's vostro account This is an liability account in Alice's bookkeeping system The vostro account ledger carries a credit balance. Bob is holding money for Alice Alice's nostro account This is an asset account in Alice's bookkeeping system The vostro account ledger carries a debit balance. Bob's vostro account (equivalent) This is an liability account in Bob's bookkeeping system The vostro account ledger carries a credit balance. Nostro means "our money held by them". Vostro means "their money held by us" In bookkeeping terms, each account carries a debit balance, a credit balance, or a zero balance. From the perspective of the bookkeeping system's owner, some people think of: debit balances (assets) as positive credit balances (liabilities) as negative But this is not strictly true. The owner of the bookkeeping system also maintains one or more "owner's equity" accounts. Those represent the owner's "net worth". Equity accounts carry credit balances. They are seen as the bookkeeping system's liability to the owner. This is what makes the bookkeeping system as a whole "balance". The XRPL doesn't keep explicit equity accounts, but it can derive them through API calls. Account relationships also have "limits' on what their account balance can be. These are made explicit on trust lines but are implicit in most accounting systems. You savings account can not have a negative balance. The lower limit (from your perspective) is zero. From your perspective, it may also have an implicit upper limit as well. Likely the maximum that is insured against loss if the bank were to fail. Checking accounts generally can not have a negative balance either. But banks often offer "overdraft protection" as an additional service. So occasionally you might see a checking account go below zero. "Rippling" is an advanced topic, but it generally has more to do with permissions you set for your accounts, than those permissions set by your counterparties.
  14. Why do you feel strongly about this?
  15. I've been looking at available clients to try and decide which to use in the study group. I'm pretty old and stuck in my ways, so I'm leaning towards using the latest version of the discontinued client that Ripple built. But here are my notes of what I've looked at so far: Top Wallet Client The original downloadable client: https://web.archive.org/web/20180117165134/https://rippex.net/carteira-ripple.php @r0bertz updated version: https://xrpcommunity.blog/how-to-use-regular-key-and-disable-master-key-with-ripple-desktop-client/ Top Utilities Bithomp Explorer and Tools: https://bithomp.com Still Investigating Harbor Wallet: https://www.secureblockchains.com/harbor-xrp-wallet/ Needs pathfinding support Needs test net support Ripplerm: https://github.com/ripplerm/ripple-wallet Just discovered this - similar to Bithomp in concept Ruled Out Hardware Only Minimalist Ripple Client: https://github.com/jatchili/minimalist-ripple-client Bithomp is a better more up-to-date version of this Secalot Hardware Only Ledger Nano Hardware Only Atomic Can't set own secret Coinomi Doesn't support XRPL GateHub Requires a lot of KYC to use Coinbase Wallet Can't set own secret Toast Doesn't seem to support other XRPL currencies very well
  • Create New...