Jump to content

mDuo13

Ripple Employee
  • Content count

    264
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by mDuo13

  1. An update on Ripple's XRP escrow

    Glad this was taken care of quickly and that the company had the gumption to admit the mistake.
  2. Deal with telCAN_NOT_QUEUE

    What server are you submitting to, and what version is it running? rippled 0.70.2 added some new codes that clarify telCAN_NOT_QUEUE sub-cases like blocked/blocks, XRP balance, queue full, etc. I think the s1.ripple.com servers have been very busy lately because of the recent price spike, so it's possible the queue itself is full. I wish more people (and businesses!) ran their own rippled servers instead of relying on Ripple's public servers. That said, I suspect your problem is the LastLedgerSequence one. If you used the most recently validated ledger, and then a ledger closed right around the time you were submitting, it could be that you just barely missed the "current" ledger + 2. (The "current" ledger can be +2 over the validated ledger depending on where in the consensus process you hit—there may be an unconfirmed closed ledger between the validated ledger and the current open ledger.) Also, according to some research @JoelKatz has been doing lately, spending 11-15 drops is generally enough to get in within a ledger or two (5-10 seconds). Though you can go crazy and spend like 5,000+ drops if you're really in a hurry, anywhere in between 15 and 5000 drops doesn't make much of a practical difference in processing speed right now.
  3. What @TexasHodlem said is correct. To be more specific, the "metadata" of a validated transaction shows what happened while executing that transaction. Specifically, in the metadata's "AffectedNodes" array, there's almost always an "AccountRoot" type object for the transaction sender whose "Balance" (XRP) is decreased by some amount. If the transaction doesn't send, sell, or set aside XRP, then the difference is equal to the "Fee" (transaction cost) field exactly. This includes the case where the transaction failed with a "tec"-class error. Other error classes like tel, tem, tef, and ter, don't get included in ledgers, so they don't pay a transaction cost. But keep in mind, some of those may not be the transaction's final code if you see it when you submit a transaction. If the transaction sent or sold XRP, then the total amount debited is the transaction cost and the amount sent/sold combined. There'll also be at least one other AccountRoot, Escrow, or PayChannel node in the AffectedNodes that's credited however much was sent/sold. (And of course, it's reported in integer "drops" of XRP.)
  4. Deal with telCAN_NOT_QUEUE

    https://ripple.com/build/transaction-cost/#queued-transactions
  5. Self Escrow

    There's a detailed tutorial on how to do this with the rippled APIs here, although it's certainly not foolproof: https://ripple.com/build/escrow-tutorials/ You can also use RippleAPI, where you can specify the escrow time using an ISO 8601 date-time string like "2018-01-01T12:00:00.000Z", although the existing docs don't really walk you through the whole process: https://ripple.com/build/rippleapi/#escrow-creation (Unlike the example code, you should be sure to put the lockup time in the "allowExecuteAfter" field.)
  6. Ledger account spam is a known issue, believe me. (Some exchanges are more, uh, communicative than others.) There are several barriers standing in the way of deleting accounts, the main one being transaction replay. If you fully delete an account, you lose track of its sequence number and so you could send old transactions again if you re-created it. (And of course, if you fully delete the account, you have no idea whether it used to exist or not.) And even if there was a way to delete or compact accounts, that mechanism couldn't refund people the account reserve, or else people could spam the ledger with accounts for as long as they wanted, then get all their money back (effectively losing nothing) whenever they decided they were done.
  7. Rippled 0.90.0-b1 is out ?!

    My understanding is that 0.81.0 will be identical to 0.80.1 except for the default config file. 0.81.0 will ship with a default config file that uses Ripple's validator list site (vl.ripple.com) instead of the hardcoded validator public keys. At that point, we'll strongly encourage everyone to update their configs to match. Going forward, the vl.ripple.com site will let people automatically follow along with Ripple's recommendations for which validators to trust as the validation network grows from the default 5 to a larger, more diverse set. (It's important that everyone adds validators more or less in sync; if you fall way behind and end up with a non-representative subset, then it's theoretically possible for you to accidentally fork away from the main network.) Meanwhile 0.90.0 is our next major release with new features. (Not sure what's guaranteed to go in there, but "less tricky partial payments", "checks", "full crypto conditions suite", and others are possibilities I've heard floated.)
  8. Published a couple new documents today: "Money in the XRP Ledger" is a high-level introduction to how money works in the XRP Ledger: the two types of currency and their different properties. "Currency Format" migrates and updates the old wiki page by the same name. This describes the low-level nuts and bolts of how currency codes and currency amounts work and how they're stored. These are just baby steps toward our long-term cleanup and expansion of XRP Ledger documentation, but it's always a pleasure to share when we have progress on that front. As always, I'd love to hear if you find these documents helpful, confusing, or if you have other technical topics you want to see covered in greater depth.
  9. Generally speaking, you don't explicitly mark addresses this way in the XRP Ledger, especially if you're only using XRP itself. You just use the addresses in whatever way you plan to use them. The main difference is where you keep the secret keys—on a computer that connects to the internet and submits transactions in an automatic fashion, or not? If you're issuing non-XRP currencies, you need to set the DefaultRipple flag on your issuing address, but that's about it.
  10. Yes, it's possible with an Amendment to the protocol. (Almost anything is possible with an amendment, really.) It could be tricky to properly handle older data, transactions, and ledgers that were created and saved with the old precision, but not that difficult. Not necessarily. With the way banks operate, they're more likely to use custom private ledgers that support similar features (heck, maybe even Mojaloop, whose conditional payments are similar to XRP Escrow and also ILP-compatible) than to use a shared public cryptocurrency ledger unless they have very good reason to do things in public. Yes, you're precisely right. In the strictest sense, a "blockchain" is a decentralized system wherein the agreed-upon shared state is defined by the longest valid chain of transaction blocks. (Also, you need the full chain of blocks to have the total history of unspent transaction outputs.) Because the XRP Ledger uses a consensus protocol to define which ledger is the agreed-upon state, it has several related qualities that make it different from a "blockchain" in the strict sense: Each block-equivalent ("ledger version") in the XRP Ledger system contains the full state It does not matter which chain is longest, only which chain is approved by a consensus of validators you trust You don't need to have the full history to know the full current state
  11. Also, here's a bit more on transfer fees including examples of how to set them: https://ripple.com/build/gateway-guide/#transferrate
  12. I started writing this stuff out for a message to one person, but it grew out of hand and I realized it might be useful technical info for more people who want to better understand the differences between Interledger modes, Interledger validators, and XRP Ledger validators. The original whitepaper for the Interledger Protocol defines three modes: optimistic, universal, and atomic. In optimistic mode, you assume everything will succeed, so you don't have to use conditional transfers/holds at all. (In fact, this is more or less how legacy payment systems work.) Needless to say, there are lots of problems with optimistic mode, so it's not practical outside of some very carefully controlled situations. Universal mode and atomic mode are two approaches that both solve the multi-ledger execution problem using conditional transfers that expire if the condition isn't met in time. The tricky part is—time is relative! Einstein aside, there are always chances that participants' systems will disagree about whether something made it just before or just after the deadline; maybe it was sent in time but arrived late. Maybe it sat in a queue or got lost along the way, or maybe two participants' clocks are offset from one another. Maybe one side had a long outage during the expiration; should it consider things expired or not when it recovers? The fundamental difference between Universal Mode and Atomic Mode is whose watch you use. To elaborate a little more: In Atomic Mode, you nominate a validator or set of validators (formerly called notaries) to hold the timepiece and be the arbiter of whether a condition was fulfilled before its expiration or not. The individual ledgers where the transfers are happening all look to the Validator(s) to see whether they should execute the transfers or not. This means that the ledger ignores its own clock and goes with what the validator decides—if the transfer gets the validator's stamp of approval, it goes through, no questions asked. An interesting property about these validators is that they don't need to know much about the transfers themselves: all they know is the ID of the overall transaction, the condition (and eventually fulfillment), the expiration time, and which ledger(s) to notify when there's a definite outcome. They don't need to know the parties of the transaction, or what the amounts are; the ledgers have that information and just need a go/no-go signal from the validator(s). In Universal Mode, each ledger is the arbiter of its own timepiece; there is no "validator" in this mode. When the ledger sees a request to fulfill a conditional transfer, it decides whether the expiration has passed or not. As a result, sometimes a payment (a chain of transfers) doesn't fully execute. In those cases, the receiver gets paid, the sender never gets charged, and some connector in the middle loses money. (The connector only loses money if a ledger they use has a failure, or if they themselves have a failure, or if they set their expirations unreasonably close together.) The upside is, connectors can plan around this, not all the parties at all steps have to agree on anything, and the two endpoints of the transaction are never at risk of losing money. In some cases, you can even retry the portion of the payment that failed. What may surprise you is that the public ILP specs don't define atomic mode; Stefan, Evan, et al. came to the conclusion that, in order to use Atomic mode, all the participants had to agree on a set of validators and how to choose them. And if you're going so far as to do that, you could also agree on any number of other modifications to the protocol, so honestly, it doesn't really make sense to define a standard that needs you to agree on some other stuff anyway. On the other hand, if you build a private network of banks and similar institutions, they are are absolutely loathe to accept the risk that some payments fail in the middle, and perfectly willing to define and abide by conventions for whose timepiece is authoritative. Thus, Ripple ended up in a situation where xCurrent uses a proprietary "atomic" variation of the Interledger Protocol (whose conventions are enforced in part by business contracts!) and the published Interledger standards have only the works-anywhere-with-risks Universal mode definition and the reductive-for-example-purposes Optimistic mode. Meanwhile, XRP Ledger validators are a different beast. Unlike Interledger transactions, where each ledger is its own fiefdom, the XRP Ledger consists of a shared state that's replicated across all participants. That means that XRP Ledger validators must not only agree on whether a transaction occurred, but exactly how it executed. The little-discussed "Ripple Transaction Protocol" (RTXP) includes all the rules for how to process a transaction: which objects to create in the ledger's data-store, which offers to take when processing a trade, etc. (For the record, RTXP's only "documentation" is the code itself.) The hash of the final ledger state as a result of all these transactions is the final thing that validators agree on, proving that they reached the same conclusion regarding the exact state of everything the ledger contains. This is no small amount of work, and the fact that the XRP Ledger closes 15,000+ times per day with most validators reaching the exact same conclusion over 90% of the time is pretty impressive. Another major difference between ILP atomic mode validators and XRP Ledger validators is that ILP atomic mode validators can be ad-hoc. You can use a different validator or set of validators for every individual transaction, switching freely between them on whatever basis makes sense. With the XRP Ledger, you're best off following the same set of validators continuously for every ledger. So, as you can see, ILP atomic mode validators and XRP Ledger validators both have important jobs to do, but they are also very different. I hope this is useful information and I'll gladly answer more questions if you want to know more about the intricacies of these fascinating technologies.
  13. If I had to guess, we thought Brad was a good fit because we agree that peanut butter is better when you put a lot of it on every slice.
  14. Generating Keys on Ripple Site

    Breaking your question up: 1. It is impossible, given the current state of mathematics, to reverse-engineer a public key or Ripple address, except by "guess and check" (aka brute force). And to do it by a naive guess-and-check, you'd have to make so many guesses that might take more energy than exists in the universe. It's possible that a new mathematic technique or a quantum computer with a lot of qubits could come up with a far more efficient way to do it. But unless that happens, it's impossible. 2. A Ripple address is inextricably linked with a secret key. (It's called a "master key" for that reason.) There is an option to use a different key (a "regular key") or a set of multiple keys (a signer list) and disable the master key if you're worried. 3. The key pairs aren't stored on the XRP Ledger or anywhere else. The address is stored in the ledger after the account gets funded by receiving an XRP payment; that's enough to verify things signed by the private key, without needing the private key itself. 4. If you generate keys offline, all you've done is choose a random number and then do some math on it. (Same if you generate keys online, actually.) When you send a transaction, the XRP Ledger does some of the same math, and as long as the result is valid, that's all it cares about.
  15. Generating Keys on Ripple Site

    Really, the code you're looking at is just the way you get access to the code that does the real work. It's like looking at a gas pedal and being amazed at how it makes the wheels turn. In reality, the real work is done by your operating system's source of randomness, because, at their core, Ripple key pairs are just random numbers finagled into a particular format. That source of randomness can involve some pretty complex code, because when it comes to randomness, more sources is better. So it'll pull from anything your computer has that might be kind of random: mouse movement, unused memory contents, hardware timing data, possibly even background noise picked up by your microphone and stuff like that. (See also: Wikipedia article on Entropy in Computing)
  16. I think @Sukrim knows more about Lightning than I do, so I can't really talk about that. As for whether you're using the term "settlement" accurately, I've found that different people use it to mean different things even within the industry. The way I tend to view it is, "settlement" happens when the balances are declared current and the outcome of transactions is final so the money is unlocked for you to use elsewhere. If the money is on hold or pending, then settlement (of those transactions) hasn't happened yet. By that definition, sending claims in an XRP payment channel isn't settlement; settlement happens two ways: The receiver redeems a claim to actually get some more XRP into their account, or The sender requests to close the channel, then actually closes the channel after the SettleDelay (waiting period) has elapsed. In both cases, you have to settle using "traditional" XRP Ledger transactions, so you can't settle faster than there's a new ledger version (i.e. every 4-7 seconds). And in the case of #2, the amount of time you have to wait to declare the channel settled is actually defined in the channel itself by the SettleDelay—since you have to give the receiver a chance to redeem any outstanding claims before taking the XRP back. So it's variable, but not faster than every 4-7 seconds. However, the settlement that occurs when you redeem or close a payment channel can encompass an unlimited number of off-ledger payments that are guaranteed by the signed claims. So in a sense this is like the analogy of editing your running total of how much you owe the car-rental company, but there's a big difference: signed claims have a much stronger guarantee, and can be claimed at any time the channel is open. So imagine (for the sake of argument) that you went to a car company for a 10-day car rental at $50/day plus a $500 deposit on a car and a $1/mile usage charge. The car company putting a $1500 hold on your credit card is like opening a $1500 payment channel, except that you (or more accurately, an app acting on your behalf) can update the car company multiple times per second with your mileage and other sundry charges. Then the car company could decide to settle the $50/day charge each morning, and also settle the usage charge every 20 miles or so. You're still out the same amount in the end, but the rental car company can get portions of their eventual bill in between, which means they need less working capital to "tide them over" until they receive payments for the car. In reality, rental cars are unlikely to work this way, but online services are a different story. A lot of Ripple employees are hoping that online content can move beyond an advertising-driven revenue model to a micropayments model, where you could actually pay fractions of a cent per pageload or something more closely tied to the actual cost and value of the media and its delivery method.
  17. You're not a dummy for not understanding paths. I'm pretty sure that the general problem space of paths and routing is one of the biggest challenges of the internet of value. By the way, I talked to the esteemed @JoelKatz and got a better answer for why we don't recommend gateways to trust each other. Basically it's really similar to the thing where you don't want to enable rippling between multiple gateways as a consumer: if one of the gateways you trusted stops redeeming funds, people can take advantage of rippling through you to trade the now-worthless dead gateway's issuances for the still-valuable issuances of other gateways you trust. It's worse if gateways trust one another because rippling can cause a gateway's issuing account to issue more currency (up to the limit they trust the other gateway for), leading to cascading insolvency if gateways trust each other for more than they can afford to lose. It's fine as long as you set the limits reasonably, but you need to be able to react quickly if what seems like a "reasonable" limit suddenly changes. See also: the 2008 financial crisis.
  18. Splitting this up: That's a little different. The diagram linked above is "default paths"—the ones possibly taken where you don't specify any paths in the Payment transaction. To ripple through a third party, you need to include a non-default path mentioning that third party, which is why it's not in the diagram. That's entirely possible; I'm not personally familiar with NBAD's setup. I'm pretty sure they're using it for settling value across internal subsidiaries, and I'm assuming they require authorized trust lines, so they're not going to run into any unclear legal situations with liability to/from third parties.
  19. One of the issuers would have to trust the other. That's against Ripple's recommendations for how to run an issuer, so the only cases where it'll work is ones where people are using unusual configurations. So, not major well-known gateways. I think it's technically viable and a core feature of making community credit schemes work well—two hubs of trust can trust each other to facilitate rippling across them—but I think when it comes to gateway businesses, it could end up in weird legal territory, so it's just an extra precaution to say, "nah, don't ripple between issuers, just use order books" because order books have more explicit limits and well-understood behavior. Lots of people get surprised by the possible outcomes of rippling (more stodgily known as "net settlement") when you incorporate all the technical details.
  20. Ripple Validator Registry

    I'm seeing October 4 stats on mine. Maybe it got fixed since this topic was posted? I know that the site pulls data based on your computer's local time as reported by your browser. Maybe check that your computer's clock has the right date?
  21. Answering these two together: I agree with you. That said, both the published standard and the proprietary atomic variation are evolving, sometimes borrowing from each other and sometimes diverging. I suspect that we may one day publish a standard for the atomic one, but right now we have two different teams focusing on developing their Interledger variations for different use cases. You're spot-on. It's entirely possible (and maybe even a good idea) for some big groups of ILP transactions to choose the XRP Ledger as a source of truth for validation. That said, Universal Mode doesn't need validators and one of the great benefits of ILP is the whole idea of it working anywhere without having to rely on a particular source of truth, so I expect the slice of ILP transactions that would do this to be a substantial minority. In many cases, you want maximum privacy, you don't want to wait extra time for ledger confirmations (the XRP Ledger's 4-second confirmation times here are still way more than you need for some types of ILP transactions), or you may have other reasons for not doing so. But yes, I think it would be awesome, it would make sense, and it probably wouldn't even be that hard to set up. I know the Research Team also played around with an idea called "XRP Atomic Mode Auto-upgrading" or something like that (XAMA) where participants would recognize that their segment of a Universal-mode ILP payment could use the XRP Ledger for validation, and would do that so that the sub-section of the payment acted like an atomic-mode segment. I don't think I understand your question. For one thing, you don't need to "bridge" ILP and the XRP Ledger (formerly known as the RCL) because the XRP Ledger's Escrow feature gives native support for ILP. (PS: new doc page alert!) Good question! Trust lines are a really fascinating concept that really dig into the meaning of money itself. But if you ask our resident software engineer Bob Way, he'll say a "trust line" is just a really awkward term for an "account"—you know, a relationship between two parties where you have a balance, a transaction history, and some metadata. The reason that the XRP Ledger has "trust lines" is that it provides an abstract way for parties to interact in any currency they want. Creating a trust line is sort of like opening an account directly with that person/entity. (The idea of who sets the limits feels "backwards" from what we're used to from banking, but that's mostly an artifact of who has the power to add money to the account.) If I owe my buddy 50 bucks, he puts it on my tab; now I have an "account" with him. And once you have an account, you can do net settlement. That is, if I cover him for $20, we can skip the effort of him pulling out a $20 bill, handing it to me, and me handing it back to cancel out $20 of my debt to him. Interledger trust lines come from basically the idea that, hey, maybe if two parties want to interact with one another, they don't have to go through a central counterparty. And if they just open accounts with one another, they can do the accounting however they like, possibly using a really fast, really simple "ledger" that just records the balances between them and does net settlement automatically. And nobody but those two has to know about the transaction history in their accounts/trust lines with one another, so they get great privacy. The two have to trust each other, but they can set limits on their trust lines/accounts to indicate just how much they trust each other. And they can do Interledger payments between them, being part of bigger ILP payments, without needing to record all their individual transfers at the bank or on a public blockchain ledger or something.
  22. Payment Channels

    It looks like you had an OwnerCount of 9 at the time, including several Payment Channels to rpmn4x... already open: { "id": 1, "command": "account_objects", "account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "ledger_index": 33085918 } { "id": 1, "status": "success", "type": "response", "result": { "account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "account_objects": [ { "Balance": { "currency": "EUR", "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", "value": "0" }, "Flags": 2228224, "HighLimit": { "currency": "EUR", "issuer": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "value": "1000000000" }, "HighNode": "0000000000000000", "LedgerEntryType": "RippleState", "LowLimit": { "currency": "EUR", "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", "value": "0" }, "LowNode": "00000000000001F8", "PreviousTxnID": "7F258F1D461347E2DC291FD251176539217095A63F2B77AD4FEB6222326A637B", "PreviousTxnLgrSeq": 27111857, "index": "8539FC0948A44B4A191034CBBC0A6453675D71C195809EE1C792D9A0E009352F" }, { "Balance": { "currency": "ETH", "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", "value": "0" }, "Flags": 2228224, "HighLimit": { "currency": "ETH", "issuer": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "value": "1000000000" }, "HighNode": "0000000000000000", "LedgerEntryType": "RippleState", "LowLimit": { "currency": "ETH", "issuer": "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", "value": "0" }, "LowNode": "000000000000008B", "PreviousTxnID": "81FBEE61207C4FD237C61E031B8642988999AB2F25429EC9E251D4041A678528", "PreviousTxnLgrSeq": 32213999, "index": "EE0C1F8E9500186965AB449BC162685114DF4F8231ED153321CDF1FF499FFBE6" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Expiration": 559687870, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "7C55CEEC91FA8D77BD1C02149D6D088383A0325677EE0BBFFBD49DB6D5BA8F01", "PreviousTxnLgrSeq": 33020418, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "BED0C316432AF47682DB04116761E14BB78FC0E8B6F092A600ED5FA1A13AE4A5" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Expiration": 559688001, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "B1FB01616AB6719DC1B8E3955FC91DC01658B19D598C4E79A6D3A289594AE364", "PreviousTxnLgrSeq": 33020457, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "4C9BB0C6FD12AB0F9A85470A11797340CBBC213679D81CE407F9D84E859E42F9" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Expiration": 559688100, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "0C53FB8E696F30A691904E3493049C154539135FB13829B4E866994856542BB2", "PreviousTxnLgrSeq": 33020483, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "88A1079E5C73160EFE66C5EAAD94D622203BAF252EA62B466C86DD29CA4B57F4" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "C1D79EB0D15E946736B4DE33C7EE69F3DA0E7BE6ACEEF9DD442C418FBFF3BD9E", "PreviousTxnLgrSeq": 32862304, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "EFCDB932C0CD54A4C937993D19C549037EF879A9F8E4BE506DF44189B0B70A6E" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "94EAB1528FD1FAF0FCD05DB01E0DE7444579C28620131C3AC27A108F25BC791C", "PreviousTxnLgrSeq": 32862308, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "F8DE72B07E2F7D3CD7BED6AD4EA2FAECE386CCD16779F167C1C51D100885099F" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "1773528147DC83B072385205B1E49442C8FB505BE5FF34179F3E3A1CB51F1CAB", "PreviousTxnLgrSeq": 32862318, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "F968CDDBE91602B1E8B6BFD7C1BBFFB41AD43FDA7FEDDEFD1ADAE073B51C3534" }, { "Account": "rEYZSepKEJHXkbVkRzxdTcGdqNo9qcLEPA", "Amount": "1000000", "Balance": "0", "Destination": "rpmn4x7Xbi9jUCvpS6WHLtEhTHUEMYUG9W", "DestinationTag": 4, "Flags": 0, "LedgerEntryType": "PayChannel", "OwnerNode": "0000000000000000", "PreviousTxnID": "7193A1F1D8D606FB36DCB06F84266C3281054AF2E0C81E4058EFE8F01EB59653", "PreviousTxnLgrSeq": 32862352, "PublicKey": "0270233A645A45805F12165089D9D6D5391CFE65F92B96EF0C6C46ED15968BF1B0", "SettleDelay": 86400, "index": "186B0E180E6187CD777B4BCC1B06890F167B65D527008FE1D164276A8EE26B87" } ], "ledger_hash": "D16FB1D548D02476C02FE632AD820FF0CD83C0BCCE8B4EE8DF0A4ED5BFFBBC83", "ledger_index": 33085918, "validated": true } } With 9 items owned, that adds up to 20+(9x5) = 65 XRP locked up. Starting at 72 XRP, subtracting the 3XRP you were putting in the channel and factoring in the additional 5 XRP the new channel would require, that makes it unfunded (69 XRP available vs 70 required). Out of curiosity, did you mean to create 7 different payment channels to the same recipient?
  23. The main challenge here is that the cost of taking particular paths could change at any time. So even if you look and it seems like the transaction will succeed at a certain rate, another transaction could use that liquidity before you. (Maybe they even arrive to most servers a second after you but get luckily placed before you in the canonical order when the ledger closes.) Like tulo said, it'll use the most cost-effective paths first, but there's no guarantee how much you'll deliver with tfPartialPayment by default. tfLimitQuality can help here if you are more concerned with getting a good rate than getting a specific amount. The "default" behavior will try to deliver the specific amount by first using the cheapest path, then if that dries up, going to the next-cheapest, and on down the line. With tfLimitQuality turned on, it stops when the path's rate is less than the ratio of SendMax:Amount, even if the average rate of the overall payment is still within the intended cost because the first few paths were very good. (tfLimitQuality is the "I don't want to use any worse-than-average exchange rates to top off my amount" flag.) Another flag you might want is DeliverMin (destination.minAmount in RippleAPI) so you can set a specific minimum destination amount, and the payment won't succeed (won't spend anything) if it can't deliver at least that much.
  24. Can you link me to where you're expecting to see it?
  25. Thanks! That's good feedback on the "drops" bit. I'll add a reminder. As for the tx hashes, I'm not sure which hashes you're asking for... the ones in the tutorial are all on the TestNet, which means they're ephemeral because the TestNet gets reset regularly and as far as I know there aren't any servers that keep a long history. If you're asking for the Escrows of Ripple's huge XRP stockpile, I don't think they've happened yet.
×