Jump to content

BobWay

Silver Member
  • Content Count

    507
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by BobWay

  1. 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.
  2. 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.
  3. We'll definitely do something. Let me get my focus back first though.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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!
  16. 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?
  17. Thanks @Hodor! I'll edit the original post to change the links.
  18. 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
  19. 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
  20. Awesome! I'm ready to pick some dates and times. I'll post more shortly.
  21. 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
  22. 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.
  23. 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
  24. 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.
  25. 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.
×
×
  • Create New...